Skip to main content

Browse the archive

Staging
v0.8.1
https://github.com/git/git
23 January 2022, 05:21:09 UTC
sort by:
Revision Author Date Message Commit Date
20ddfca Shawn O. Pearce 29 January 2007, 01:58:47 UTC git-gui: Test for Cygwin differently than from Windows. Running on Cygwin is different than if we were running through MinGW. In the Cygwin case we have cygpath available to us, we need to perform UNIX<->Windows path translation sometimes, and we need to perform odd things like spawning our own login shells to perform network operations. But in the MinGW case these don't occur. Git knows native Windows file paths, and login shells may not even exist. Now git-gui will avoid running cygpath unless it knows its on Cygwin. It also uses a different shortcut type when Cygwin is not present, and it avoids invoking /bin/sh to execute hooks if Cygwin is not present. This latter part probably needs more testing in the MinGW case. This change also improves how we start gitk. If the user is on any type of Windows system its known that gitk won't start right if ~/.gitk exists. So we delete it before starting if we are running on any type of Windows operating system. We always use the same wish executable which launched git-gui to start gitk; this way on Windows we don't have to jump back to /bin/sh just to go into the first wish found in the user's PATH. This should help on MinGW when we probably don't want to spawn a shell just to start gitk. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 06:12:42 UTC
273984f Shawn O. Pearce 29 January 2007, 01:00:36 UTC git-gui: Offer quick access to the HTML formatted documentation. Users may want to be able to read Git documentation, even if they are not command line users. There are many important concepts and terms covered within the standard Git documentation which would be useful to even non command line using people. We now try to offer an 'Online Documentation' menu option within the Help menu. First we try to guess to see what browser the user has setup. We default to instaweb.browser, if set, as this is probably accurate for the user's configuration. If not then we try to guess based on the operating system and the available browsers for each. We prefer documentation which is installed parallel to Git's own executables, e.g. `git --exec-path`/../Documentation/index.html, as that is how I typically install the HTML docs. If those are not found then we open the documentation published on kernel.org. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 06:12:42 UTC
6b90d39 Shawn O. Pearce 27 January 2007, 07:31:01 UTC git-gui: Reword meaning of merge.summary. OK, its official, I'm not reading documentation as well as I should be. Core Git's merge.summary configuration option is used to control the generation of the text appearing within the merge commit itself. It is not (and never has been) used to default the --no-summary command line option, which disables the diffstat at the end of the merge. I completely blame Git for naming two unrelated options almost the exact same thing. But its my own fault for allowing git-gui to confuse the two. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 27 January 2007, 07:31:01 UTC
c539449 Shawn O. Pearce 26 January 2007, 09:43:43 UTC git-gui: Support merge.summary, merge.verbosity. Changed our private merge summary config option to be the same as the merge.summary option supported by core Git. This means setting the "Show Merge Summary" flag in git-gui will have the same effect on the command line. In the same vein I've also added merge.verbosity to the gui options, allowing the user to adjust the verbosity level of the recursive merge strategy. I happen to like level 1 and suggest that other users use that, but level 2 is the core Git default right now so we'll use the same default in git-gui. Unfortunately it appears as though core Git has broken support for the merge.summary option, even though its still in the documentation For the time being we should pass along --no-summary to git-merge if merge.summary is false. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 09:43:43 UTC
729a6f6 Shawn O. Pearce 26 January 2007, 09:16:39 UTC git-gui: Always offer scrollbars for branch lists. Anytime we use a listbox to show branch names its possible for the listbox to exceed 10 entries (actually its probably very common). So we should always offer a scrollbar for the Y axis on these listboxes. I just forgot to add it when I defined them. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 09:16:39 UTC
5f39dbf Shawn O. Pearce 26 January 2007, 09:11:10 UTC git-gui: Don't allow merges in the middle of other things. If the user is in the middle of a commit they have files which are modified. These may conflict with any merge that they may want to perform, which would cause problems if the user wants to abort a bad merge as we wouldn't have a checkpoint to roll back onto. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 09:11:10 UTC
dff7e88 Shawn O. Pearce 26 January 2007, 09:07:34 UTC git-gui: Don't allow users to commit a bad octopus merge. If an octopus merge goes horribly wrong git-merge will leave the working directory and index dirty, but will not leave behind a MERGE_HEAD file for a later commit. Consequently we won't know its a merge commit and instead would let the user resolve the conflicts and commit a single-parent commit, which is wrong. So now if an octopus merge fails we notify the user that the merge did not work, tell them we will reset the working directory, and suggest that they merge one branch at a time. This prevents the user from committing a bad octopus merge. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 09:07:34 UTC
ee3cfb5 Shawn O. Pearce 26 January 2007, 08:58:56 UTC git-gui: Update status bar during a merge. I got slightly confused when I did two merges in a row, as the status bar said "merge completed successfully" while the second merge was still running. Now we show what branches are actively being merged. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 08:58:56 UTC
ce9735d Shawn O. Pearce 26 January 2007, 08:54:05 UTC git-gui: Let users abort with `reset --hard` type logic. If you get into the middle of a merge that turns out to be horrible and just not something you want to do right now, odds are you need to run `git reset --hard` to recover your working directory to a pre-merge state. We now offer Merge->Abort Merge for exactly this purpose, however its also useful to thow away a non-merge, as its basically the same logic as `git reset --hard`. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 08:54:05 UTC
e483483 Shawn O. Pearce 26 January 2007, 08:33:56 UTC git-gui: Implement local merge operations. To allow users to merge local heads and tracking branches we now offer a dialog which lets the user select 1-15 branches and merge them using the stock `git merge` Grand Unified Merge Driver. Originally I had wanted to implement this merge internally within git-gui as I consider GUMD to be mostly Porcelain-ish, but the truth is it does its job exceedingly well and its a relatively complex chunk of code. I'll probably circle back later and try to remove the invocation of GUMD from git-gui, but right now it lets me get the job done faster. Users cannot start a merge if they are currently in the middle of one, or if they are amending a commit. Trying to do either is just stupid and should be stopped as early as possible. I've also made it simple for users to startup a gitk session prior to a merge by offering a Visualize button which runs `gitk $revs --not HEAD`, where $revs is the list of branches currently selected in the merge dialog. This makes it quite simple to find out what the damage will be to the current branch if you were to carry out the currently proposed merge. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 08:33:56 UTC
bc7452f Shawn O. Pearce 26 January 2007, 07:02:09 UTC git-gui: Use builtin version of 'git gc'. Technically the new git-gc command is strictly Porcelain; its invoking multiple plumbing commands to do its work. Since git-gui tries to not rely on Porclain we shouldn't be invoking git-gc directly, instead we should perform its tasks on our own. To make this easy I've created console_chain, which takes a list of tasks to perform and runs them all in the same console window. If any individual task fails then the chain stops running and the window shows a failure bar. Only once all tasks have been completed will it invoke console_done with a successful status. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 07:02:09 UTC
6c3d148 Shawn O. Pearce 26 January 2007, 06:29:00 UTC git-gui: Refactor console success/failure handling. Because I want to be able to run multiple output-producing commands in a single 'console' window within git-gui I'm refactoring the console handling routines to require the "after" argument of console_exec. This should specify a procedure to execute which will receive two args, the first is the console window handle and the second is the status of the last command (0 on failure, 1 on success). A new procedure console_done can be passed to the last console_exec command to forward perform all cleanup and enable the Close button. Its status argument is used to update the final status bar on the bottom of the console window. This isn't any real logic changing, and no new functionality is in this patch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 06:29:00 UTC
b972ea5 Shawn O. Pearce 26 January 2007, 05:49:17 UTC git-gui: Always use -v option to push. Right now `git-push -v` is actually not that verbose; it merely adds the URL it is pushing to. This can be informative if you are pushing to a configured remote, as you may not actually remember what URL that remote is connected to. That detail can be important if the push fails and you attempt to communicate the errors to a 3rd party to help you resolve the issue. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 05:49:17 UTC
86a2af6 Shawn O. Pearce 26 January 2007, 05:47:44 UTC git-gui: Remove no longer used pull from remote code. Because we aren't going to support single click pulling of changes from an existing remote anytime in the near future, I'm moving the code which used to perform that action. Hopefully we'll be able to do something like it in the near-future, but also support local branches just as easily. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 05:47:44 UTC
1d6a978 Shawn O. Pearce 26 January 2007, 04:50:27 UTC git-gui: Added arbitrary branch pushing support. Because its common for some users to push topic branches to a remote repository for review and merging by other parties, users need an easy way to push one or more branches to a remote repository without needing to edit their .git/config file anytime their set of active branches changes. We now provide a basic 'Push...' menu action in the Push menu which opens a dialog allowing the user to select from their set of local branches (refs/heads, minus tracking branches). The user can designate which repository to send the changes to by selecting from an already configured remote or by entering any valid Git URL. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 05:41:01 UTC
156b292 Shawn O. Pearce 26 January 2007, 03:38:59 UTC git-gui: Always use lsearch -exact, to prevent globbing. 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: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 05:41:01 UTC
5f8b70b Shawn O. Pearce 26 January 2007, 02:33:06 UTC git-gui: Maintain the same file list for diff during refresh. 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: Shawn O. Pearce <spearce@spearce.org> 26 January 2007, 05:41:01 UTC
d070c4c Shawn O. Pearce 25 January 2007, 22:07:03 UTC git-gui: Don't switch branches if changing to the current branch. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 22:16:57 UTC
3f7fd92 Shawn O. Pearce 25 January 2007, 22:16:22 UTC git-gui: Remove Pull menu and cleanup Branch/Fetch/Push menus. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 22:16:22 UTC
fb08bac Shawn O. Pearce 25 January 2007, 21:50:15 UTC git-gui: Prefer Tk's entry widget over a 1 line text field. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 21:50:15 UTC
6856767 Shawn O. Pearce 25 January 2007, 18:07:53 UTC git-gui: Pad the database statistics dialog window. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 18:07:53 UTC
5753ef1 Shawn O. Pearce 25 January 2007, 18:01:16 UTC git-gui: Support 'Visualize All Branches' on Mac OS X. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 18:01:16 UTC
23effa7 Shawn O. Pearce 25 January 2007, 17:57:57 UTC git-gui: Force focus to the diff viewer on mouse click. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 17:57:57 UTC
b9a75e3 Shawn O. Pearce 25 January 2007, 17:55:20 UTC git-gui: Unset unnecessary UI setup variable. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 17:55:20 UTC
4e55d19 Shawn O. Pearce 25 January 2007, 17:54:59 UTC git-gui: Cleanup end-of-line whitespace in commit messages. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 17:54:59 UTC
30b14ed Shawn O. Pearce 25 January 2007, 02:30:23 UTC git-gui: Elide CRs appearing in diff output from display. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 05:25:32 UTC
a25c518 Shawn O. Pearce 25 January 2007, 02:20:57 UTC git-gui: Allow staging/unstaging individual diff hunks. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 05:25:32 UTC
86773d9 Shawn O. Pearce 25 January 2007, 01:39:30 UTC git-gui: Only allow Refresh in diff context menu when we have a diff. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 05:25:32 UTC
bb816c5 Shawn O. Pearce 25 January 2007, 00:08:49 UTC git-gui: Display the size of the pack directory. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 05:25:31 UTC
f747133 Shawn O. Pearce 24 January 2007, 22:01:49 UTC git-gui: Use system default labelframe bordering. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 05:25:31 UTC
b5b6b43 Shawn O. Pearce 24 January 2007, 21:51:59 UTC git-gui: Implement basic branch switching through read-tree. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 05:25:31 UTC
0fd49d0 Shawn O. Pearce 24 January 2007, 20:21:01 UTC git-gui: Display database stats (count-objects -v) on demand. 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: Shawn O. Pearce <spearce@spearce.org> 25 January 2007, 05:25:31 UTC
5988527 Shawn O. Pearce 23 January 2007, 09:40:21 UTC git-gui: Handle commit encoding better. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 09:40:21 UTC
51a989b Shawn O. Pearce 23 January 2007, 09:07:18 UTC git-gui: Honor system encoding for filenames. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 09:07:18 UTC
0565246 Shawn O. Pearce 23 January 2007, 08:30:02 UTC git-gui: Remove spurious newline in untracked file display. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 08:30:02 UTC
4e62e27 Shawn O. Pearce 23 January 2007, 08:25:17 UTC git-gui: Don't try to tag the 'Binary files * and * differ' line. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 08:25:17 UTC
d3596fd Shawn O. Pearce 23 January 2007, 08:18:37 UTC git-gui: When possible show the type of an untracked file. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 08:18:37 UTC
19b41e4 Shawn O. Pearce 23 January 2007, 07:33:58 UTC git-gui: Limit display of large untracked files. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 07:33:58 UTC
464c9ff Shawn O. Pearce 23 January 2007, 07:08:09 UTC git-gui: Don't show content of untracked binary files. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 07:08:09 UTC
124355d Shawn O. Pearce 23 January 2007, 03:41:13 UTC git-gui: Always start a rescan on an empty diff. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 06:48:50 UTC
e54a1bd Shawn O. Pearce 23 January 2007, 00:18:39 UTC git-gui: Ignore 'No newline at end of file' marker line. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 06:48:50 UTC
75e78c8 Shawn O. Pearce 22 January 2007, 23:31:12 UTC git-gui: Fix 'Select All' action on Windows. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 06:48:50 UTC
e0c781b Shawn O. Pearce 22 January 2007, 23:24:45 UTC git-gui: Don't attempt to tag new file/deleted file headers in diffs. 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: Shawn O. Pearce <spearce@spearce.org> 23 January 2007, 06:48:49 UTC
46aaf90 Shawn O. Pearce 22 January 2007, 22:10:38 UTC git-gui: Force an update-index --refresh on unchanged files. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 22:10:38 UTC
8ce0316 Shawn O. Pearce 22 January 2007, 04:11:47 UTC git-gui: Don't format the mode line of a diff. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 04:11:47 UTC
f5925d9 Shawn O. Pearce 21 January 2007, 23:00:03 UTC git-gui: Create missing branch head on initial commit. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:59 UTC
c5a1eb8 Shawn O. Pearce 21 January 2007, 22:50:42 UTC git-gui: Slightly tweak new window geometry. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:59 UTC
d4dd034 Shawn O. Pearce 21 January 2007, 22:26:22 UTC git-gui: Update todo list with finished and new items. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:59 UTC
9c10dea Shawn O. Pearce 21 January 2007, 22:22:40 UTC git-gui: Correctly categorize tracking branches and heads. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:59 UTC
4343434 Shawn O. Pearce 21 January 2007, 22:02:25 UTC git-gui: Automatically toggle the relevant radio buttons. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:58 UTC
b36ffe8 Shawn O. Pearce 21 January 2007, 21:43:14 UTC git-gui: Fully select a field when entering into it. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:58 UTC
f250091 Shawn O. Pearce 21 January 2007, 21:37:05 UTC git-gui: Improve keyboard traversal in dialogs. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:58 UTC
c845692 Shawn O. Pearce 21 January 2007, 21:28:59 UTC git-gui: Allow user to specify a branch name pattern. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:57 UTC
e754d6e Shawn O. Pearce 21 January 2007, 20:40:55 UTC git-gui: Give a better error message on an empty branch name. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:57 UTC
19e283f Shawn O. Pearce 21 January 2007, 20:38:09 UTC git-gui: Don't offer tracking branches if none exist. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:57 UTC
3c23697 Shawn O. Pearce 21 January 2007, 19:58:01 UTC git-gui: Never line wrap in file lists. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:57 UTC
ca52156 Shawn O. Pearce 21 January 2007, 19:49:45 UTC git-gui: Make diff viewer colors match gitk's defaults. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:56 UTC
37d2a1c Shawn O. Pearce 21 January 2007, 19:23:51 UTC git-gui: Correctly ignore '* Unmerged path' during diff. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:56 UTC
884fd05 Shawn O. Pearce 21 January 2007, 19:16:40 UTC git-gui: Change rude error popup to info popup. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:56 UTC
15e1374 Shawn O. Pearce 21 January 2007, 19:14:54 UTC git-gui: Improve the merge check interface for branch deletion. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:56 UTC
66cc17d Shawn O. Pearce 21 January 2007, 18:56:38 UTC git-gui: Use a grid layout for branch dialog. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:55 UTC
f8a1518 Shawn O. Pearce 21 January 2007, 18:37:53 UTC git-gui: Pad new branch name input box. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:55 UTC
14efcc7 Shawn O. Pearce 21 January 2007, 18:34:00 UTC git-gui: Correct unmerged file detection at commit time. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:55 UTC
68c30b4 Shawn O. Pearce 21 January 2007, 18:27:43 UTC git-gui: Add Refresh to diff viewer context menu. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:55 UTC
a4b1786 Shawn O. Pearce 21 January 2007, 18:25:06 UTC git-gui: Correct disappearing unstaged files. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:54 UTC
6bdc929 Shawn O. Pearce 21 January 2007, 18:22:26 UTC git-gui: Clear diff from viewer if the side changed. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:54 UTC
079d0d5 Shawn O. Pearce 21 January 2007, 18:18:11 UTC git-gui: Fix bug in unmerged file display. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:54 UTC
fec4a78 Shawn O. Pearce 21 January 2007, 18:12:02 UTC git-gui: Improve diff --cc viewing for unmerged files. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:54 UTC
3b4db3c Shawn O. Pearce 21 January 2007, 17:30:51 UTC git-gui: Improve the display of merge conflicts. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:53 UTC
82cb870 Shawn O. Pearce 21 January 2007, 16:54:16 UTC git-gui: Remove combined diff showing behavior. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:53 UTC
20a53c0 Shawn O. Pearce 21 January 2007, 16:37:58 UTC git-gui: Refactor current_diff -> current_diff_path. 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: Shawn O. Pearce <spearce@spearce.org> 22 January 2007, 03:47:53 UTC
e21594a Shawn O. Pearce 21 January 2007, 09:57:11 UTC git-gui: Attempt to checkout the new branch after creation. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 09:57:11 UTC
3dcdfdf Shawn O. Pearce 21 January 2007, 09:54:01 UTC git-gui: Don't delete the test target branch. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 09:54:01 UTC
4f9d851 Shawn O. Pearce 21 January 2007, 09:51:45 UTC git-gui: Improve the branch delete confirmation dialogs. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 09:51:45 UTC
6858efb Shawn O. Pearce 21 January 2007, 09:28:22 UTC git-gui: Move commit_prehook into commit_tree. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 09:28:22 UTC
6f48f3a Shawn O. Pearce 21 January 2007, 09:19:33 UTC git-gui: Remove 'Allow Partially Added Files' option. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 09:19:33 UTC
62efea1 Shawn O. Pearce 21 January 2007, 08:13:13 UTC git-gui: Use borders on text fields in branch dialog. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 08:13:13 UTC
859d805 Shawn O. Pearce 21 January 2007, 07:27:26 UTC git-gui: Allow creating branches from tracking heads. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:26 UTC
0a25f93 Shawn O. Pearce 21 January 2007, 07:21:45 UTC git-gui: Allow users to delete branches merged upstream. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:26 UTC
887412d Shawn O. Pearce 21 January 2007, 07:14:00 UTC git-gui: Implemented local branch deletion. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:25 UTC
bd29ebc Shawn O. Pearce 21 January 2007, 06:34:55 UTC git-gui: Bind M1-N to create branch. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:25 UTC
c5ab47c Shawn O. Pearce 21 January 2007, 06:31:14 UTC git-gui: Implemented create branch GUI. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:25 UTC
ab26abd Shawn O. Pearce 21 January 2007, 04:52:19 UTC git-gui: Pad the cancel/save buttons in the options window. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:25 UTC
833eda7 Shawn O. Pearce 21 January 2007, 04:46:53 UTC git-gui: Only permit selection in one list at a time. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:24 UTC
31a8d19 Shawn O. Pearce 21 January 2007, 04:35:39 UTC git-gui: Simplify printing of index info to update-index. During unstaging we can simplify the way we perform the output by combining our four puts into a single call. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:24 UTC
b4b491e Shawn O. Pearce 21 January 2007, 04:33:34 UTC git-gui: Refactor the add to commit state filters. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:24 UTC
7d40edf Shawn O. Pearce 21 January 2007, 04:20:17 UTC git-gui: Refactor the revert (aka checkout-index) implementation. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:23 UTC
de5f6d5 Shawn O. Pearce 21 January 2007, 04:10:30 UTC git-gui: Add or unstage based on the specific icon used. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:23 UTC
93e912c Shawn O. Pearce 21 January 2007, 04:07:04 UTC git-gui: Refactor add/remove proc names to align with reality. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:23 UTC
ac39160 Shawn O. Pearce 21 January 2007, 04:00:28 UTC git-gui: Cleanup state descriptions. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:23 UTC
5989a57 Shawn O. Pearce 21 January 2007, 03:58:52 UTC git-gui: Remove invalid DM state. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:22 UTC
b4b2b84 Shawn O. Pearce 21 January 2007, 03:57:19 UTC git-gui: Correct DD file state to be only D_. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:22 UTC
21e409a Shawn O. Pearce 21 January 2007, 03:45:19 UTC git-gui: Convert UI to use 'staged for commit' interface. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:22 UTC
0812665 Shawn O. Pearce 21 January 2007, 03:06:51 UTC git-gui: Start file status display refactoring. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:21 UTC
c2faa43 Shawn O. Pearce 21 January 2007, 03:00:28 UTC git-gui: Display the directory we are entering during startup. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:21 UTC
dccfa67 Shawn O. Pearce 21 January 2007, 02:56:25 UTC git-gui: Make the gitk starting message match our usual format. Because we usually say "Operation... please wait..." we should do the same thing when starting gitk. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:21 UTC
c2758a1 Shawn O. Pearce 21 January 2007, 02:55:05 UTC git-gui: Allow [gitdir ...] to act as [file join [gitdir] ...]. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:21 UTC
c950c66 Shawn O. Pearce 21 January 2007, 02:48:56 UTC git-gui: Cleanup usage of gitdir global variable. 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: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:20 UTC
16d18b8 Shawn O. Pearce 21 January 2007, 02:36:21 UTC git-gui: Refactor reponame computation. We use reponame in a number of locations, and every time its always the same value. Instead of computing this multiple times with code that was copied and pasted around we can compute it once immediately after the global gitdir has been computed and set. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:20 UTC
8ff487c Shawn O. Pearce 21 January 2007, 02:23:21 UTC git-gui: Suggest when running 'git gc' may be worthwhile. Users often forget to repack their object database, then start to complain about how slow it is to perform common operations after they have collected thousands of loose objects in their objects directory. A simple repack usually restores performance. During startup git-gui now asks git-count-objects how many loose objects exist, and if this number exceeds a hardcoded threshold we suggest that the user compress the database (aka run 'git gc') at this time. I've hardcoded this to 2000 objects on non-Windows systems as there the filesystems tend to handle the ~8 objects per directory just fine. On Windows NTFS and FAT are just so slow that we really start to lag when more than 200 loose objects exist, so the hardcoded threshold is much lower there. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 January 2007, 07:54:20 UTC
back to top