- 23 1月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Its possible for external programs to update file modification dates of many files within a repository. I've seen this on Windows with a popular virus scanner, sadly enough. If the user has Trust File Modification Timestamp enabled and the virus scanner touches a large number of files it can be annoying trying to clear them out of the 'Changed But Not Updated' file list by clicking on them one at a time to load the diff. So now we force a rescan as soon as one such file is found, and for just that rescan we disable the Trust File Modification Timestamp option thereby allowing Git to update the modification dates in the index. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 22 1月, 2007 27 次提交
-
-
由 Shawn O. Pearce 提交于
We sometimes see a mode line show up in a diff if the file mode was changed. But its not something we format specially. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we are making an initial commit our branch head did not exist when we scanned for all heads during startup. Consequently we won't have it in our branch menu. So force it to be put there after the ref was created. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I didn't really like the way a new git-gui launched in a new repository as the window geometry wasn't quite the best layou. So this is a minor tweak to try and get space distributed around the window better. By decreasing the widths we're also able to shrink the gui smaller without Tk clipping content at the edge of the window. A nice feature. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Up until now git-gui did not support the new wildcard syntax used to fetch any remote branch into a tracking branch during 'git fetch'. Now if we identify a tracking branch as ending with the string '/*' then we use for-each-ref to print out the reference names which may have been fetched by that pattern. We also now correctly filter any tracking branches out of refs/heads, if they user has placed any there. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When the user selects a starting revision from one of our offered popup lists (local branches or tracking branches) or enters in an expression in the expression input field we should automatically activate the corresponding radio button for them. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user is tabbing through fields in the options dialog they are likely to want to just enter a new value for the field, rather than edit the value in-place. This is easier if we select the entire value upon focusing into the field. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we are in a dialog such as the new branch dialog or our options dialog we should permit the user to traverse around through the available widgets with their Tab/Shift-Tab key combinations. So in any single line text field where we don't want tab characters to actually be inserted into the value rebind Tab and Shift-Tab to honor what the tk_focusPrev and tk_focusNext scripts recommend. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Typically I'm creating all new branches with the same prefix, e.g. 'sp/'. So its handy to be able to setup a repository (or global) level config option for git gui which contains this initial prefix. Once set then git-gui will load it into the new branch name field whenever a new branch is being created. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
New branches must have a name. An empty one is not a valid ref, but the generic message "We do not like '' as a branch name." is just too vague or difficult to read. So detect the missing name early and tell the user it must be entered. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I refactored the common code related to tracking branch listing into a new procedure all_tracking_branches. This saves a few lines and should make the create and delete dialogs easier to maintain. We now don't offer a radio button to create from a tracking branch or merge-check a tracking branch if there are no tracking branches known to git-gui. This prevents us from creating an empty option list and letting the user try to shoot themselves in the foot by asking us to work against an empty initial revision. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Some of my file paths in some of my repositories are very long, this is rather typical in Java projects where the path name contains a deep package structure and then the file name itself is rather long and (hopefully) descriptive. Seeing these paths line wrap in the file lists looks absolutely horrible. The entire rendering is almost unreadable. Now we draw both horizontal and vertical scrollbars for both file lists, and we never line wrap within the list text itself. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because users who use git-gui are likely to also be using gitk, we should at least match gitk's default colors and formatting within the diff viewer. Unfortunately this meant that I needed to change the background colors of the hunks in a 'diff --cc' output, as the green used for 'added line' was completely unreadable on the old color. We now use ivory1 to show hunks which came from HEAD/parent^1, which are the portions that the current branch has contributed, and are probably the user's own changes. We use a very light blue for the portions which came from FETCH_HEAD, as this makes the changes made by the other branch stand out more in the diff. I've also modified the hunk header lines to be blue, as that is how gitk is showing them. Apparently I forgot to raise the sel tag above everything else in the diff viewer, which meant that selections in the diff viewer were not visible if they were made on a 'diff --cc' hunk which had a background. Its now the higest priority tag, ensuring the selection is always visible and readable. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If a path is really unmerged, such as because it has been deleted and also modifed, we cannot obtain a diff for it. Instead Git is sending back '* Unmerged path <blah>' for file <blah>. We should display this line as-is as our tag selecting switches don't recognize it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 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 12 次提交
-
-
由 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>
-