- 09 7月, 2007 12 次提交
-
-
由 Shawn O. Pearce 提交于
If we cannot locate a command in $gitexecdir on our own then it may just be because we are supposed to run it by `git $name` rather than by `git-$name`. Many commands are now builtins, more are likely to go in that direction, and we may see the hardlinks in $gitexecdir go away in future versions of git. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The master Makefile in git.git installs gitk into bindir, not gitexecdir, which means gitk is located as a sibling of the git wrapper and not as though it were a git helper tool. We can also avoid some Tcl concat operations by letting eval do all of the heavy lifting; we have two proper Tcl lists ($cmd and $revs) that we are joining together and $revs is currently never an empty list. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Rather than making the C library search for git every time we want to execute it we now search for the main git wrapper at startup, do symlink resolution, and then always use the absolute path that we found to execute the binary later on. This should save us some cycles, especially on stat challenged systems like Cygwin/Win32. While I was working on this change I also converted all of our existing pipes ([open "| git ..."]) to use two new pipe wrapper functions. These functions take additional options like --nice and --stderr which instructs Tcl to take special action, like running the underlying git program through `nice` (if available) or redirect stderr to stdout for capture in Tcl. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that we have a fancy status bar mega-widget we can reuse that within our main window. This opens the door for implementating future improvements like a progress bar. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the end-user feeds us an abbreviated SHA-1 on the command line for `git gui browser` or `git gui blame` we now unabbreviate the value through `git rev-parse` so that the title section of the blame or browser window shows the user the complete SHA-1 as Git determined it to be. If the abbreviated value was ambiguous we now complain with the standard error message(s) as reported by git-rev-parse --verify, so that the user can understand what might be wrong and correct their command line. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This is a major rewrite of the way we perform switching between branches and the subsequent update of the working directory. Like core Git we now use a single code path to perform all changes: our new checkout_op class. We also use it for branch creation/update as it integrates the tracking branch fetch process along with a very basic merge (fast-forward and reset only currently). Because some users have literally hundreds of local branches we use the standard revision picker (with its branch filtering tool) to select the local branch, rather than keeping all of the local branches in the Branch menu. The branch menu listing out all of the available branches is simply not sane for those types of huge repositories. Users can now checkout a detached head by ticking off the option in the checkout dialog. This option is off by default for the obvious reason, but it can be easily enabled for any local branch by simply checking it. We also detach the head if any non local branch was selected, or if a revision expression was entered. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'm really starting to dislike global variables. The ui_status_value global varible is just one of those that seems to appear in a lot of code and in many cases we didn't even declare it "global" within the proc that updates it so we haven't always been getting all of the updates we expected to see. This change introduces two new global procs: ui_status $msg; # Sets the status bar to show $msg. ui_ready; # Changes the status bar to show "Ready." The second (special) form is used because we often update the area with this message once we are done processing a block of work and want the user to know we have completed it. I'm not fixing the cases that appear in lib/branch.tcl right now as I'm actually in the middle of a huge refactoring of that code to support making a detached HEAD checkout. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the current branch is not a symbolic-ref that points to a name in the refs/heads/ namespace we now just assume that the head is a detached head. In this case we return the special branch name of HEAD rather than empty string, as HEAD is a valid revision specification and the empty string is not. I have also slightly improved the current-branch function by using string functions to parse the symbolic-ref data. This should be slightly faster than using a regsub. I think the code is clearer too. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
In some workflows users will want to almost always just create a new local branch that matches a remote branch. In this type of workflow it is handy to have the new branch dialog default to "Match Tracking Branch" and "Starting Revision"-Tracking Branch", with the focus in the branch filter field. This can save users working on this type of workflow at least two mouse clicks every time they create a new local branch or switch to one with a fast-forward. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
A simple refactoring of the delete branch dialog to allow use of the class construct to better organize the code and to reuse the revision selection code of our new choose_rev mega-widget. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This rather large change pulls the "Starting Revision" part of the new branch dialog into a mega widget that we can use anytime we need to select a commit SHA-1. To make use of the mega widget I have also refactored the branch dialog to use the class system, much like the delete remote branch dialog already does. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Some newer features of git-gui want to rely on features that are new to Git 1.5.3. Since they were added as part of the 1.5.3 development series we cannot use those features with versions of Git that are older than 1.5.3, such as from the stable 1.5.2 series. We introduce [git-version >= 1.5.3] to allow the caller to get a response of 0 if the current version of git is < 1.5.3 and 1 if the current version of git is >= 1.5.3. This makes it easy to setup conditional code based upon the version of Git available to us at runtime. Instead of parsing the version text by hand we now use the Tcl [package vcompare] subcommand to compare the two version strings. This works nicely, as Tcl as already done all of the hard work of doing version comparsions. But we do have to remove the Git specific components such as the Git commit SHA-1, commit count and release candidate suffix (rc) as we want only the final release version number. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 06 7月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
Pushing changes to a remote system is a very common action for many users of git-gui, so much so that in some workflows a user is supposed to push immediately after they make a local commit so that their change(s) are immediately available for their teammates to view and build on top of. Including the push button right below the commit button on the left toolbar indicates that users should probably perform this action after they have performed the commit action. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users often need to be able to push the current branch so that they can publish their recent changes to anyone they are collaborating with on the project. Associating a keyboard action with this will make it easier for keyboard-oriented users to quickly activate the push features. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
We actually only want our F5/M1-R keystroke bound in the main window. Within a browser/blame/console window pressing these keys should not execute the rescan action. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 30 6月, 2007 1 次提交
-
-
由 Gerrit Pape 提交于
On 'Visualize ...', a gitk process is started. Since it is run in the background, catching a possible startup error doesn't work, and the error output goes to the console git-gui is started from. The most probable startup error is that gitk is not installed; so before trying to start, check for the existence of the gitk program, and popup an error message unless it's found. This was noticed and reported by Paul Wise through http://bugs.debian.org/429810Signed-off-by: NGerrit Pape <pape@smarden.org> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 27 6月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
The Tools/Migrate menu option is a hack just for me. Yes, that's right, git-gui has a hidden feature that really only works for me, and the users that I support within my day-job's great firewall. The menu option is not supported outside of that environment. In the past we only enabled Tools/Migrate if our special local script 'gui-miga' existed in the proper location, and if there was a special '.pvcsrc' in the top level of the working directory. This latter test for the '.pvcsrc' file is now failing, as the file was removed from all Git repositories due to changes made to other tooling within the great firewall's realm. I have changed the test to only work on Cygwin, and only if the special 'gui-miga' is present. This works around the configuration changes made recently within the great firewall's realm, but really this entire Tools/Migrate thing should be abstracted out into some sort of plugin system so other users can extend git-gui as they need. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 22 6月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Junio asked that we don't force the user to have a valid X11 server configured in $DISPLAY just to obtain the output of `git gui version`. This makes sense, the user may be an automated tool that is running without an X server available to it, such as a build script or other sort of package management system. Or it might just be a user working in a non-GUI environment and wondering "what version of git-gui do I have installed?". Tcl has a lot of warts, but one of its better ones is that a comment can be continued to the next line by escaping the LF that would have ended the comment using a backslash-LF sequence. In the past we have used this trick to escape away the 'exec wish' that is actually a Bourne shell script and keep Tcl from executing it. I'm using that feature here to comment out the Bourne shell script and hide it from the Tcl engine. Except now our Bourne shell script is a few lines long and checks to see if it should print the version, or not. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 12 6月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
Because Tk does not assure us the order that it will process children in before it destroys the main toplevel we cannot safely save our geometry data during a "bind . <Destroy>" event binding. The geometry may have already changed as a result of a one or more children being removed from the layout. This was pointed out in gitk by Mark Levedahl, and patched over there by commit b6047c5a. So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when the window is closed by the user, and forward that close event to our main do_quit routine. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Apparently git-commit.sh (the command line commit user interface in core Git) always gives precedence to the prior commit's message if `commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists. We actually were doing the same here in git-gui, but the amended message got lost if $GIT_DIR/MERGE_MSG already existed because we started a rescan immediately after loading the prior commit's body into the edit buffer. When that happened the rescan found MERGE_MSG existed and replaced the commit message buffer with the contents of that file. This meant the user never saw us pick up the commit message of the prior commit we are about to replace. Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by running `git cherry-pick -n $someid` and then trying to amend the prior commit in git-gui, thus combining the contents of $someid with the contents of HEAD, and reusing the commit message of HEAD, not $someid. With the recent changes to make cherry-pick use the $GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message of $someid, not HEAD. Now we always use HEAD if we are amending. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 06 6月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
If the user clicks on a line region that we haven't yet received an annotation for from git-blame we show them "Loading annotation". But I don't want the user to confuse this loading message with a commit whose first line is "Loading annotation" and think we messed up our display somehow. Since we never use italics for anything else, I'm going with the idea that italic slant can be used to show data is missing/elided out at the time being. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Matthijs Melchior 提交于
The default font was already bold, so marking the selected file with bold font did not work. Change that to lightgray background. Also, the header colors are now softer, giving better readability. Signed-off-by: NMatthijs Melchior <mmelchior@xs4all.nl> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 03 6月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
For quite a while we have been assuming the user is running on a Tcl/Tk 8.4 or later platform. This may not be the case on some very old systems. Unfortunately I am pretty far down the path of using the Tcl/Tk 8.4 commands and options and cannot easily work around them to support earlier versions of Tcl/Tk. So we'll check that we are using the correct version up front, and if not we'll stop with a related error message. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Earlier I missed making sure our spinbox widgets used the same font as the other widgets around them. This meant that using a main font with a size of 20 would make every widget in the options dialog huge, but the spinboxes would be left with whatever the OS native font is. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 02 6月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Its wrong to exit the application if we destroy a random widget contained withing something else; especially if its some small trivial thing that has no impact on the overall operation. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 01 6月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
To improve performance on fork+exec impoverished systems (such as Windows) we want to avoid running git-symbolic-ref on every rescan if we can do so. A quick way to implement such an avoidance is to just read the HEAD ref ourselves; we'll either see it as a symref (starts with "ref: ") or we'll see it as a detached head (40 hex digits). In either case we can treat that as our current branch. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Johannes Sixt pointed out that dropping to 0 lines of context does allow the user to get more fine-grained hunk selection, especially since we don't currently support "highlight and apply (or revert)". Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 29 5月, 2007 8 次提交
-
-
由 Shawn O. Pearce 提交于
Recently git-merge learned to avoid generating the diffstat after a merge by reading the merge.diffstat configuration option. By default this option is assumed to be true, as that is the old behavior. However we can force it to false by setting it as a standard boolean option. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 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>
-