- 22 1月, 2007 13 次提交
-
-
由 Shawn O. Pearce 提交于
If the user has not added any files yet they cannot commit. But telling them this isn't an error, its really just an informational note meant to push the user in the correct direction. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Just like how we split out the local and remote branches into two different pick lists for branch creation, we should do the same thing for branch deletion. This means that there are really 3 modes of operation here: * delete only if merged into designated local branch; * delete only if merged into designated tracking (remote) branch; * delete no matter what So we now use radio buttons to select between these operations. We still default to checking for merge into the current branch, as that is probably the most commonly used behavior. It also is what core Git's command line tools do. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Using a stack of frames in the Starting Revision section of the new branch dialog turned out to be a mess. The varying lengths of each label caused the optionMenu widgets to be spread around the screen at unaligned locations, making the interface very kludgy looking. Now we layout the major sections of the branch dialog using grid rather than pack, allowing these widgets to line up vertically in a nice neat column. All extra space is given to column 1, which is where we have located the text fields. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The new branch name input box was showing up too close to the labelframe border, it was basically right on top of it on Windows. This didn't look right when compared to the Starting Revision's expression input field, as that had a 5 pixel padding. So I've put the new name input box into its own frame and padded that frame by 5 pixels, making the UI more consistent. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Its impossible to commit an index which has unmerged stages. Unfortunately a bug in git-gui allowed the user to try to do exactly that, as we broke out of our file scanning loop as soon as we found a valid AMD index state. That's wrong, as the files are coming back from our array in pseudo-random order; an unmerged file may get returned only after all merged files. I also noticed the grammer around here in our dialog boxes still used the term 'include', so this has been updated to reflect current usage. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Sometimes you want to just force the diff to redisplay itself without rescanning every file in the filesystem (as that can be very costly on large projects and slow operating systems). Now you can force a diff-only refresh from the context menu. Previously you could also do this by reclicking on the file name in the UI, but it may not be obvious to all users, having a context menu option makes it more clear. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
A prior commit tried to use the old index state for the old working directory state during a UI refresh of a file. This caused files which were being unstaged (and thus becoming unmodified) to drop out of the working directory side of the display, at least until the user performed a rescan to force the UI to redisplay everything. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user switches the currently shown file from one side of the UI to the other then how its diff is presented would be different. And leaving the old diff up is downright confusing. Since the diff is probably not interesting to the user after the switch we should just clear the diff viewer. This saves the user time, as they won't need to wait for us to reload the diff. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
We were not correctly setting the old state of an index display to _ if the index was previously unmerged. This caused us to try and update a U->M when resolving a merge conflict but we were unable to do so as the icon did not exist in the index viewer. Tk did not like being asked to modify an icon which was undefined. Now we always transform both the old and the new states for both sides (index and working directory) prior to updating the UI. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that we are using 'git diff' to display unmerged working directory files we are getting 'diff --cc' output rather than 'diff --combined' output. Further the markers in the first two columns actually make sense here, we shouldn't attempt to rewrite them to something else. I've added 'diff --cc *' to the skip list in our diff viewer, as that particular line is not very interesting to display. I've completely refactored how we perform detection of the state of a line during diff parsing; we now report an error message if we don't understand the particular state of any given line. This way we know if we aren't tagging something we maybe should have tagged in the UI. I've also added special display of the standard conflict hunk markers (<<<<<<<, =======, >>>>>>>). These are formatted without a patch op as the patch op is always '+' or '++' (meaning the line has been added relative to the committed state) and are displayed in orange bold text, sort of like the @@ or @@@ marker line is at the start of each hunk. In a 3 way merge diff hunks which came from our HEAD are shown with a azure2 background, and hunks which came from the incoming MERGE_HEAD are displayed with a 'light goldenrod yellow' background. This makes the two different hunks clearly visible within the file. Hunks which are ++ or -- (added or deleted relative to both parents) are shown without any background at all. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If a file has a merge conflict we want it to show up in the 'Changed But Not Updated' file list rather than the 'Changes To Be Committed' file list. This way the user can mostly ignore the left side (the HEAD<->index comparsion) while resolving a merge and instead focus on the merge conflicts, which are just shown on the right hand side. This requires detecting the U state in the index side and drawing it as though it were _, then forcing the working directory side to have a U state. We have to delay this until presentation time as we don't want to change our internal state data to be different from what Git is telling us (I tried, the patch for that was ugly and didn't work). When showing a working directory diff and its a merge conflict we don't want to use diff-files as this would wind up showing any automatically merged hunks obtained from MERGE_HEAD in the diff. These are not usually very interesting as they were completed by the system. Instead we just want to see the conflicts. Fortunately the diff porcelain-ish frontend (aka 'git diff') detects the case of an unmerged file and generates a --cc diff against HEAD and MERGE_HEAD. So we now force any working directory diff with an index state of 'U' to go through that difference path. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The combined diff format can be very confusing, especially to new users who may not even be familiar with a standard two way diff format. So for files which are already staged for commit and which are modifed in the working directory we should show two different diffs, depending on which side the user clicked on. If the user clicks on the "Changes To Be Committed" side then we should show them the PARENT<->index difference. This is the set of changes they will actually commit. If the user clicks on the "Changed But Not Updated" side we should show them the index<->working directory difference. This is the set of changes which will not be committed, as they have not been staged into the index. This is especially useful when merging, as the "Changed But Not Updated" files are the ones that need merge conflict resolution, and the diff here is the conflict hunks and/or any evil merge created by the user. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
We now need to keep track of which side the current diff is for, HEAD<->index or index<->working directory. Consequently we need an additional "current diff" variable to tell us which side the diff is for. Since this is really only necessary in reshow_diff I'm going to declare a new global, rather than try to shove both the path and the side into current_diff. To keep things clear later on, I'm renaming current_diff to current_diff_path. There is no functionality change in this commit. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 21 1月, 2007 27 次提交
-
-
由 Shawn O. Pearce 提交于
If the user asked us to checkout the branch after creating it then we should try to do so. This may fail, especially right now since branch switching from within git-gui is not supported. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Its possible for the user to select a branch for the merge test (while deleting branches) and also select that branch for deletion. Doing so would have bypassed our merge check for that branch, as a branch is always a strict subset of itself. So we will simply skip over a branch and not delete it if that is the branch which the user selected for the merge check. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user is deleting a branch which is fully merged into the selected test branch we should not confirm the delete with them, the fact that the branch is fully merged means we can recover the branch and no work will be lost. If a branch is not fully merged, we should warn the user about which branch(es) that is and continue deleting those which are fully merged. We should only delete a branch if the user disables the merge check, and in that case we should confirm with the user that a delete should occur as this may cause them to lose changes. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The only reason the commit_prehook logic was broken out into its own proc was so it could be invoked after the current set of files that were already added to the commit could be refreshed if 'Allow Partially Added Files' was set to false. Now that we no longer even offer that option to the user there is no reason to keep this code broken out into its own procedure. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that we take the approach of core Git where we allow the user to stage their changes directly into the index all of the time there is absolutely no reason to have the Allow Partially Added Files option, nor is there a reason or desire to default that option to false. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
On Mac OS X wish does not draw borders around text fields, making the field look like its not even there until the user focuses into it. I don't know the Mac OS X UI standards very well, but that just seems wrong. Other applications (e.g. Terminal.app) show their input boxes with a sunken relief, so we should do the same. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Sometimes you want to create a branch from a remote tracking branch. Needing to enter it in the revision expression field is very annoying, so instead let the user select it from a list of known tracking branches. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Most of the time when you are deleting branches you want to delete those which have been merged into your upstream source. Typically that means it has been merged into the tip commit of some tracking branch, and the current branch (or any other head) doesn't matter. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users can now delete a local branch by selecting from a list of available branches. The list automatically does not include the current branch, as deleting the current branch could be quite dangerous and should not be supported. The user may also chose to have us verify the branches are fully merged into another branch before deleting them. By default we select the current branch, matching 'git branch -d' behavior, but the user could also select any other local branch. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Creating branches is a common enough activity within a Git project that we probably should give it a keyboard accelerator. N is not currently used and seems reasonable to stand for "New Branch". To bad our menu calls it create. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users may now create new branches by activating the Branch->Create menu item. This opens a dialog which lets the user enter the new branch name and select the starting revision for the new branch. For the starting revision we allow the user to either select from a list of known heads (aka local branches) or to enter an arbitrary SHA1 expression. For either creation technique we run the starting revision through rev-parse to verify it is valid before trying to create the ref with update-ref. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
It looks horrible to have the cancel and save buttons wedged up against each other in our options dialog. Therefore toss a 5 pixel pad between them. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that our lists represent more defined states it no longer makes any sense to permit a user to make selections from both lists at once, as the each available operation acts only on files whose status corresponds to only one of the lists. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
During unstaging we can simplify the way we perform the output by combining our four puts into a single call. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The list of states which are valid for update-index were a little too verbose and fed a few too many cases to the program. We can do better with less lines of code by using more pattern matching, and since we already were globbing here there's little change in runtime cost. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
We can revert any file which has a valid stage 0 (is not unmerged) and which is has a working directory status of M or D. This vastly simplifies our pattern matching on file status when building up the list of files to perform a checkout-index against. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Rather than relying on the file state and just inverting it, we should look at which file icon the user clicked on. If they clicked on the one in the "Changes To Be Committed" list then they want to unstage the file. If they clicked on the icon in the "Changed But Not Updated" list then they want to add the file to the commit. This should be much more reliable about capturing the user's intent then looking at the file state. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that core Git refers to resetting paths in the index as "unstaging" the paths we should do the same in git-gui, both internally in our code and also within the menu action name. The same follows for our staging logic, as core Git refers to this as 'add'. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Updated the state descriptions for individual file states to try and make them more closely align with what git-runstatus might display. This way a user who is reading Git documentation will be less confused by our descriptions. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The DM state cannot really happen. Its implying that the file has been deleted in the index, but the file in the working directory has been modified relative to the file in the index. This is complete nonsense, the file doesn't exist in the index for it to be different against! Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Apparently my earlier suspicion that the file state DD was a bug was correct. A file which has been deleted from the working directory and from the index will always get the state of D_ during a rescan. Thus the only valid state for this to have is D_. We should always use only D_ internally during our state changes. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This is a rather drastic change to the git-gui user interface, but it doesn't really look any different yet. I've taken the two lists and converted them to being "changes to be committed" and "changed but not updated". These lists correspond to the same lists output by git-runstatus based on how files differ in the HEAD<->index and the index<->working directory comparsions it performs. This change is meant to correlate with the change in Git 1.5.0 where we have brought the index more into the foreground and are trying to teach users to make use of it as part of their daily operations. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'm going to refactor the way file status information gets displayed so it more closely aligns with the way 'git-runstatus' displays the differences between HEAD<->index and index<->working directory. To that end the other file list is going to be changed to be the working directory difference. So this change renames it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user has many git-gui icons it may be confusing when they start one which git-gui is still coming up. So on the windows systems we now include an echo statement which displays the full pathname of the working directory we are trying to enter into. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because we usually say "Operation... please wait..." we should do the same thing when starting gitk. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because it is such a common idiom to use [gitdir] along with [file join] to locate the path of an item within the .git directory of the current repository we might as well allow gitdir to act as a wrapper for the file join operation. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The gitdir global variable is essentially read-only, and is used rather frequently. So are appname and reponame. Needing to constantly declare 'global appname' just so we can access the value as $appname is downright annoying and redundant. So instead I'm declaring these as procedures and changing all uses to invoke the procedure rather than access the global directly. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-