Skip to main content

Browse the archive

Staging
v0.5.1
https://github.com/git/git
23 January 2022, 05:21:09 UTC
sort by:
Revision Author Date Message Commit Date
51bd9d7 Shawn O. Pearce 26 February 2007, 16:47:14 UTC git-gui: Don't create empty (same tree as parent) commits. Mark Levedahl noticed that git-gui will let you create an empty normal (non-merge) commit if the file state in the index is out of whack. The case Mark was looking at was with the new autoCRLF feature in git enabled and is actually somewhat difficult to create. I found a different way to create an empty commit: turn on the Trust File Modifications flag, touch a file, rescan, then move the file into the "Changes To Be Committed" list without looking at the file's diff. This makes git-gui think there are files staged for commit, yet the update-index call did nothing other than refresh the stat information for the affected file. In this case git-gui allowed the user to make a commit that did not actually change anything in the repository. Creating empty commits is usually a pointless operation; rarely does it record useful information. More often than not an empty commit is actually an indication that the user did not properly update their index prior to commit. We should help the user out by detecting this possible mistake and guiding them through it, rather than blindly recording it. After we get the new tree name back from write-tree we compare it to the parent commit's tree; if they are the same string and this is a normal (non-merge, non-amend) commit then something fishy is going on. The user is making an empty commit, but they most likely don't want to do that. We now pop an informational dialog and start a rescan, aborting the commit. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 February 2007, 16:47:14 UTC
fd234df Shawn O. Pearce 26 February 2007, 16:22:10 UTC git-gui: Add Reset to the Branch menu. cehteh on #git noticed that there was no way to perform a reset --hard from within git-gui. When I pointed out this was Merge->Abort Merge cehteh said this is not very understandable, and that most users would never guess to try that option unless they were actually in a merge. So Branch->Reset is now also a way to cause a reset --hard from within the UI. Right now the confirmation dialog is the same as the one used in Merge->Abort Merge. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 February 2007, 16:22:10 UTC
9b28a8b Shawn O. Pearce 26 February 2007, 16:17:11 UTC git-gui: Relocate the menu/transport menu code. This code doesn't belong down in the main window UI creation, its really part of the menu system and probably should be located with it. I'm moving it because I could not find the code when I was looking for it earlier today, as it was not where I expected it to be found. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 February 2007, 16:17:11 UTC
92446ab Junio C Hamano 25 February 2007, 07:18:11 UTC Don't modify CREDITS-FILE if it hasn't changed. We should always avoid rewriting a built file during `make install` if nothing has changed since `make all`. This is to help support the typical installation process of compiling a package as yourself, then installing it as root. Forcing CREDITS-FILE to be always be rebuilt in the Makefile means that CREDITS-GEN needs to check for a change and only update CREDITS-FILE if the file content actually differs. After all, content is king in Git. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 February 2007, 07:18:26 UTC
9811937 Shawn O. Pearce 21 February 2007, 06:33:59 UTC git-gui: Don't crash in citool mode on initial commit. Attempting to use `git citool` to create an initial commit caused git-gui to crash with a Tcl error as it tried to add the newly born branch to the non-existant branch menu. Moving this code to after the normal commit cleanup logic resolves the issue, as we only have a branch menu if we are not in singlecommit mode. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 06:33:59 UTC
7391b2e Shawn O. Pearce 21 February 2007, 06:29:05 UTC git-gui: Remove TODO list. I'm apparently not very good at keeping my own TODO file current. I its also somewhat strange to keep the TODO list as part of the software branch, as its meta-information that is not directly related to the code. I'm pulling the TODO list from git-gui and moving it into a seperate branch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 06:29:05 UTC
c0f7a6c Shawn O. Pearce 21 February 2007, 06:24:57 UTC git-gui: Include browser in our usage message. Now that the 'browser' subcommand can be used to startup the tree browser, it should be listed as a possible subcommand option in our usage message. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 06:24:57 UTC
019f42a Shawn O. Pearce 19 February 2007, 02:08:04 UTC git-gui: Change summary of git-gui. Since git-gui does more than create commits, it is unfair to call it "a commit creation tool". Instead lets just call it a graphical user interface. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 05:11:02 UTC
871f4c9 Shawn O. Pearce 19 February 2007, 02:06:48 UTC git-gui: Display all authors of git-gui. Now that git-gui has been released to the public as part of Git 1.5.0 I am starting to see some work from other people beyond myself and Paul. Consequently the copyright for git-gui is not strictly the two of us anymore, and these others deserve to have some credit given to them. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 05:11:01 UTC
ee40599 Shawn O. Pearce 19 February 2007, 00:06:09 UTC git-gui: Use mixed path for docs on Cygwin. The Firefox browser requires that a URL use / to delimit directories. This is instead of \, as \ gets escaped by the browser into its hex escape code and then relative URLs are incorrectly resolved, Firefox no longer sees the directories for what they are. Since we are handing the browser a true URL, we better use the standard / for directories. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 05:11:01 UTC
372ef95 Shawn O. Pearce 18 February 2007, 07:12:32 UTC git-gui: Correct crash when saving options in blame mode. Martin Waitz noticed that git-gui crashed while saving the user's options out if the application was started in blame mode. This was caused by the do_save_config procedure invoking reshow_diff incase the number of context lines was modified by the user. Because we bypassed main window UI setup to enter blame mode we did not set many of the globals which were accessed by reshow_diff, and reading unset variables is an error in Tcl. Aside from moving the globals to be set earlier, I also modified reshow_diff to not invoke clear_diff if there is no path currently in the diff viewer. This way reshow_diff does not crash when in blame mode due to the $ui_diff command not being defined. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 February 2007, 07:12:32 UTC
b90d479 Shawn O. Pearce 16 February 2007, 05:24:03 UTC git-gui: Expose the browser as a subcommand. Some users may find being able to browse around an arbitrary branch to be handy, so we now expose our graphical browser through `git gui browse <committish>`. Yes, I'm being somewhat lazy and making the user give us the name of the branch to browse. They can always enter HEAD. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 February 2007, 05:24:03 UTC
101e3ae Martin Koegler 15 February 2007, 06:28:34 UTC git-gui: Create new branches from a tag. I'm missing the possibility to base a new branch on a tag. The following adds a tag drop down to the new branch dialog. Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 15 February 2007, 06:34:40 UTC
26370f7 Shawn O. Pearce 14 February 2007, 06:55:16 UTC git-gui: Prefer version file over git-describe. Some distributions are using Git for part of their package management system, but unpack Git's own source code for delivery from the .tar.gz. This means that when we walk up the directory tree with git-describe to locate a Git repository, the repository we find is for the distribution and *not* for git-gui. Consequently any tag we might find there is bogus and does not apply to us. In this case the version file should always exist and be readable, as the packager is working from the released .tar.gz sources. So we should always favor the version file over anything git-describe guess for us. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 06:55:16 UTC
ed3adde Shawn O. Pearce 14 February 2007, 05:28:00 UTC git-gui: Print version on the console. Like `git version`, `git gui version` (or `git gui --version`) shows the version of git-gui, in case the user needs to know this, without looking at it in the GUI about dialog. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 05:28:00 UTC
5ac58f5 Shawn O. Pearce 14 February 2007, 05:10:20 UTC git-gui: More consistently display the application name. I started to find it confusing that git-gui would refer to itself as git-citool when it was started through the citool hardlink, or with the citool subcommand. What was especially confusing was the options dialog and the about dialog, as both seemed to imply they were somehow different from the git-gui versions. In actuality there is no difference at all. Now we just call our options menu item 'Options...' (skipping the application name) and our About dialog now always shows git-gui within the short description (above the copyleft notice) and in the version field. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 05:10:20 UTC
cdf6e08 Shawn O. Pearce 14 February 2007, 04:43:48 UTC git-gui: Permit merging tags into the current branch. It was pointed out on the git mailing list by Martin Koegler that we did not show tags as possible things to merge into the current branch. They actually are, and core Git's Grand Unified Merge Driver will accept them just like any other commit. So our merge dialog now requests all refs/heads, refs/remotes and refs/tags named refs and attempts to match them against the commits not in HEAD. One complicating factor here is that we must use the %(*objectname) field when talking about an annotated tag, as they will not appear in the output of rev-list. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 04:43:48 UTC
54acdd9 Shawn O. Pearce 14 February 2007, 04:15:25 UTC git-gui: Basic version check to ensure git 1.5.0 or later is used. This is a very crude (but hopefully effective) check against the `git` executable found in our PATH. Some of the subcommands and options that git-gui requires to be present to operate were created during the 1.5.0 development cycle, so 1.5 is the minimum version of git that we can expect to support. There actually are early releases of 1.5 (e.g. 1.5.0-rc0) that don't have everything we expect (like `blame --incremental`) but these are purely academic at this point. 1.5.0 final was tagged and released just a few hours ago. The release candidates will (hopefully) fade into the dark quickly. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 04:15:25 UTC
8134722 Shawn O. Pearce 13 February 2007, 03:48:56 UTC git-gui: Refactor 'exec git subcmd' idiom. As we frequently need to execute a Git subcommand and obtain its returned output we are making heavy use of [exec git foo] to run foo. As I'm concerned about possibly needing to carry environment data through a shell on Cygwin for at least some subcommands, I'm migrating all current calls to a new git proc. This actually makes the code look cleaner too, as we aren't saying 'exec git' everywhere. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 02:32:52 UTC
022fef3 Andy Parkins 13 February 2007, 15:26:16 UTC git-gui: fix typo in GIT-VERSION-GEN, "/dev/null" not "/devnull" Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 13 February 2007, 15:35:58 UTC
fdf6cfc Shawn O. Pearce 12 February 2007, 22:45:21 UTC git-gui: Change base version to 0.6. This is the start of the 0.6 series of git-gui. I'm calling it 0.6 (rather than any other value) as I already had a private tag on one system based on 0.5, and that tag is quite a bit behind this version. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 22:45:21 UTC
07d082b Shawn O. Pearce 12 February 2007, 22:05:10 UTC git-gui: Guess our version accurately as a subproject. When we are included as a subproject, such as how git.git carries us, we want to retain our own version number and not the version number assigned by git.git's own tags. Consequently we need to locate the correct tag which applies to our tree content and its commit lineage. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 22:05:10 UTC
6a6459b Shawn O. Pearce 12 February 2007, 21:38:29 UTC git-gui: Handle gitgui tags in version gen. I've decided to use gitgui-0.5 as the format for tags in the git-gui repository. The prefix of gitgui was chosen here to make its namespace different from the namespace used by git itself, allowing developers to pull both tag namespaces into the same repository. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 21:38:29 UTC
5d643cd Shawn O. Pearce 12 February 2007, 21:14:44 UTC git-gui: Generate a version file on demand. Because git-gui is being shipped as a subproject of the main Git project and will often have a different lifecycle than the main Git project, we should ship our own version number in the release tarball rather than relying on the main Git version file. Git's master Makefile will invoke our own with the target dist-version, asking us to save off our GITGUI_VERSION value into our own version file, so that our GIT-VERSION-GEN script can recover it at build time. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 21:14:44 UTC
7e81d4e Shawn O. Pearce 12 February 2007, 21:12:04 UTC git-gui: Rename GIT_VERSION to GITGUI_VERSION. Now that the decision has been made to treat git-gui as a subproject, rather than merging it directly into git, we should use a different substitution for our version value to avoid any possible confusion. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 21:12:04 UTC
663e7cf Shawn O. Pearce 12 February 2007, 20:37:50 UTC git-gui: Allow gitexecdir, INSTALL to be set by the caller. When used as a subproject within git.git our Makefile must honor the gitexecdir which git.git's Makefile is passing down to us, ensuring that we install our executables into the libexec chosen by the end-user or packager. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 20:37:50 UTC
0960f7d Shawn O. Pearce 11 February 2007, 22:19:38 UTC git-gui: Stop deleting gitk preferences. Now that git 1.5.0 and later contains a version of gitk that uses correct geometry on Windows platforms, even if ~/.gitk exists, we should not delete the user's ~/.gitk to work around the bug. It is downright mean to remove a user's preferences for another app. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 11 February 2007, 22:19:38 UTC
d585e78 Shawn O. Pearce 09 February 2007, 07:28:32 UTC git-gui: Focus into blame panels on Mac OS. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 07:28:32 UTC
486ef52 Shawn O. Pearce 09 February 2007, 06:59:38 UTC git-gui: Improve annotated file display. Rather than trying to mark the background color of the line numbers to show which lines have annotated data loaded, we now show a ruler between the line numbers and the file data. This ruler is just 1 character wide and its background color is set to grey to denote which lines have annotation ready. I had to make this change as I kept loosing the annotation marker when a line was no longer colored as part of the current selection. We now color the lines blamed on the current commit in yellow, the lines in the commit which came after (descendant) in red (hotter, less tested) and the lines in the commit before (ancestor) in blue (cooler, better tested). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 06:59:38 UTC
1351ba1 Shawn O. Pearce 09 February 2007, 03:41:51 UTC git-gui: Jump to the first annotation block as soon as its available. To help clue users into the fact that annotation data arrives incrementally, and that they should try to locate the region they want while the tool is running, we jump to the first line of the first annotation if the user has not already clicked on a line they are interested in and if the window is still looking at the very top of the file. Since it takes a second (at least on my PowerBook) to even generate the first annotation for git-gui.sh, the user should have plenty of time to adjust the scrollbar or click on a line even before we get that first annotation record in, which allows the user to bypass our automatic jumping. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 03:41:51 UTC
6910ae8 Shawn O. Pearce 09 February 2007, 02:39:27 UTC git-gui: Redesign the display of annotated files. Using 180 columns worth of screen space to display just 20 columns of file data and 160 columns worth of annotation information is not practically useful. Users need/want to see the file data, and have the anotation associated with it displayed in a detail pane only when they have focused on a particular region of the file. Now our file viewer has a small 10-line high pane below the file which shows the commit message for the commit this line was blamed on. The columns have all been removed, except the current line number column as that has some real value when trying to locate an interesting block. To keep the user entertained we have a progress meter in the status bar of the viewer which lets them know how many lines have been annotated, and how much has been completed. We use a grey background on the line numbers for lines which we have obtained annotation from, and we color all lines in the current commit with a yellow background, so they stand out when scanning through the file. All other lines are kept with a white background, making the yellow really pop. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 02:39:27 UTC
df6287e Shawn O. Pearce 09 February 2007, 00:53:36 UTC git-gui: Use git-config now over git-repo-config. Now that core Git has "renamed" git-repo-config to git-config, we should do the same. I don't know how long core Git will keep the repo-config command, and since git-gui's userbase is so small and almost entirely on some flavor of 1.5.0-rc2 or later, where the rename has already taken place, it should be OK to rename now. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 00:53:36 UTC
24d2bf2 Shawn O. Pearce 09 February 2007, 00:44:49 UTC git-gui: Relabel the Add All action. One user that I spoke with recently was confused why the 'Add All' button did not add all of his 'Changed But Not Updated' files. The particular files in question were new, and thus not known to Git. Since the 'Add All' routine only updates files which are already tracked, they were not added automatically. I suspect that calling this action 'Add Existing' would be less confusing, so I'm renaming it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 00:44:49 UTC
258871d Shawn O. Pearce 09 February 2007, 00:41:32 UTC git-gui: Select subcommands like git does. If we are invoked as `git-foo`, then we should run the `foo` subcommand, as the user has made some sort of link from `git-foo` to our actual program code. So we should honor their request. If we are invoked as `git-gui foo`, the user has not made a link (or did, but is not using it right now) so we should execute the `foo` subcommand. We now can start the single commit UI mode via `git-citool` and also through `git gui citool`. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 00:41:32 UTC
2ebba52 Shawn O. Pearce 09 February 2007, 00:10:52 UTC git-gui: View blame from the command line. Viewing annotated files is one of those tasks that is relatively difficult to do in a simple vt100 terminal emulator. The user really wants to be able to browse through a lot of information, and to interact with it by navigating through revisions. Now users can start our file viewer with annotations by running 'git gui blame commit path', thereby seeing the contents of the given file at the given commit. Right now I am being lazy by not allowing the user to omit the commit name (and have us thus assume HEAD). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 00:10:52 UTC
db7f34d Shawn O. Pearce 08 February 2007, 22:47:17 UTC git-gui: Optionally save commit buffer on exit. If the commit area does not exist, don't save the commit message to a file, or the window geometry. The reason I'm doing this is I want to make the main window entirely optional, such as if the user has asked us to show a blame from the command line. In such cases the commit area won't exist and trying to get its text would cause an error. If we are running without the commit message area, we cannot save our window geometry either, as the root window '.' won't be a normal commit window. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 23:14:44 UTC
64a906f Shawn O. Pearce 08 February 2007, 23:10:05 UTC git-gui: Separate transport/branch menus from multicommit. These are now controlled by the transport and branch options, rather than the multicommit option. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 23:10:05 UTC
cf25ddc Shawn O. Pearce 08 February 2007, 23:03:41 UTC git-gui: Refactor single_commit to a proc. This is a minor code cleanup to make working with what used to be the $single_commit flag easier. Its also to better handle various UI configurations, depending on command line parameters given by the user, or perhaps user preferences. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 23:03:41 UTC
42b922f Shawn O. Pearce 08 February 2007, 22:13:51 UTC git-gui: Replace \ with \\ when showing paths. We already replace \n with \\n so that Tk widgets don't start a new display line with part of a file path which is just unlucky enough to contain an LF. But then its confusing to read a path whose name actually contains \n as literal characters. Escaping \ to \\ would make that case display as \\n, clarifying the output. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 22:13:51 UTC
9bccb78 Shawn O. Pearce 08 February 2007, 22:07:59 UTC git-gui: Support keyboard traversal in browser. Users want to navigate the file list shown in our branch browser windows using the keyboard. So we now support basic traversal with the arrow keys: Up/Down: Move the "selection bar" to focus on a different name. Return: Move into the subtree, or open the annotated file. M1-Right: Ditto. M1-Up: Move to the parent tree. M1-Left: Ditto. Probably the only feature missing from this is to key a leading part of the file name and jump directly to that file (or subtree). This change did require a bit of refactoring, to pull the navigation logic out of the mouse click procedure and into more generic routines which can also be used in bindings. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 22:07:59 UTC
63faf4d Shawn O. Pearce 08 February 2007, 20:59:39 UTC git-gui: Update known branches during rescan. If the user has created (or deleted) a branch through an external tool, and uses Rescan, they probably are trying to make git-gui update to show their newly created branch. So now we load all known heads and update the branch menu during any rescan operation, just in-case the set of known branches was modified. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 20:59:39 UTC
37f1db8 Shawn O. Pearce 29 January 2007, 11:56:00 UTC git-gui: Assign background colors to each blame hunk. To help the user visually see which lines are associated with each other in the file we attempt to sign a unique background color to each commit and then render all text associated with that commit using that color. This works out OK for a file which has very few commits in it; but most files don't have that property. What we really need to do is look at what colors are used by our neighboring commits (if known yet) and pick a color which does not conflict with our neighbor. If we have run out of colors then we should force our neighbor to recolor too. Yes, its the graph coloring problem. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 11:56:00 UTC
747c0cf Shawn O. Pearce 29 January 2007, 11:23:12 UTC git-gui: Use a grid layout for the blame viewer. Using a panedwindow to display the blame viewer's individual columns just doesn't make sense. Most of the important data fits within the columns we have allocated, and those that don't the leading part fits and that's good enough. There are just too many columns within this viewer to let the user sanely control individual column widths. This change shouldn't really be an issue for most git-gui users as their displays should be large enough to accept this massive dump of data. We now also have a properly working horizontal scrollbar for the current file data area. This makes it easier to get away with a narrow window when screen space is limited, as you can still scroll around within the file content. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 11:23:12 UTC
e7fb6c6 Shawn O. Pearce 29 January 2007, 10:51:49 UTC git-gui: Install column headers in blame viewer. I started to get confused about what each column meant in the blame viewer, and I'm the guy who wrote the code! So now git-gui hints to the user about what each column is by drawing headers at the top. Unfortunately this meant I had to use those dreaded frame objects which seem to cause so much pain on Windows. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 10:51:49 UTC
915616e Shawn O. Pearce 29 January 2007, 10:33:27 UTC git-gui: Display original filename and line number in blame. When we annotate a file and show its line data, we're already asking for copy and movement detection (-M -C). This costs extra time, but gives extra data. Since we are asking for the extra data we really should show it to the user. Now the blame UI has two additional columns, one for the original filename (in the case of a move/copy between files) and one for the original line number of the current line of code. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 10:33:27 UTC
8f6c07b Shawn O. Pearce 29 January 2007, 08:09:28 UTC git-gui: Correctly handle spaces in filepaths. Anytime are about to open a pipe on what may be user data we need to make sure the value is escaped correctly into a Tcl list, so that the executed subprocess will receive the right arguments. For the most part we were already doing this correctly, but a handful of locations did not. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 08:09:28 UTC
463ca37 Shawn O. Pearce 29 January 2007, 08:03:29 UTC git-gui: Use -M and -C when running blame. Since we run blame incrementally in the background we might as well get as much data as we can from the file. Adding -M and -C definately makes it take longer to compute the revision annotations, but since they are streamed in and updated as they are discovered we'll get recent data almost immediately anyway. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 08:03:29 UTC
db45378 Shawn O. Pearce 29 January 2007, 07:56:07 UTC git-gui: Allow users to edit user.name, user.email from options. Users may need to be able to alter their user.name or user.email configuration settings. If they are mostly a git-gui user they should be able to view/set these important values from within the git-gui environment, rather than needing to edit a raw text file on their local filesystem. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 07:56:07 UTC
c94dd1c Shawn O. Pearce 29 January 2007, 07:52:06 UTC git-gui: Display the current branch name in browsers. Rather than using HEAD for the current branch, use the actual name of the current branch in the browser. This way the user knows what a browser is browsing if they open up different browsers while on different branches. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 07:52:06 UTC
3eddda9 Shawn O. Pearce 29 January 2007, 07:50:10 UTC git-gui: Improve the icons used in the browser display. Real icons which seem to indicate going up to the parent (an up arrow) and a subdirectory (an open folder). Files are now drawn with the file_mod icon, like a modified file is. This just looks better as it is more consistent with the rest of our UI. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 07:50:10 UTC
35874c1 Shawn O. Pearce 29 January 2007, 05:50:41 UTC git-gui: Implemented file browser and incremental blame. This rather huge change provides a browser for the current branch. The browser simply shows the contents of tree HEAD, and lets the user drill down through the tree. The icons used really stink, as I just copied in icon which we already had. I really need to replace the file_dir and file_uplevel icons with something more useful. If the user double clicks on a file within the browser we open it in a blame viewer. This makes use of the new incremental blame feature that Linus just added yesterday to core Git. Fortunately the feature will be in 1.5.0 final so we can rely on having it available here. Since the blame engine is incremental the user will get blame data for groups which can be determined early. Git will slowly fill in the remaining lines as it goes. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 06:12:42 UTC
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
back to top