- 25 1月, 2007 4 次提交
-
-
由 Shawn O. Pearce 提交于
Just as we show the amount of disk space taken by the loose objects, its interesting to know how much space is taken by the packs directory. So show that in our Database Statistics dialog. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
In the new branch dialog and delete branch dialog we are using the system default labelframe border settings (whatever those are) and they look reasonable on both Windows and Mac OS X. But for some unknown reason to me I used a raised border for the options dialog. It doesn't look consistent anymore, so I'm switching it to the defaults. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user selects a different branch from the Branch menu, or asks us to create a new branch and immediately checkout that branch we now perform the update of the working directory by way of a 2 way read-tree invocation. This emulates the behavior of `git checkout branch` or the behavior of `git checkout -b branch initrev`. We don't however support the -m style behavior, where a switch can occur with file level merging performed by merge-recursive. Support for this is planned for a future update. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Its nice to know how many loose objects and roughly how much disk space they are taking up, so that you can guestimate about when might be a good time to run 'Compress Database'. The same is true of packfiles, especially once the automatic keep-pack code in git-fetch starts to be more widely used. We now offer the output of count-objects -v in a nice little dialog hung off the Repository menu. Our labels are slightly more verbose than those of `count-objects -v`, so users will hopefully be able to make better sense of what we are showing them here. We probably should also offer pack file size information, and data about *.idx files which exist which lack corresponding *.pack files (a situation caused by the HTTP fetch client). But in the latter case we should only offer the data once we have way to let the user clean up old and inactive index files. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 23 1月, 2007 12 次提交
-
-
由 Shawn O. Pearce 提交于
Git prefers that all log messages are encoding in UTF-8. So now when git-gui generates the commit message it converts the commit message text from the internal Tcl Unicode representation into a UTF-8 file. The file is then fed as stdin to git-commit-tree. I had to start using a file here rather than feeding the message in with << as << uses the system encoding, which we may not want. When we reload a commit message via git-cat-file we are getting the raw byte stream, with no encoding performed by Git itself. So unless the new 'encoding' header appears in the message we should probably assume it is utf-8 encoded; but if the header is present we need to use whatever it claims. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since git operates on filenames using the operating system encoding any data we are receiving from it by way of a pipe, or sending to it by way of a pipe must be formatted in that encoding. This should be the same as the Tcl system encoding, as its the encoding that applications should be using to converse with the operating system. Sadly this does not fix the gitweb/test file in git.git on Macs; that's due to something really broken happening in the filesystem. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This newline is stupid; it doesn't get put here unless the file is very large, and then its just sort of out of place. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users may want to know what a file is before they add it to the repository, especially if its a binary file. So when possible invoke 'file' on the path and try to get its output. Since this is strictly advice to the user we won't bother to report any failures from our attempt to run `file`. Since some file commands also output the path name they were given we look for that case and strip it off the front of the returned output before placing it into the diff viewer. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Our internal diff viewer displays untracked files to help users see if they should become tracked, or not. It is not meant as a full file viewer that handles any sort of input. Consequently it is rather unreasonable for users to expect us to show them very large files. Some users may click on a very big file (and not know its very big) then get surprised when Tk takes a long time to load the content and render it, especially if their memory is tight and their OS starts to swap processes out. Instead we now limit the amount of data we load to the first 128 KiB of any untracked file. If the file is larger than 128 KiB we display a warning message at the top of our diff viewer to notify the user that we are not going to load the entire thing. Users should be able to recognize a file just by its first 128 KiB and determine if it should be added to the repository or not. Since we are loading 128 KiB we may as well scan it to see if the file is binary. So I've removed the "first 8000 bytes" rule and just allowed git-gui to scan the entire data chunk that it read in. This is probably faster anyway if Tcl's [string range] command winds up making a copy of the data. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
A binary file can be very large, and showing the complete content of one is horribly ugly and confusing. So we now use the same rule that core Git uses; if there is a NUL byte (\0) within the first 8000 bytes of the file we assume it is binary and refuse to show the content. Given that we have loaded the entire content of the file into memory we probably could just afford to search the whole thing, but we also probably should not load multi-megabyte binary files either. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we got an empty diff its probably because the modification time of the file was changed but the file content hasn't been changed. Typically this happens because an outside program modified the file and git-gui was told to not run 'update-index --refresh', as the user generally trusts file modification timestamps. But we can also get an empty diff when a program undos a file change and still updates the modification timestamp upon saving, but has undone the file back to the same as what is in the index or in PARENT. So even if gui.trustmtime is false we should still run a rescan on an empty diff. This change also lets us cleanup the dialog message that we show when this case occurs, as its no longer got anything to do with Trust File Modification Timestamps. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If one or both versions of the file don't have a newline at the end of the file we get a line telling us so in the diff output. This shouldn't be tagged, nor should it generate a warning about not being tagged. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Sometimes the Select All action from our context menus doesn't work unless the text field its supposed to act on has focus. I'm not really sure why adding the sel tag requires having focus. It technically should not be required to update the sel tag membership, but perhaps there is a bug in Tcl/Tk 8.4.1 on Windows which is causing this odd behavior. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
We don't want to tag these new file/delete file lines, as they aren't actually that interesting. Its quite clear from the diff itself that the file is a new file or is a deleted file (as the entire thing will appear in the diff). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 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 24 次提交
-
-
由 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 提交于
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>
-