- 29 5月, 2007 7 次提交
-
-
由 Shawn O. Pearce 提交于
Git has supported remote branch deletion for quite some time, but I've just never gotten around to supporting it in git-gui. Some workflows have users push short-term branches to some remote Git repository, then delete them a few days/weeks later when that topic has been fully merged into the main trunk. Typically in that style of workflow the user will want to remove the branches they created. We now offer a "Delete..." option in the Push menu, right below the generic "Push..." option. When the user opens our generic delete dialog they can select a preconfigured remote, or enter a random URL. We run `git ls-remote $url` to obtain the list of branches and tags known there, and offer this list in a listbox for the user to select one or more from. Like our local branch delete dialog we offer the user a way to filter their selected branch list down to only those branches that have been merged into another branch. This is a very common operation as the user will likely want to select a range of topic branches, but only delete them if they have been merged into some sort of common trunk. Unfortunately our remote merge base detection is not nearly as strict as the local branch version. We only offer remote heads as the test commit (not any local ones) and we require that all necessary commits to successfully run git-merge-base are available locally. If one or more is missing we suggest that the user run a fetch first. Since the Git remote protocol doesn't let us specify what the tested commit was when we evaluated our decision to execute the remote delete there is a race condition here. The user could do a merge test against the trunk, determine a topic branch was fully merged, but before they can start pushing the delete request another user could fast-forward the remote topic branch to a new commit that is not merged into the trunk. The delete will arrive after, and remove the topic, even though it was not fully merged. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Git's native command line interface has had branch renaming support for quite a while, through the -m/-M options to the git-branch command line tool. This is an extremely useful feature as users may decide that the name of their current branch is not an adequate description, or was just entered incorrectly when it was created. Even though most people would consider git-branch to be a Porcelain tool I'm using it here in git-gui as it is the only code that implements the rather complex set of logic needed to successfully rename a branch in Git. Currently that is along the lines of: *) Backup the ref *) Backup the reflog *) Delete the old ref *) Create the new ref *) Move the backed up reflog to the new ref *) Record the rename event in the reflog *) If the current branch was renamed, update HEAD *) If HEAD changed, record the rename event in the HEAD reflog *) Rename the [branch "$name"] section in the config file Since that is some rather ugly set of functionality to implement and get right, and some of it isn't easily accessible through the raw plumbing layer I'm just cheating by relying on the Porcelain. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The Windows and Mac OS X platforms do not generally use the tearoff menu feature found on traditional X11 based systems. On Windows the Tk engine does support the feature, but it really is out of place and just confuses people who aren't used to working on a UNIX system. On Mac OS X its not supported for the root menu bar and its submenus, as it doesn't fit into the overall platform UI model. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we cannot locate our git-gui library directory, or we find it but the tclIndex file is not present there (or it is present but is not something we are allowed to read) the user cannot use the application. Rather than silently ignoring the errors related to the tclIndex file being unavailable we report them up front and display to the user why we cannot start. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we are using our "non-optimized" tclIndex format (which is just a list of filenames, in the order necessary for source'ing) we are doing all of our loading before we even tested to see if GITGUI_VERBOSE was set in the environment. This meant we never showed the files as we sourced them into the environment. Now we setup our overloaded auto_load and source scripts before we attempt to define our library path, or source the scripts that it mentions. This way GITGUI_VERBOSE is always honored if set. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because we now try to automatically guess the library directory in certain installations users may wonder where git-gui is getting its supporting files from. We now display this location in our About dialog, and we also include the location we are getting our Git executables from. Unfortunately users cannot use this 'About git-gui' dialog to troubleshoot library loading problems; the dialog is defined by code that exists in the library directory, creating a catch-22. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
In some workflows it is common for a large number of temporary branches to be created in a remote repository, get fetched to clients that typically only use git-gui, and then later have those branches deleted from the remote repository once they have been fully merged into all destination branches. Users of git-gui would obviously like to have their local tracking branches cleaned up for them, otherwise their local tracking branch namespace would grow out of control. The best known way to remove these tracking branches is to run "git remote prune <remotename>". Even though it is more of a Porcelain command than plumbing I'm invoking it through the UI, because frankly I don't see a reason to reimplement its ls-remote output filtering and config file parsing. A new configuration option (gui.pruneduringfetch) can be used to automatically enable running "git remote prune <remotename>" after the fetch of that remote also completes successfully. This is off by default as it require an additional network connection and is not very fast on Cygwin if a large number of tracking branches have been removed (due to the 2 fork+exec calls per branch). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 27 5月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Johannes Sixt asked me to try to avoid embedding the runtime location of git-gui's library directory in the executable script. Not embedding it helps the MinGW to be relocatable to another directory should a user wish to install the programs in a directory other than the location the packager wanted them to be installed into. Most of this is a hack. We try to determine if the path of our master git-gui script will be able to locate the lib by ../share/git-gui/lib. This should be true if $(gitexecdir) and $(libdir) have the same prefix. If they do then we defer the assignment of $(libdir) until runtime, and we get it from $argv0 rather than embedding it into the script itself. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 24 5月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Alberto Bertogli reported on #git that git-gui was exiting with alt-q, while gitk on the same system was exiting with ctrl-q. That was not what I wanted. I really wanted M1B to be bound to the Control key on most non-Mac OS X platforms, but according to Sam Vilain M1 on most systems means alt. Since gitk always does control, I'm doing the same thing for all non-Mac OS X systems. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 22 5月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Our GITGUI_LIBDIR macro was testing only for @@ at the start of the path, assuming nobody would ever find that to be a reasonable prefix for a directory to install our library into. That is most likely a valid assumption, but its even more unlikely they would have the start be @@GITGUI_ and the end be @@. Note that we cannot use the full string here because that would get expanded by the sed replacement in our Makefile. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 18 5月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Petr Baudis pointed out the main git.git repository's Makefile dies now if git-gui 0.7.0-rc1 or later is being used and TCL_PATH was not set to a working tclsh program path. This breaks people who may have a working build configuration today and suddenly upgrade to the latest git release. The tclIndex is required for git-gui to load its associated lib files, but using the Tcl auto_load procedure to source only the files we need is a performance optimization. We can emulate the auto_load by just source'ing every file in that directory, assuming we source class.tcl first to initialize our crude class system. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 11 5月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 09 5月, 2007 5 次提交
-
-
由 Shawn O. Pearce 提交于
If the user doesn't give us a revision parameter to our blame subcommand then we can generate blame against the working tree file by passing the file path off to blame with the --contents argument. In this case we cannot obtain the contents of the file from the ODB; instead we must obtain the contents by reading the working directory file as-is. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The browser subcommand now optionally accepts a single revision argument; if no revision argument is supplied then we use the current branch as the tree to browse. This is very common, so its a nice option. Our blame subcommand now tries to perform the same assumptions as the command line git-blame; both the revision and the file are optional. We assume the argument is a filename if the file exists in the working directory, otherwise we assume the argument is a revision name. A -- can be supplied between the two to force parsing, or before the filename to force it to be a filename. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I think it was Andy Parkins who pointed out that git gui blame HEAD f does not work if f is in a subdirectory and we are currently running git-gui within that subdirectory. This is happening because we did not take the user's prefix into account when we computed the file path in the repository. We now assume the prefix as returned by rev-parse --show-prefix is valid and we use that during the command line blame subcommand when we apply the parameters. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Our blame viewer code has historically been a mess simply because the data for multiple viewers was all crammed into a single pair of Tcl arrays. This made the code hard to read and even harder to maintain. Now that we have a slightly better way of tracking the data for our "meta-widgets" we can make use of it here in the blame viewer to cleanup the code and make it easier to work with long term. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that we have a slightly easier method of working with per-widget data we should make use of that technique in our browser and console meta-widgets, as both have a decent amount of information that they store on a per-widget basis and our current approach of handling it is difficult to follow. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 08 5月, 2007 4 次提交
-
-
由 Johannes Sixt 提交于
All menu entries talk about "staging" and "unstaging" changes, but the titles of the file lists use different wording, which may confuse newcomers. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Like the console procs I have moved the code related to merge support into their own namespace, so that they are isolated from the rest of the world. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users who are used to vi and recent versions of gitk may want to scroll the diff region using vi style keybindings. Since these aren't bound to anything else and that widget does not accept focus for data input, we can easily support that too. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'm finding it difficult to work with a 6,000+ line Tcl script and not go insane while looking for a particular block of code. Since most of the program is organized into different units of functionality and not all users will need all units immediately on startup we can improve things by splitting procs out into multiple files and let auto_load handle things for us. This should help not only to better organize the source, but it may also improve startup times for some users as the Tcl parser does not need to read as much script before it can show the UI. In many cases the user can avoid reading at least half of git-gui now. Unfortunately we now need a library directory in our runtime location. This is currently assumed to be $(sharedir)/git-gui/lib and its expected that the Makefile invoker will setup some sort of reasonable sharedir value for us, or let us assume its going to be $(gitexecdir)/../share. We now also require a tclsh (in TCL_PATH) to just run the Makefile, as we use tclsh to generate the tclIndex for our lib directory. I'm hoping this is not an unncessary burden on end-users who are building from source. I haven't really made any functionality changes here, this is just a huge migration of code from one file to many smaller files. All of the new changes are to setup the library path and install the library files. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 03 5月, 2007 7 次提交
-
-
由 Shawn O. Pearce 提交于
Whenever we want to execute a git subcommand from the plumbing layer (and on rare occasion, the more porcelain-ish layer) we tend to use our proc wrapper, just to make the code slightly cleaner at the call sites. I wasn't doing that in a couple of places, so this is a simple cleanup to correct that. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Rather than passing "-font font_ui" to every widget that we create we can instead reconfigure the option database for all widget classes to use our font_ui as the default widget font. This way Tk will automatically setup their defaults for us, and we can reduce the size of the application. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
An earlier change tossed these optionMenu font configurations all over the code, when really we can just rename the proc to a hidden internal name and provide our own wrapper to install the font configuration we really want. We also don't need to set these option database entries in all of the procedures that open dialogs; instead we should just set one time, them after we have the font configuration ready for use. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since Tk automatically wraps lines for us in tk_messageBox widgets we don't need to try to wrap them ourselves. Its actually worse that we linewrapped this here in the script, as not all fonts will render this dialog nicely. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
A coworker who was new to git-gui recently tried to make an octopus merge when he did not quite mean to. Unfortunately in his case the branches had file level conflicts and failed to merge with the octopus strategy, and he didn't quite know why this happened. Since most users really don't want to perform an octopus merge this additional safety valve in front of the merge process is a good thing. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that the command line git-commit has made displaying the subject (first line) of the newly created commit popular we can easily do the same thing here in git-gui, without the ugly part of forking off a child process to obtain that first line. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the path of our wish executable that are running under contains spaces we need to make sure they are escaped in a proper Tcl list, otherwise we are unable to start gitk. Reported by Randal L. Schwartz on #git. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 24 4月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Uwe Kleine-König discovered git-gui mangled his surname and did not send the proper UTF-8 byte sequence to git-commit-tree when his name appeared in the commit message (e.g. Signed-Off-By line). Turns out this was related to other trouble that I had in the past with trying to use "fconfigure $fd -encoding $enc" to select the stream encoding and let Tcl's IO engine do all of the encoding work for us. Other parts of git-gui were just always setting the file channels to "-encoding binary" and then performing the encoding work themselves using "encoding convertfrom" and "convertto", as that was the only way I could make UTF-8 filenames work properly. I found this same bug in the amend code path, and in the blame display. So its fixed in all three locations (commit creation, reloading message for amend, viewing message in blame). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 15 4月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
By showing the basename of the directory very early in the title bar I can more easily locate a particular git-gui session when I have 8 open at once and my Windows taskbar is overflowing with items. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 05 4月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
If we generate a blame status string before we have obtained any annotation data at all from the input file, or if the input file is empty, our total_lines will be 0. This causes a division by 0 error when we blindly divide by the 0 to compute the total percentage of lines loaded. Instead we should report 0% done. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 04 4月, 2007 4 次提交
-
-
由 Shawn O. Pearce 提交于
If a dialog/window has a default button registered not every platform associates the return key with that button, but all users do. We have to register the binding of the return key ourselves to make sure the user's expectations of pressing return will activate the default button are met. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Eygene Ryabinkin 提交于
Many git-gui messages were broken into a multiple lines to make good paragraph width. Unfortunately in reality it breaks the paragraph width completely, because the dialog window width does not coincide with the paragraph width created by the current font. Tcl/Tk's standard dialog boxes are breaking the long lines automatically, so it is better to make long lines and let the interpreter do the job. Signed-off-by: NEygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Eygene Ryabinkin 提交于
Made the default buttons on the dialog active and focused upon the dialog appearence. Bound 'Escape' and 'Return' keys to the dialog dismissal where it was appropriate: mainly for dialogs with only one button and no editable fields, but on console output dialogs as well. Signed-off-by: NEygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Eygene Ryabinkin 提交于
Some parts of git-gui were not respecting the default GUI font. Most of them were catched and fixed. Signed-off-by: NEygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 13 3月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
I got a little surprise one day when I tried to run 'git gui version' outside of a Git repository to determine what version of git-gui was installed on that system. Turns out we were doing the repository check long before we got around to command line argument handling. We now look to see if the only argument we have been given is 'version' or '--version', and if so, print out the version and exit immediately; long before we consider looking at the Git version or working directory. This way users can still get to the git-gui version number even if Git's version cannot be read. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This reverts commit 871f4c97. Too many users have complained about the credits generator in git-gui, so I'm backing the entire thing out. This revert will finish that series. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Johannes Sixt noticed that git-gui would not let the user commit a merge created by `git merge -s ours` as the ours strategy does not alter the tree (that is HEAD^1^{tree} = HEAD^{tree} after the merge). The same issue arises from amending such a merge commit. We now permit an empty commit (no changed files) if we are doing a merge commit. Core Git does this with its command line based git-commit tool, so it makes sense for the GUI to do the same. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 02 3月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Git 1.5.0 and later no longer output useless messages to standard error when making the initial (or what looks to be) commit of a repository. Since /dev/null does not exist on Windows in the MinGW environment we can't redirect there anyway. Since Git does not output anymore, I'm removing the redirection. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 27 2月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Mark Levedahl noticed that git-gui will let you create an empty normal (non-merge) commit if the file state in the index is out of whack. The case Mark was looking at was with the new autoCRLF feature in git enabled and is actually somewhat difficult to create. I found a different way to create an empty commit: turn on the Trust File Modifications flag, touch a file, rescan, then move the file into the "Changes To Be Committed" list without looking at the file's diff. This makes git-gui think there are files staged for commit, yet the update-index call did nothing other than refresh the stat information for the affected file. In this case git-gui allowed the user to make a commit that did not actually change anything in the repository. Creating empty commits is usually a pointless operation; rarely does it record useful information. More often than not an empty commit is actually an indication that the user did not properly update their index prior to commit. We should help the user out by detecting this possible mistake and guiding them through it, rather than blindly recording it. After we get the new tree name back from write-tree we compare it to the parent commit's tree; if they are the same string and this is a normal (non-merge, non-amend) commit then something fishy is going on. The user is making an empty commit, but they most likely don't want to do that. We now pop an informational dialog and start a rescan, aborting the commit. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-