Skip to main content

Browse the archive

Staging
v0.5.1
swh:1:snp:c5feb7ee9221a3820c8879e85e8a18470c0b3afa
sort by:
Revision Author Date Message Commit Date
3849bfb Shawn O. Pearce 17 September 2007, 03:12:19 UTC git-gui: Disable native platform text selection in "lists" Sometimes we use a Tk text widget as though it were a listbox. This happens typically when we want to show an icon to the left of the text label or just when a text widget is generally a better choice then the native listbox widget. In these cases if we want the user to have control over the selection we implement our own "in_sel" tag that shows the selected region and we perform our own selection management in the background via keybindings and mouse bindings. In such uses we don't want the user to be able to activate the native platform selection by dragging their mouse through the text widget. Doing so creates a very confusing display and the user is left wondering what it may mean to have two different types of selection in the same widget. Tk doesn't allow us to delete the "sel" tag that it uses internally to manage the native selection but it will allow us to make it invisible by setting the tag to have the same display properties as unselected text. So long as we don't actually use the "sel" tag for anything in code its effectively invisible. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 17 September 2007, 03:12:19 UTC
55bad4f Shawn O. Pearce 14 September 2007, 00:08:53 UTC git-gui: Paper bag fix "Commit->Revert" format arguments The recent bug fix to correctly handle filenames with %s (or any other valid Tcl format specifier) missed a \ on this line and caused the remaining format arguments to not be supplied when we updated the status bar. This caused a Tcl error anytime the user was trying to perform a file revert. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 September 2007, 00:08:53 UTC
042f53c Shawn O. Pearce 13 September 2007, 23:50:35 UTC git-gui: Provide 'uninstall' Makefile target to undo an installation Several users have requested a "make uninstall" target be provided in the stock git-gui Makefile so that they can undo an install if git-gui goes to the wrong place during the initial install, or if they are unhappy with the tool and want to remove it from their system. We currently assume that the complete set of files we need to delete are those defined by our Makefile and current source directory. This could differ from what the user actually has installed if they installed one version then attempt to use another to perform the uninstall. Right now I'm just going to say that is "pilot error". Users should uninstall git-gui using the same version of source that they used to make the installation. Perhaps in the future we could read tclIndex and base our uninstall decisions on its contents. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 September 2007, 00:02:39 UTC
afe2098 Shawn O. Pearce 13 September 2007, 23:07:46 UTC git-gui: Font chooser to handle a large number of font families Simon Sasburg noticed that on X11 if there are more fonts than can fit in the height of the screen Tk's native tk_optionMenu does not offer scroll arrows to the user and it is not possible to review all choices or to select those that are off-screen. On Mac OS X the tk_optionMenu works properly but is awkward to navigate if the list is long. This is a rewrite of our font selection by providing a new modal dialog that the user can launch from the git-gui Options panel. The dialog offers the user a scrolling list of fonts in a pane. An example text shows the user what the font looks like at the size they have selected. But I have to admit the example pane is less than ideal. For example in the case of our diff font we really should show the user an example diff complete with our native diff syntax coloring. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Acked-by: Simon Sasburg <simon.sasburg@gmail.com> 13 September 2007, 23:07:46 UTC
e7034d6 Shawn O. Pearce 13 September 2007, 23:04:14 UTC git-gui: Make backporting changes from i18n version easier This is a very trivial hack to define a global mc procedure that does not actually perform i18n translations on its input strings. By declaring an mc procedure here in our maint version of git-gui we can take patches that are intended for the latest development version of git-gui and easily backport them without needing to tweak the mc calls first. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 13 September 2007, 23:04:14 UTC
63c4024 Shawn O. Pearce 11 September 2007, 17:37:45 UTC git-gui: Don't delete send on Windows as it doesn't exist The Windows port of Tk does not have the send command so we cannot delete it from our global namespace, but the Mac OS X and X11 ports do have it. Switching this delete attempt into a catch makes send go away, or stay away. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 11 September 2007, 22:57:18 UTC
8938410 Shawn O. Pearce 10 September 2007, 00:38:05 UTC git-gui: Trim trailing slashes from untracked submodule names Oddly enough `git ls-files --others` supplies us the name of an untracked submodule by including the trailing slash but that same git version will not accept the name with a trailing slash through `git update-index --stdin`. Stripping off that final slash character before loading it into our file lists allows git-gui to stage changes to submodules just like any other file. This change should give git-gui users some basic submodule support, but it is strictly at the plumbing level as we do not actually know about calling the git-submodule porcelain that is a recent addition to git 1.5.3. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 September 2007, 00:39:47 UTC
3b9dfde Shawn O. Pearce 10 September 2007, 00:13:10 UTC git-gui: Assume untracked directories are Git submodules If `git ls-files --others` returned us the name of a directory then it is because Git has decided that this directory itself contains a valid Git repository and its files shouldn't be listed as untracked for this repository. In such a case we should label the object as a Git repository and not just as a directory. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 September 2007, 00:39:42 UTC
4ed1a19 Michele Ballabio 09 September 2007, 19:09:07 UTC git-gui: handle "deleted symlink" diff marker Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 23:47:26 UTC
2d19f8e Michele Ballabio 09 September 2007, 19:04:45 UTC git-gui: show unstaged symlinks in diff viewer git-gui has a minor problem with regards to symlinks that point to directories. git init mkdir realdir ln -s realdir linkdir git gui Now clicking on file names in the "unstaged changes" window, there's a problem coming from the "linkdir" symlink: git-gui complains with error reading "file4": illegal operation on a directory ...even though git-gui can add that same symlink to the index just fine. This patch fix this by adding a check. [sp: Minor fix to use {link} instead of "link" in condition and to only open the path if it is not a symlink.] Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 23:47:22 UTC
c63fe3b Shawn O. Pearce 09 September 2007, 03:05:43 UTC git-gui: Avoid use of libdir in Makefile Dmitry V. Levin pointed out that on GNU linux libdir is often used in Makefiles to mean "/usr/lib" or "/usr/lib64", a directory that is meant to hold platform-specific binary files. Using a different libdir meaning here in git-gui's Makefile breaks idomatic expressions like rpm specifile "make libdir=%_libdir". Originally I asked that the git.git Makefile undefine libdir before it calls git-gui's own Makefile but it turns out this is very hard to do, if not impossible. Renaming our libdir to gg_libdir resolves this case with a minimum amount of fuss on our part. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 09:03:12 UTC
cff9339 Shawn O. Pearce 09 September 2007, 03:47:00 UTC git-gui: Disable Tk send in all git-gui sessions The Tk designers blessed us with the "send" command, which on X11 will allow anyone who can connect to your X server to evaluate any Tcl code they desire within any running Tk process. This is just plain nuts. If git-gui wants someone running Tcl code within it then would ask someone to supply that Tcl code to it; waiting for someone to drop any random Tcl code into us is not fantastic idea. By renaming send to the empty name the procedure will be removed from the global namespace and Tk will stop responding to random Tcl evaluation requests sent through the X server. Since there is no facility to filter these requests it is unlikely that we will ever consider enabling this command. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 03:47:10 UTC
0b883ab Gerrit Pape 07 September 2007, 17:16:59 UTC git-gui: lib/index.tcl: handle files with % in the filename properly Steps to reproduce the bug: $ mkdir repo && cd repo && git init Initialized empty Git repository in .git/ $ touch 'foo%3Fsuite' $ git-gui Then click on the 'foo%3Fsuite' icon to include it in a changeset, a popup comes with: 'Error: bad field specifier "F"' Vincent Danjean noticed the problem and also suggested the fix, reported through http://bugs.debian.org/441167 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 03:06:26 UTC
047d94d Shawn O. Pearce 02 September 2007, 19:38:04 UTC git-gui: Properly set the state of "Stage/Unstage Hunk" action Today I found yet another way for the "Stage Hunk" and "Unstage Hunk" context menu actions to leave the wrong state enabled in the UI. The problem this time was that I connected the state determination to the value of $::current_diff_side (the side the diff is from). When the user was last looking at a diff from the index side and unstages everything the diff panel goes empty, but the action stayed enabled as we always assumed unstaging was a valid action. This change moves the logic for determining when the action is enabled away from the individual side selection, as they really are two unrelated concepts. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 September 2007, 03:03:52 UTC
881d8f2 Shawn O. Pearce 02 September 2007, 19:30:26 UTC git-gui: Fix detaching current branch during checkout If the user tried to detach their HEAD while keeping the working directory on the same commit we actually did not completely do a detach operation internally. The problem was caused by git-gui not forcing the HEAD symbolic ref to be updated to a SHA-1 hash when we were not switching revisions. Now we update the HEAD ref if we aren't currently detached or the hashes don't match. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 September 2007, 03:01:44 UTC
6e4ba05 Shawn O. Pearce 02 September 2007, 19:19:07 UTC git-gui: Correct starting of git-remote to handle -w option Current versions of git-remote apparently are passing the -w option to Perl as part of the shbang line: #!/usr/bin/perl -w this caused a problem in git-gui and gave the user a Tcl error with the message: "git-remote not supported: #!/usr/bin/perl -w". The fix for this is to treat the shbang line as a Tcl list and look at the first element only for guessing the executable name. Once we know the executable name we use the remaining elements (if any exist) as arguments to the executable, before the script filename. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 September 2007, 03:01:44 UTC
c80d25d Shawn O. Pearce 25 August 2007, 03:15:50 UTC git-gui: Correct 'git gui blame' in a subdirectory David Kastrup pointed out that the following sequence was not working as we had intended: $ cd lib $ git gui blame console.tcl fatal: cannot stat path lib/console.tcl: No such file or directory The problem here was we disabled the chdir to the root of the working tree when we are running with a "bare allowed" feature such as blame or browser, but we still kept the prefix we found via `git rev-parse --show-prefix`. This caused us to try and look for the file "console.tcl" within the subdirectory but also include the subdirectory's own path from the root of the working tree. This is unlikely to succeed, unless the user just happened to have a "lib/lib/console.tcl" file in the repository, in which case we would produce the wrong result. In the case of a bare repository we shouldn't get back a value from `rev-parse --show-prefix`, so really $_prefix should only be set to the non-empty string if we are in a working tree and we are in a subdirectory of that working tree. If this is true we really want to always be at the top level of the working tree, as all paths are accessed as though they were relative to the top of the working tree. Converting $_prefix to a ../ sequence is a fairly simple approach to moving up the requisite levels. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 August 2007, 03:15:50 UTC
9c9f5fa Shawn O. Pearce 23 August 2007, 06:44:13 UTC git-gui: Do not offer to stage three-way diff hunks into the index git-apply does not accept a patch that was generated as a three-way combined diff format such as we see during merge conflicts. If we get such a diff in our diff viewer and try to send it to git-apply it just errors out and the user is left confused wondering why they cannot stage that hunk. Instead of feeding a known to be unacceptable hunk to git-apply we now just disable the stage/unstage context menu option if the hunk came from a three way diff. The user may still be confused about why they cannot work with a combined diff, but at least they are only confused as to why git-gui is not offering them the action. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 23 August 2007, 06:44:13 UTC
9f4119e Shawn O. Pearce 23 August 2007, 06:39:45 UTC git-gui: Refactor diff pane popup support for future improvements The current popup_diff_menu procedure is somewhat messy as it has a few duplications of the same logic in each of the different legs of the routine. We can simplify these by setting a few state variables in the different legs. No functional change, just a cleanup to make it easier to implement future functional changes within this block. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 23 August 2007, 06:39:45 UTC
875b7c9 Shawn O. Pearce 22 August 2007, 06:41:00 UTC git-gui: Fix "unoptimized loading" to not cause git-gui to crash If the tclsh command was not available to us at the time we were "built" our lib/tclIndex just lists all of our library files and we source all of them at once during startup, rather than trying to lazily load only the procedures we need. This is a problem as some of our library code now depends upon the git-version proc, and that proc is not defined until after the library was fully loaded. I'm moving the library loading until after we have determined the version of git we are talking to, as this ensures that the required git-reversion procedure is defined before any library code can be loaded. Since error_popup is defined in the library we instead use tk_messageBox directly for errors found during the version detection. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 22 August 2007, 06:41:00 UTC
ce015c2 Shawn O. Pearce 21 August 2007, 06:22:53 UTC git-gui: Paper bag fix "Stage Hunk For Commit" in diff context menu In a13ee29b975d3a9a012983309e842d942b2bbd44 I totally broke the "Stage Hunk For Commit" feature by making this menu item always appear in a disabled state, so it was never invokable. A "teaser feature", just sitting there taunting the poor user who has become used to having it available. The issue caused by a13ee was I added a test to look at the data in $file_states, but I didn't do that test correctly as it was always looking at a procedure local $file_states array, which is not defined, so the test was always true and we always disabled the menu entry. Instead we only want to disable the menu entry if the current file we are looking at has no file state information (git-gui is just a very confused little process) or it is an untracked file (and we cannot stage individual hunks). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 August 2007, 06:22:53 UTC
18a01a0 Shawn O. Pearce 20 August 2007, 06:17:05 UTC git-gui: Allow git-merge to use branch names in conflict markers Earlier when I rewrote the merge implementation for git-gui I broke it such that the conflict markers for the "theirs" side of the hunk was using a full SHA-1 ID in hex, rather than the name of the branch the user had merged. This was because I got paranoid and passed off the full SHA-1 to git-merge, instead of giving it the reference name the user saw in the merge dialog. I'd still like to resolve the SHA-1 upfront in git-gui and always use that value throughout the merge, but I can't do that until we have a full implementation of git-merge written in Tcl. Until then its more important that the conflict markers be useful to the end-user, so we need to pass off the ref name and not the SHA-1 ID. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 20 August 2007, 06:17:05 UTC
c6951dd Shawn O. Pearce 20 August 2007, 04:53:04 UTC git-gui: Fix window manager problems on ion3 cehteh on #git noticed that secondary windows such as console windows from push/fetch/merge or the blame browser failed on ion when we tried to open them a second time. The issue turned out to be the fact that on ion [winfo ismapped .] returns false if . is not visible right now because it has been obscured by another window in the same panel. So we need to keep track of whether or not the root window has been displayed for this application, and once it has been we cannot ever assume that ismapped is going to return true. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 20 August 2007, 04:38:13 UTC
51b8c50 Väinö Järvelä 03 August 2007, 09:27:39 UTC git-gui: Added support for OS X right click OS X sends Button-2 on a "real" right click, such as with a three button mouse, or by using the two-finger trackpad click. Signed-off-by: Väinö Järvelä <v@pp.inet.fi> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 August 2007, 06:47:30 UTC
a13ee29 Shawn O. Pearce 03 August 2007, 02:55:22 UTC git-gui: Avoid Tcl error in popup menu on diff viewer If there is no path currently shown in the diff viewer then we were getting Tcl errors anytime the user right-clicked on the diff viewer to bring up its popup menu. The bug here is caused by trying to get the file_state for the empty string; this path is never seen so we never have file_state for it. In such cases we now disable the Stage Hunk For Commit option. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 03 August 2007, 02:55:22 UTC
84f6753 Shawn O. Pearce 30 July 2007, 00:21:54 UTC git-gui: Minor refactoring of merge command line in merge support This is just a small code movement to cleanup how we generate the command line for a merge. I'm only doing it to make the next series of changes slightly more readable. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 30 July 2007, 03:44:52 UTC
dac7089 Shawn O. Pearce 30 July 2007, 01:19:54 UTC git-gui: Use more modern looking icons in the tree browser This is a replacement of all of the icons in our tree browser window, as the prior icons just looked too 1980s Tk-ish. The icons used here are actually from a KDE themed look, so they might actually be familiar to some users of git-gui. Aside from using more modern looking icons we now have a special icon for executable blobs, to make them stand out from the normal non-executable blobs. We also denote symlinks now with a different icon, so they stand out from the other types of objects in the tree. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 30 July 2007, 03:44:52 UTC
37e2199 Shawn O. Pearce 30 July 2007, 00:29:52 UTC git-gui: Don't offer to stage hunks from untracked files If the user looks at an untracked file in our diff pane we used to offer "Stage Hunk For Commit" in the context menu when they right-clicked in that pane. The problem is we don't actually have any diff hunks in untracked files, so there is nothing to really select for staging. So we now grey out the menu item, so the user cannot invoke it and think its broken when it does not perform any useful action. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 30 July 2007, 03:44:51 UTC
95af4d8 Shawn O. Pearce 30 July 2007, 01:26:42 UTC git-gui: Make sure remotes are loaded when picking revisions If we are started for only a blame/browser/citool run we don't usually initialize the list of remotes, or determine which refs are tracking branches and which are local branch heads. This is because some of that work is relatively expensive and is usually not going to be needed if we are started only for a blame, or to make a single commit. However by not loading the remote configuration we were crashing if the user tried to open a browser for another branch through the Repository menu, as our load_all_heads procedure was unable to decide which refs/heads/ items were actually local heads. We now force all remote configuration data to be loaded if we have not done so already and we are trying to create a revision mega widget. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 30 July 2007, 03:44:51 UTC
0fe055c Shawn O. Pearce 29 July 2007, 08:06:51 UTC git-gui: Use progress bar while resetting/aborting files Resetting a large number of files on a slow filesystem can take considerable time, just as switching branches in such a case can take more than two seconds. We now take advantage of the progress meter output by read-tree and show it in the main window status bar, just like we do during checkout (branch switch). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 July 2007, 08:07:13 UTC
94a4dd9 Shawn O. Pearce 29 July 2007, 07:22:27 UTC git-gui: Honor core.excludesfile when listing extra files Recent git versions have a git-status that honors the core.excludesfile configuration option when it reports on untracked files. Unfortunately I missed the introduction of this configuration option in the core porcelain implementation, so it was not reflected here in git-gui. Found and reported by Lars Noschinski <lars@public.noschinski.de>. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 July 2007, 07:22:27 UTC
360cc10 Christian Stimming 28 July 2007, 20:17:10 UTC git-gui: Unify wording to say "to stage" instead of "to add" Also, the warning message when clicking "Reset" is adapted to the wording "Reset" rather than a confusion "Cancel commit?". Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 July 2007, 07:09:07 UTC
1e0a92f Shawn O. Pearce 27 July 2007, 06:30:15 UTC git-gui: Don't kill modified commit message buffer with merge templates If the user is in the middle of a merge and has already started to modify their commit message we were losing the user's changes when they pressed 'Rescan' after resolving issues or making changes in the working directory. The problem here was our background timer that saves the commit message buffer. It marks the commit message buffer as not being modified when it writes it out to disk, so during the rescan we assumed the buffer should be replaced with what we read from the MERGE_MSG file. So we now only read these files from .git if we have a valid backup file. Since we clear it on commit this will only have an impact while the user is actively editing the current commit. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 27 July 2007, 06:30:15 UTC
bc318ea Shawn O. Pearce 25 July 2007, 09:02:38 UTC git-gui: Remove usernames from absolute SSH urls during merging If we are being asked to merge a tracking branch that comes from a remote repository accessed by the very common SSH URL format of "user@host:/path/to/repo" then we really don't need the username as part of the merge message, it only clutters up the history and makes things more confusing. So we instead clip the username part off if the local filesystem path is absolute, as its probably not going to be an ambiguous URL even when it is missing the username. On the other hand we cannot clip the username off if the URL is not absolute, because in such cases (e.g. "user@host:myrepo") the directory that the repository path is resolved in is relative to the user's home directory, and the username becomes important. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 July 2007, 09:02:38 UTC
ead49f5 Shawn O. Pearce 25 July 2007, 08:54:53 UTC git-gui: Format tracking branch merges as though they were pulls If we are merging a tracking branch we know exactly what remote URL that branch is fetched from, and what its name is on that remote repository. In this case we can setup a merge message that looks just like a standard `git-pull $remote $branch` operation by filling out FETCH_HEAD before we start git-merge, and then run git-merge just like git-pull does. I think the result of this behavior is that merges look a lot nicer when the came off of local tracking branches, because they no longer say "commit 'origin/...'" to describe the commit being merged but instead now mention the specific repository we fetched those commits from. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 July 2007, 08:54:53 UTC
9feefbd Shawn O. Pearce 25 July 2007, 08:32:18 UTC git-gui: Cleanup bindings within merge dialog Misc. code cleanups in the merge dialog's binding setup and action button creation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 July 2007, 08:32:18 UTC
350a35f Shawn O. Pearce 25 July 2007, 07:44:50 UTC git-gui: Replace merge dialog with our revision picker widget Now that we only support merging one branch we can offer the user a better user interface experience by allowing them to select the revision they want to merge through our revision picking widget. This change neatly solves the problem of locating a branch out of a sea of 200 tracking branches, and of dealing with very long branch names that all have a common prefix. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 July 2007, 08:23:31 UTC
becafaa Shawn O. Pearce 25 July 2007, 08:20:02 UTC git-gui: Show ref last update times in revision chooser tooltips If we can we now show the last modification date of a loose ref as part of the tooltip information shown in the revision picker. This gives the user an indication of when was the last time that the ref was modified locally, and may especially be of interest when looking at a tracking branch. If we cannot find the loose ref file than we try to fallback on the reflog and scan it for the date of the last record. We don't start with the reflog however as scanning it backwards from the end is not an easy thing to do in Tcl. So I'm being lazy here and just going through the entire file, line by line. Since that is less efficient than a single stat system call, its our fallback strategy. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 July 2007, 08:23:20 UTC
844c3f6 Shawn O. Pearce 25 July 2007, 08:13:00 UTC git-gui: Display commit/tag/remote info in tooltip of revision picker Our revision chooser mega-widget now sets up tooltips for itself so that it displays details about a commit (or a tag and the commit it refers to) when the user mouses over that line in the filtered ref list. If the item is from a remote tracking branch then we also show the remote url and what branch on that remote we fetch from, so the user has a clear concept of where that revision data originated. To help the merge dialog I've also added a new constructor that makes the dialog only offer unmerged revisions (those not in HEAD), as this allows users to avoid performing merges only to get "Already up to date" messages back from core Git. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 July 2007, 08:23:20 UTC
30d1990 Shawn O. Pearce 25 July 2007, 07:27:57 UTC git-gui: Save remote urls obtained from config/remotes setup I'm storing the URLs of any pre-configured remote repositories that we happen to come across so that we can later use these URLs to show to the user in parts of the UI that might care. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 July 2007, 08:23:09 UTC
7d5266a Shawn O. Pearce 22 July 2007, 08:49:06 UTC git-gui: Avoid unnecessary symbolic-ref call during checkout If we are checking out the branch we are already on then there is no need to call symbolic-ref to update the HEAD pointer to the "new" branch name, it is already correct. Currently this situation does not happen very often, but it can be seen in some workflows where the user always recreates their local branch from a remote tracking branch and more-or-less ignores what branch he/she is on right now. As they say, ignorance is bliss. This case will however become a tad more common when we overload checkout_op to actually also perform all of our merges. In that case we will likely see that the branch we want to "checkout" is the current branch, as we are actually just merging into it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 23 July 2007, 05:28:35 UTC
a813988 Shawn O. Pearce 23 July 2007, 05:11:08 UTC git-gui: Refactor current branch menu items to make i18n easier The i18n team has also identified a rather ugly block of code in git-gui that is used to make a pair of Repository menu items show the current branch name. This code is difficult to convert to use [mc ...] to lookup the translation, so I'm refactoring it into a procedure. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 23 July 2007, 05:11:08 UTC
83751fc Shawn O. Pearce 23 July 2007, 04:36:39 UTC git-gui: Refactor diff popup into a procedure to ease i18n work The folks working on the i18n version of git-gui have had some trouble trying to convert these English strings into [mc] calls due to the double evaluation. Moving this block into a standard procedure eliminates the double evaluation, making their work easier. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 23 July 2007, 04:36:39 UTC
9c5a3c7 Shawn O. Pearce 23 July 2007, 04:20:04 UTC git-gui: Paper bag fix quitting crash after commit My earlier introduction of the GITGUI_BCK file (which saves the user's commit message buffer while they are typing it) broke the Quit function. If the user makes a commit we delete the GITGUI_BCK file; if they then immediately quit the application we fail to rename the GITGUI_BCK file to GITGUI_MSG. This is because the file does not exist, but our flag still says it does. The root cause is we did not unset the flag during commit. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 23 July 2007, 04:20:04 UTC
e7d7b1a Shawn O. Pearce 23 July 2007, 04:12:30 UTC git-gui: Clarify meaning of add tracked menu option Junio recently pointed out on the mailing list that our "Add Existing" feature is a lot like `git add -u`, which is generally described as "(Re)Add Tracked Files". This came up during discussion of how to translate "Add Existing" into Japanese, as the individual working on the translation was not quite sure what the option meant and therefore had some trouble selecting the best translation. I'm changing the menu option to "Add Tracked Files To Commit" and the button to "Add Tracked". This should help new users to better understand the actions behind those GUI widgets. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 23 July 2007, 04:12:30 UTC
7bd197c Shawn O. Pearce 22 July 2007, 08:09:53 UTC git-gui: Fix unnecessary fast-forward during checkout If we are trying to checkout a local branch which is matched to a remote tracking branch, but the local branch is newer than the remote tracking branch we actually just want to switch to the local branch. The local branch is "Already up to date". Unfortunately we tossed away the local branch's commit SHA-1 and kept the remote tracking branch's SHA-1, which meant that the user lost the local changes when we updated the working directory. At least we did not update the local branch ref, so the user's data was still intact. We now toss the tracking branch's SHA-1 and replace with the local branch's SHA-1 before the checkout, ensuring that we pass of the right tree to git-read-tree when we update the working directory. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 22 July 2007, 08:09:53 UTC
854ffd3 Shawn O. Pearce 21 July 2007, 20:32:42 UTC git-gui: Completely remove my Tools/Migrate hack This menu option of Tools/Migrate has been living inside of git-gui as a local hack to support some coworkers of mine. It has no value to anyone outside of my day-job team and never really should have been in a release version of git-gui. So I'm pulling it out, so that nobody else has to deal with this garbage. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 22 July 2007, 07:08:34 UTC
54febd4 Shawn O. Pearce 20 July 2007, 08:10:13 UTC git-gui: Internally allow fetch without storing for future pull support This is actually just an underlying code improvement that has no user visible component yet. UI improvements to actually fetch and merge via an arbitrary remote with no tracking branches must still follow to make this change useful for the end-user. Our tracking branch specifications are a Tcl list of three components: - local tracking branch name - remote name/url - remote branch name/tag name This change just makes the first element optional. If it is an empty string we will run the fetch, but have the value be saved only into the special .git/FETCH_HEAD, where we can pick it up and use it for this one time operation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 July 2007, 09:00:37 UTC
dba0741 Shawn O. Pearce 20 July 2007, 07:56:06 UTC git-gui: Skip unnecessary read-tree work during checkout I totally missed this obvious optimization in the checkout code path. If our current repository HEAD is actually at the commit we are moving to, and we agreed to perform this switch earlier, then we have no files to update in the working directory and any stale mtimes are simply not of consequence right now. We can pretend like we ran a read-tree and skip right into the post-read-tree work, such as updating the branch and setting the symbolic-ref. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 July 2007, 09:00:37 UTC
eea1ab6 Shawn O. Pearce 20 July 2007, 07:37:43 UTC git-gui: Simplify error case for unsupported merge types If we are given a merge type we don't understand in checkout_op there is probably a bug in git-gui somewhere that allowed this unknown merge strategy to come into this part of the code path. We currently only recognize three merge types ('none', 'ff' and 'reset') but are going to be supporting more in the future. Rather than keep editing this message I'm going with a very generic "Uh, we don't do that!" type of error. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 July 2007, 09:00:37 UTC
f66b8a6 Shawn O. Pearce 20 July 2007, 07:34:56 UTC git-gui: Factor out common fast-forward merge case In both the ff and reset merge_types supported by checkout_op the result is the same if the merge base of our target commit and the existing commit is the existing commit: its a fast-forward as the existing commit is fully contained in the target commit. This minor cleanup in logic will make it easier to implement a new kind of merge_type that actually merges the two trees with a real merge strategy, such as git-merge-recursive. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 July 2007, 09:00:37 UTC
60f7352 Shawn O. Pearce 20 July 2007, 06:13:24 UTC git-gui: Save the merge base during checkout_op processing I've decided to teach checkout_op how to perform more than just a fast-forward and reset type of merge. This way we can also do a full recursive merge even when we are recreating an existing branch from a remote. To help with that process I'm saving the merge-base we computed during the ff/reset/fail decision process, in case we need it later on when we actually start a true merge operation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 July 2007, 09:00:36 UTC
4578c5c Shawn O. Pearce 21 July 2007, 08:57:57 UTC git-gui: Automatically backup the user's commit buffer A few users have been seeing crashes in Tk when using the undo key binding to undo the last few keystroke events in the commit buffer. Unfortunately that means the user loses their commit message and must start over from scratch when the user restarts the process. git-gui now saves the user's commit message buffer every couple of seconds to a temporary file under .git (specifically .git/GITGUI_BCK). At exit time we rename this file to .git/GITGUI_MSG if there is a message, the file exists, and it is currently synchronized with the Tk buffer. Otherwise we do our usual routine of saving the Tk buffer to .git/GITGUI_MSG and delete .git/GITGUI_BCK, if it exists. During startup we favor .git/GITGUI_BCK over .git/GITGUI_MSG. This way a crash doesn't take out the user's message buffer but instead will cause the user to lose only a few keystrokes. Most people do not type more than 200 WPM, and with 30 possible saves per minute we are unlikely to lose more than 7 words. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 July 2007, 08:57:57 UTC
5dc2cae Shawn O. Pearce 19 July 2007, 06:24:25 UTC git-gui: Completely remove support for creating octopus merges I'm working on refactoring the UI of the merge dialog, because as it currently stands the dialog is absolutely horrible, especially when you have 200+ branches available from a single remote system. In that refactoring I plan on using the choose_rev widget to allow the user to select exactly which branch/commit they want to merge. However since that only selects a single commit I'm first removing the code that supports octopus merges. A brief consultation on #git tonight seemed to indicate that the octopus merge strategy is not as useful as originally thought when it was invented, and that most people don't commonly use them. So making users fall back to the command line to create an octopus is actually maybe a good idea here, as they might think twice before they use it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 19 July 2007, 06:24:25 UTC
a422896 Shawn O. Pearce 19 July 2007, 05:45:42 UTC git-gui: Don't show blame tooltips that we have no data for If we haven't yet loaded any commit information for a given line but our tooltip timer fired and tried to draw the tooltip we shouldn't; there is nothing to show. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 19 July 2007, 05:45:42 UTC
c4638f6 Shawn O. Pearce 19 July 2007, 05:13:29 UTC git-gui: Translate standard encoding names to Tcl ones This is a essentially a copy of Paul Mackerras encoding support from gitk. I stole the code from gitk commit fd8ccbec4f0161, as Paul has already done all of the hard work setting up this translation table. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 19 July 2007, 05:27:17 UTC
d36cd96 Shawn O. Pearce 19 July 2007, 04:43:16 UTC git-gui: Avoid unnecessary global statements when possible Running global takes slightly longer than just accessing the variable via its package name, especially if the variable is just only once in the procedure, or isn't even used at all in the procedure. So this is a minor cleanup for some of our commonly invoked procedures. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 19 July 2007, 04:43:16 UTC
a870ddc Shawn O. Pearce 19 July 2007, 04:39:23 UTC git-gui: Bind Ctrl/Cmd-M to merge action Users who merge often may want to access the merge action quickly, so we now bind M to the merge action. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 19 July 2007, 04:39:23 UTC
dc5ccdc Shawn O. Pearce 18 July 2007, 13:37:27 UTC Don't offer my special Tools/Migrate hack unless in multicommit Users shouldn't see this menu option if they startup a browser or blame from the command line, especially if they are doing so on a bare repository. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 19 July 2007, 03:52:18 UTC
ff749c1 Shawn O. Pearce 18 July 2007, 06:56:44 UTC git-gui: Convert merge dialog to use class system I've found that the class code makes it a whole lot easier to create more complex GUI code, especially the dialogs. So before I make any major improvements to the merge dialog's interface I'm going to first switch it to use the class system, so the code is slightly cleaner. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 06:56:44 UTC
46a2df3 Shawn O. Pearce 18 July 2007, 06:27:39 UTC git-gui: Increase the default height of the revision picker Showing only five lines of heads/tags is not very useful to a user when they have about 10 branches that match the filter expression. The list is just too short to really be able to read easily, at least not without scrolling up and down. Expanding the list out to 10 really makes the revision picker easier to read and access, as you can read the matching branches much more quickly. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 06:27:39 UTC
4040971 Shawn O. Pearce 18 July 2007, 05:48:41 UTC git-gui: Clarify the visualize history menu options Users who are new to Git may not realize that visualizing things in a repository involves looking at history. Adding in a small amount of text to the menu items really helps to understand what the action might do, before you invoke it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 05:48:41 UTC
8e891fa Shawn O. Pearce 18 July 2007, 05:39:27 UTC git-gui: Allow users to browse any branch, not just the current one We now allow users to pick which commit they want to browse through our revision picking mega-widget. This opens up in a dialog first, and then opens a tree browser for that selected commit. It is a very simple approach and requires minimal code changes. I also clarified the language a bit in the Repository menu, to show that these actions will access files. Just in case a user is not quite sure what specific action they are looking for, but they know they want some sort of file thing. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 05:39:27 UTC
85d2d59 Shawn O. Pearce 18 July 2007, 04:53:14 UTC git-gui: Allow browser subcommand to start in subdirectory Like our blame subcommand the browser subcommand now accepts both a revision and a path, just a revision or just a path. This way the user can start the subcommand on any branch, or on any subtree. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 04:53:14 UTC
c52c945 Shawn O. Pearce 18 July 2007, 03:58:56 UTC git-gui: Allow blame/browser subcommands on bare repositories A long time ago Linus Torvalds tried to run git-gui on a bare repository to look at the blame viewer, but it failed to start because we required that the user run us only from within a working directory that had a normal git repository associated with it. This change relaxes that requirement so that you can start the tree browser or the blame viewer against a bare repository. In the latter case we do require that you provide a revision and a pathname if we cannot find the pathname in the current working directory. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 03:58:56 UTC
ba7cc66 Shawn O. Pearce 18 July 2007, 03:23:56 UTC git-gui: Move feature option selection before GIT_DIR init By moving our feature option determination up before we look for GIT_DIR we can make a decision about whether or not we need a working tree up front, before we look for GIT_DIR. A future change could then allow us to start in a bare Git repository if we only need access to the ODB. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 03:23:56 UTC
3972b98 Shawn O. Pearce 18 July 2007, 03:20:56 UTC git-gui: Delay the GC hint until after we are running I'm moving the code related to looking to see if we should GC now into a procedure closer to where it belongs, the database module. This reduces our script by a few lines for the single commit case (aka citool). But really it just is to help organize the code. We now perform the check after we have been running for at least 1 second. This way the main window has time to open up and our dialog (if we open it) will attach to the main window, instead of floating out in no-mans-land like it did before on Mac OS X. I had to use a wait of a full second here as a wait of 1 millisecond made our console install itself into the main window. Apparently we had a race condition with the console code where both the console and the main window thought they were the main window. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 03:20:56 UTC
301dfaa Shawn O. Pearce 18 July 2007, 03:09:31 UTC git-gui: Let the user continue even if we cannot understand git version Some users may do odd things, like tag their own private version of Git with an annotated tag such as 'testver', then compile that git and try to use it with git-gui. In such a case `git --version` will give us 'git version testver', which is not a numeric argument that we can pass off to our version comparsion routine. We now check that the cleaned up git version is a going to pass the version comparsion routine without failure. If it has a non-numeric component, or lacks at least a minor revision then we ask the user to confirm they really want to use this version of git within git-gui. If they do we shall assume it is git 1.5.0 and run with only the code that will support. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 03:09:31 UTC
d164b75 Shawn O. Pearce 18 July 2007, 02:49:44 UTC git-gui: Change our initial GC hint to be an estimate Instead of running a full git-count-objects to count all of the loose objects we can get a reasonably close approximation by counting the number of files in the .git/objects/42 subdirectory. This works out reasonably well because the SHA-1 hash has a fairly even distribution, so every .git/objects/?? subdirectory should get a relatively equal number of files. If we have at least 8 files in .git/objects/42 than it is very likely there is about 8 files in every other directory, leaving us with around 2048 loose objects. This check is much faster, as we need to only perform a readdir of a single directory, and we can do it directly from Tcl and avoid the costly fork+exec. All of the credit on how clever this is goes to Linus Torvalds; he suggested using this trick in a post commit hook to repack every so often. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 02:49:44 UTC
2370164 Shawn O. Pearce 18 July 2007, 02:45:53 UTC git-gui: Don't crash in ask_popup if we haven't mapped main window yet If we have more than our desired number of objects and we try to open the "Do you want to repack now?" dialog we cannot include a -parent . argument if the main window has not been mapped yet. On Mac OS X it appears this window isn't mapped right away, so we had better hang avoid including it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 02:45:53 UTC
6f62b4f Shawn O. Pearce 18 July 2007, 02:31:16 UTC git-gui: Delay searching for 'nice' until its really asked for Not every caller of 'git' or 'git_pipe' wants to use nice to lower the priority of the process its executing. In many cases we may never use the nice process to launch git. So we can avoid searching our $PATH to locate a suitable nice if we'll never actually use it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 02:31:16 UTC
91464df Julian Phillips 17 July 2007, 21:14:06 UTC git-gui: Handle git versions of the form n.n.n.GIT The git-gui version check doesn't handle versions of the form n.n.n.GIT which you can get by installing from an tarball produced by git-archive. Without this change you get an error of the form: 'Error in startup script: expected version number but got "1.5.3.GIT"' Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 July 2007, 01:48:57 UTC
6eb420e Shawn O. Pearce 17 July 2007, 05:50:10 UTC git-gui: Always disable the Tcl EOF character when reading On Windows (which includes Cygwin) Tcl defaults to leaving the EOF character of input file streams set to the ASCII EOF character, but if that character were to appear in the data stream then Tcl will close the channel early. So we have to disable eofchar on Windows. Since the default is disabled on all platforms except Windows, we can just disable it everywhere to prevent any sort of read problem. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 17 July 2007, 05:50:10 UTC
ec4fcee Shawn O. Pearce 16 July 2007, 22:44:23 UTC git-gui: Brown paper bag "dirty git version fix" My prior change to allow git-gui to run with a version of Git that was built from a working directory that had uncommitted changes didn't account for the pattern starting with -, and that confused Tcl. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 July 2007, 22:44:23 UTC
2dfa54c Shawn O. Pearce 16 July 2007, 06:39:07 UTC git-gui: Skip -dirty suffix on core git versions If the user is running a 'dirty' version of git (one compiled in a working directory with modified files) we want to just assume it was a committed version, as we really only look at the part that came from a real annotated tag anyway. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 July 2007, 06:39:07 UTC
b215883 Shawn O. Pearce 12 July 2007, 06:45:23 UTC git-gui: Change prior tree SHA-1 verification to use git_read This cat-file was done on maint, where we did not have git_read available to us. But here on master we do, so we should make use of it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 July 2007, 06:45:23 UTC
f31b6ff Shawn O. Pearce 12 July 2007, 06:40:54 UTC Merge branch 'maint' * maint: git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree} 12 July 2007, 06:40:54 UTC
20f1a10 Shawn O. Pearce 12 July 2007, 06:31:28 UTC git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree} From Johannes Sixt <J.Sixt@eudaptics.com>: > It seems that MSYS's wish does some quoting for Bourne shells, > in particular, escape the first '{' of the "^{tree}" suffix, but > then it uses cmd.exe to run "git rev-parse". However, cmd.exe does > not remove the backslash, so that the resulting rev expression > ends up in git's guts as unrecognizable garbage: rev-parse fails, > and git-gui hickups in a way that it must be restarted. Johannes originally submitted a patch to this section of commit.tcl to use `git rev-parse $PARENT:`, but not all versions of Git will accept that format. So I'm just taking the really simple approach here of scanning the first line of the commit to grab its tree. About the same cost, but works everywhere. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 July 2007, 06:38:14 UTC
264f4a3 Shawn O. Pearce 09 July 2007, 15:10:26 UTC git-gui: Include a space in Cygwin shortcut command lines Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 July 2007, 01:19:22 UTC
6a5955f Shawn O. Pearce 09 July 2007, 15:09:27 UTC git-gui: Use sh.exe in Cygwin shortcuts Because we are trying to execute /bin/sh we know it must be a real Windows executable and thus ends with the standard .exe suffix. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 July 2007, 01:19:22 UTC
5922446 Shawn O. Pearce 09 July 2007, 15:01:02 UTC git-gui: Paper bag fix for Cygwin shortcut creation We cannot execute the git directory, it is not a valid Tcl command name. Instead we just want to pass it as an argument to our sq proc. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 July 2007, 01:19:22 UTC
0a84b3d Shawn O. Pearce 10 July 2007, 01:19:13 UTC Merge branch 'maint' * maint: git-gui: Don't linewrap within console windows git-gui: Correct ls-tree buffering problem in browser 10 July 2007, 01:19:13 UTC
e87fb0f Shawn O. Pearce 09 July 2007, 15:14:00 UTC git-gui: Don't linewrap within console windows If we get more than 80 characters of text in a single line odds are it is output from git-fetch or git-push and its showing a lot of detail off to the right edge that is not so important to the average user. We still want to make sure we show everything we need, but we can get away with that information being off to the side with a horizontal scrollbar. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 July 2007, 01:13:26 UTC
56e29f5 Shawn O. Pearce 09 July 2007, 15:55:45 UTC git-gui: Correct ls-tree buffering problem in browser Our file browser was showing bad output as it did not properly buffer a partial record when read from `ls-tree -z`. This did not show up on my Mac OS X system as most trees are small, the pipe buffers generally big and `ls-tree -z` was generally fast enough that all data was ready before Tcl started to read. However on my Cygwin system one of my production repositories had a large enough tree and packfile that it took a couple of pipe buffers for `ls-tree -z` to complete its dump. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 July 2007, 01:12:35 UTC
7eafa2f Shawn O. Pearce 09 July 2007, 07:28:41 UTC git-gui: Improve the Windows and Mac OS X shortcut creators We now embed any GIT_* and SSH_* environment variables as well as the path to the git wrapper executable into the Mac OS X .app file. This should allow us to restore the environment properly when we restart. We also try to use proper Bourne shell single quoting when we can, as this avoids any sort of problems that might occur due to a path containing shell metacharacters. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 07:38:10 UTC
74c4763 Shawn O. Pearce 09 July 2007, 07:07:05 UTC git-gui: Teach console widget to use git_read Now that we are pretty strict about setting up own absolute paths to any git helper (saving a marginal runtime cost to resolve the tool) we can do the same in our console widget by making sure all console execs go through git_read if they are a git subcommand, and if not make sure they at least try to use the Tcl 2>@1 IO redirection if possible, as it should be faster than |& cat. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 07:07:05 UTC
c136f2b Shawn O. Pearce 09 July 2007, 06:47:33 UTC git-gui: Perform our own magic shbang detection on Windows If we cannot locate a .exe for a git tool that we want to run than it may just be a Bourne shell script as these are popular in Git. In such a case the first line of the file will say "#!/bin/sh" so a UNIX kernel knows what program to start to parse and run that. But Windows doesn't support shbang lines, and neither does the Tcl that comes with Cygwin. We can pass control off to the git wrapper as that is a real Cygwin program and can therefore start the Bourne shell script, but that is at least two fork+exec calls to get the program running. One to do the fork+exec of the git wrapper and another to start the Bourne shell script. If the program is run multiple times it is rather expensive as the magic shbang detection won't be cached across executions. On MinGW/MSYS we don't have the luxury of such magic detection. The MSYS team has taught some of this magic to the git wrapper, but again its slower than it needs to be as the git wrapper must still go and run the Bourne shell after it is called. We now attempt to guess the shbang line on Windows by reading the first line of the file and building our own command line path from it. Currently we support Bourne shell (sh), Perl and Python. That is the entire set of shbang lines that appear in git.git today. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 06:47:33 UTC
70a7595 Shawn O. Pearce 09 July 2007, 06:30:24 UTC git-gui: Treat `git version` as `git --version` We know that the version subcommand of git is special. It does not currently have an executable link installed into $gitexecdir and we therefore would never match it with one of our file exists tests. So we forward any invocations to it directly to the git wrapper, as it is a builtin within that executable. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 06:30:24 UTC
c672989 Shawn O. Pearce 09 July 2007, 06:13:00 UTC git-gui: Assume unfound commands are known by git wrapper 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: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 06:13:00 UTC
02efd48 Shawn O. Pearce 09 July 2007, 06:10:39 UTC git-gui: Correct gitk installation location 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: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 06:10:39 UTC
0b81261 Shawn O. Pearce 09 July 2007, 05:17:09 UTC git-gui: Always use absolute path to all git executables 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: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 05:17:09 UTC
b792230 Shawn O. Pearce 09 July 2007, 02:48:19 UTC git-gui: Show a progress meter for checking out files Sometimes switching between branches can take more than a second or two, in which case `git checkout` would normally have shown a small progress meter to the user on the terminal to let them know that we are in fact working, and give them a reasonable idea of when we may finish. We now do obtain that progress meter from read-tree -v and include it in our main window's status bar. This allows users to see how many files we have checked out, how many remain, and what percentage of the operation is completed. It should help to keep users from getting bored during a large checkout operation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 02:48:19 UTC
51530d1 Shawn O. Pearce 09 July 2007, 02:06:33 UTC git-gui: Change the main window progress bar to use status_bar 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: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 02:34:54 UTC
b29bd5c Shawn O. Pearce 09 July 2007, 02:01:47 UTC git-gui: Extract blame viewer status bar into mega-widget Our blame viewer has had a very fancy progress bar at the bottom of the window that shows the current status of the blame engine, which includes the number of lines completed as both a text and a graphical meter. I want to reuse this meter system in other places, such as during a branch switch where read-tree -v can give us a progress meter for any long-running operation. This change extracts the code and refactors it as a widget that we can take advantage of in locations other than in the blame viewer. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 02:34:53 UTC
827c711 Shawn O. Pearce 09 July 2007, 01:34:28 UTC git-gui: Allow double-click in checkout dialog to start checkout If the user double clicks a branch in the checkout dialog then they probably want to start the checkout process on that branch. I found myself doing this without realizing it, and of course it did nothing as there was no action bound to the listbox's Double-Button-1 event handler. Since I did it without thinking, others will probably also try, and expect the same behavior. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 02:34:53 UTC
84d3d7b Shawn O. Pearce 09 July 2007, 01:29:54 UTC git-gui: Default selection to first matching ref If we have specifications listed in our revision picker mega-widget then we should default the selection within that widget to the first ref available. This way the user does not need to use the spacebar to activate the selection of a ref within the box; instead they can navigate up/down with the arrow keys and be done with it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 02:34:52 UTC
02087ab Shawn O. Pearce 09 July 2007, 01:19:59 UTC git-gui: Unabbreviate commit SHA-1s prior to display 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: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 02:34:51 UTC
d41b43e Shawn O. Pearce 08 July 2007, 22:40:56 UTC git-gui: Refactor branch switch to support detached head 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: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 02:34:46 UTC
699d560 Shawn O. Pearce 06 July 2007, 03:16:13 UTC git-gui: Refactor our ui_status_value update technique 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: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 01:12:57 UTC
311e02a Shawn O. Pearce 05 July 2007, 23:19:37 UTC git-gui: Better handling of detached HEAD 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: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 01:12:56 UTC
back to top