summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2007-07-29git-gui: Make sure remotes are loaded when picking revisionsLibravatar Shawn O. Pearce1-0/+4
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>
2007-07-29git-gui: Use progress bar while resetting/aborting filesLibravatar Shawn O. Pearce1-4/+12
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>
2007-07-29git-gui: Honor core.excludesfile when listing extra filesLibravatar Shawn O. Pearce1-0/+4
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>
2007-07-29git-gui: Unify wording to say "to stage" instead of "to add"Libravatar Christian Stimming5-14/+18
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>
2007-07-27git-gui: Don't kill modified commit message buffer with merge templatesLibravatar Shawn O. Pearce1-2/+3
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>
2007-07-25git-gui: Remove usernames from absolute SSH urls during mergingLibravatar Shawn O. Pearce1-0/+3
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>
2007-07-25git-gui: Format tracking branch merges as though they were pullsLibravatar Shawn O. Pearce1-4/+28
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>
2007-07-25git-gui: Cleanup bindings within merge dialogLibravatar Shawn O. Pearce1-5/+9
Misc. code cleanups in the merge dialog's binding setup and action button creation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-07-25git-gui: Replace merge dialog with our revision picker widgetLibravatar Shawn O. Pearce1-70/+11
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>
2007-07-25git-gui: Show ref last update times in revision chooser tooltipsLibravatar Shawn O. Pearce1-1/+33
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>
2007-07-25git-gui: Display commit/tag/remote info in tooltip of revision pickerLibravatar Shawn O. Pearce1-6/+230
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>
2007-07-25git-gui: Save remote urls obtained from config/remotes setupLibravatar Shawn O. Pearce1-0/+6
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>
2007-07-23git-gui: Avoid unnecessary symbolic-ref call during checkoutLibravatar Shawn O. Pearce1-14/+16
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>
2007-07-23git-gui: Refactor current branch menu items to make i18n easierLibravatar Shawn O. Pearce1-2/+11
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>
2007-07-23git-gui: Refactor diff popup into a procedure to ease i18n workLibravatar Shawn O. Pearce1-9/+11
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>
2007-07-23git-gui: Paper bag fix quitting crash after commitLibravatar Shawn O. Pearce1-1/+1
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>
2007-07-23git-gui: Clarify meaning of add tracked menu optionLibravatar Shawn O. Pearce1-2/+2
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>
2007-07-22git-gui: Fix unnecessary fast-forward during checkoutLibravatar Shawn O. Pearce1-0/+1
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>
2007-07-22git-gui: Completely remove my Tools/Migrate hackLibravatar Shawn O. Pearce1-29/+0
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>
2007-07-21git-gui: Internally allow fetch without storing for future pull supportLibravatar Shawn O. Pearce1-3/+11
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>
2007-07-21git-gui: Skip unnecessary read-tree work during checkoutLibravatar Shawn O. Pearce1-1/+3
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>
2007-07-21git-gui: Simplify error case for unsupported merge typesLibravatar Shawn O. Pearce1-1/+1
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>
2007-07-21git-gui: Factor out common fast-forward merge caseLibravatar Shawn O. Pearce1-25/+21
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>
2007-07-21git-gui: Save the merge base during checkout_op processingLibravatar Shawn O. Pearce1-5/+5
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>
2007-07-21git-gui: Automatically backup the user's commit bufferLibravatar Shawn O. Pearce2-11/+81
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>
2007-07-19git-gui: Completely remove support for creating octopus mergesLibravatar Shawn O. Pearce1-68/+17
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>
2007-07-19git-gui: Don't show blame tooltips that we have no data forLibravatar Shawn O. Pearce1-0/+5
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>
2007-07-19git-gui: Translate standard encoding names to Tcl onesLibravatar Shawn O. Pearce3-11/+304
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>
2007-07-19git-gui: Avoid unnecessary global statements when possibleLibravatar Shawn O. Pearce1-7/+4
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>
2007-07-19git-gui: Bind Ctrl/Cmd-M to merge actionLibravatar Shawn O. Pearce1-2/+4
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>
2007-07-18Don't offer my special Tools/Migrate hack unless in multicommitLibravatar Shawn O. Pearce1-1/+3
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>
2007-07-18git-gui: Convert merge dialog to use class systemLibravatar Shawn O. Pearce1-41/+65
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>
2007-07-18git-gui: Increase the default height of the revision pickerLibravatar Shawn O. Pearce1-1/+1
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>
2007-07-18git-gui: Clarify the visualize history menu optionsLibravatar Shawn O. Pearce1-3/+3
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>
2007-07-18git-gui: Allow users to browse any branch, not just the current oneLibravatar Shawn O. Pearce2-2/+58
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>
2007-07-18git-gui: Allow browser subcommand to start in subdirectoryLibravatar Shawn O. Pearce2-29/+27
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>
2007-07-17git-gui: Allow blame/browser subcommands on bare repositoriesLibravatar Shawn O. Pearce1-13/+32
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>
2007-07-17git-gui: Move feature option selection before GIT_DIR initLibravatar Shawn O. Pearce1-37/+37
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>
2007-07-17git-gui: Delay the GC hint until after we are runningLibravatar Shawn O. Pearce2-28/+30
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>
2007-07-17git-gui: Let the user continue even if we cannot understand git versionLibravatar Shawn O. Pearce1-0/+27
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>
2007-07-17git-gui: Change our initial GC hint to be an estimateLibravatar Shawn O. Pearce1-5/+14
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>
2007-07-17git-gui: Don't crash in ask_popup if we haven't mapped main window yetLibravatar Shawn O. Pearce1-2/+5
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>
2007-07-17git-gui: Delay searching for 'nice' until its really asked forLibravatar Shawn O. Pearce1-13/+15
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>
2007-07-17git-gui: Handle git versions of the form n.n.n.GITLibravatar Julian Phillips1-0/+1
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>
2007-07-17git-gui: Always disable the Tcl EOF character when readingLibravatar Shawn O. Pearce4-1/+5
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>
2007-07-16git-gui: Brown paper bag "dirty git version fix"Libravatar Shawn O. Pearce1-1/+1
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>
2007-07-16git-gui: Skip -dirty suffix on core git versionsLibravatar Shawn O. Pearce1-0/+1
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>
2007-07-12git-gui: Change prior tree SHA-1 verification to use git_readLibravatar Shawn O. Pearce1-1/+1
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>
2007-07-12Merge branch 'maint'Libravatar Shawn O. Pearce1-1/+12
* maint: git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}
2007-07-12git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}Libravatar Shawn O. Pearce1-1/+12
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>