- 26 1月, 2007 10 次提交
-
-
由 Shawn O. Pearce 提交于
Anytime we are using lsearch we are doing [lsearch -sorted] and we are applying it to file paths (or file path like things). Its valid for these to contain special glob characters, but when that happens we do not want globbing to occur. Instead we really need exact match semantics. Always supplying -exact to lsearch will ensure that is the case. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I just noticed that a file was always jumping to compare against HEAD and the index during a refresh, even if the diff viewer was comparing the index against the working directory prior to the refresh. The bug turned out to be caused by a foreach loop going through all file list names searching for the path. Since $ui_index was the first one searched and the file was contained in that file list the loop broke out, leaving $w set to $ui_index when it had been set by the caller to $ui_workdir. Silly bug caused by using a parameter as a loop index. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Its pointless to switch to the current branch, so don't do it. We are already on it and the current index and working directory should just be left alone. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The Pull menu as it stands right now is a really horrible idea. Most users will have too many branches show up in this menu, and what with the new globbing syntax for fetch entries we were offering up possible merging that just isn't really valid. So this menu is dead and will be rewritten to support better merge capabilities. The Branch menu shouldn't include a separator entry if there are no branches, it just looks too damn weird. This can happen in an initial repository before any branches have been created and before the first commit. The Fetch and Push menus should just be organized around their own menus rather than being given the menu to populate. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'm a fool and previously used a text widget configured with a height of 1 and special bindings to handle focus traversal rather than the already built (and properly behaved) entry widget. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The stat frame was right on the edge of the window on Mac OS X, making the frame's border blend in with the window border. Not exactly the effect I had in mind. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that recent versions of gitk (shipping with at least git 1.5.0-rc1 and later) actually accept command line revision specifiers without crashing on internal Tk errors we can offer the 'Visualize All Branches' menu item in the Repository menu on Mac OS X. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Apparently a "feature" of Tcl/Tk on Mac OS X is that a disabled text widget cannot receive focus or receive a selection within it. This makes the diff viewer almost useless on that platform as you cannot select individual parts of the buffer. Now we force focus into the diff viewer when its clicked on with button 1. This works around the feature and allows selection to work within the viewer just like it does on other less sane systems, like Microsoft Windows. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When committing changes its useless to have trailing whitespace on the end of a line within the commit message itself; this serves no purpose beyond wasting space in the repository. But it happens a lot on my Mac OS X system if I copy text out of a Terminal.app window and paste it into git-gui. We now clip any trailing whitespace from the commit buffer when loading it from a file, when saving it out to our backup file, or when making the actual commit object. I also fixed a bug where we lost the commit message buffer if you quit without editing the text region. This can happen if you quit and restart git-gui frequently in the middle of an editing session. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 25 1月, 2007 7 次提交
-
-
由 Shawn O. Pearce 提交于
If we are displaying a diff for a DOS-style (CRLF) formatted file then the Tk text widget would normally show the CR at the end of every line; in most fonts this will come out as a square box. Rather than showing this character we'll tag it with a tag which forces the character to be elided away, so its not displayed. However since the character is still within the text buffer we can still obtain it and supply it over to `git apply` when staging or unstaging an individual hunk, ensuring that the file contents is always fully preserved as-is. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Just like `git-add --interactive` we can now stage and unstage individual hunks within a file, rather than the entire file at once. This works on the basic idea of scanning backwards from the mouse position to find the hunk header, then going forwards to find the end of the hunk. Everything in that is sent to `git apply --cached`, prefixed by the diff header lines. We ignore whitespace errors while applying a hunk, as we expect the user's pre-commit hook to catch any possible problems. This matches our existing behavior with regards to adding an entire file with no whitespace error checking. Applying hunks means that we now have to capture and save the diff header lines, rather than chucking them. Not really a big deal, we just needed a new global to hang onto that current header information. We probably could have recreated it on demand during apply_hunk but that would mean we need to implement all of the funny rules about how to encode weird path names (e.g. ones containing LF) into a diff header so that the `git apply` process would understand what we are asking it to do. Much simpler to just store this small amount of data in a global and replay it when needed. I'm making absolutely no attempt to correct the line numbers on the remaining hunk headers after one hunk has been applied. This may cause some hunks to fail, as the position information would not be correct. Users can always refresh the current diff before applying a failing hunk to work around the issue. Perhaps if we ever implement hunk splitting we could also fix the remaining hunk headers. Applying hunks directly means that we need to process the diff data in binary, rather than using the system encoding and an automatic linefeed translation. This ensures that CRLF formatted files will be able to be fed directly to `git apply` without failures. Unfortunately it also means we will see CRs show up in the GUI as ugly little boxes at the end of each line in a CRLF file. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
There is no reason to attempt refreshing an empty diff viewer, so the Refresh option of our diff context menu should be disabled when there is no diff currently shown. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 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 11 次提交
-
-
由 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>
-