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
b13ef49 Junio C Hamano 15 August 2007, 22:01:20 UTC GIT 1.5.2.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 August 2007, 22:01:20 UTC
2ed2c22 Salikh Zakirov 15 August 2007, 17:01:43 UTC git-add -u paths... now works from subdirectory git-add -u also takes the path limiters, but unlike the command without the -u option, the code forgot that it could be invoked from a subdirectory, and did not correctly handle the prefix. Signed-off-by: Salikh Zakirov <salikh@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 August 2007, 21:28:34 UTC
a4882c2 Junio C Hamano 15 August 2007, 21:12:14 UTC Fix "git add -u" data corruption. This applies to 'maint' to fix a rather serious data corruption issue. When "git add -u" affects a subdirectory in such a way that the only changes to its contents are path removals, the next tree object written out of that index was bogus, as the remove codepath forgot to invalidate the cache-tree entry. Reported by Salikh Zakirov. Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 August 2007, 21:21:23 UTC
9396943 Linus Torvalds 05 August 2007, 04:48:08 UTC apply: remove directory that becomes empty by renaming the last file away We attempt to remove directory that becomes empty after removal of a file. We should do the same when we rename an existing file away. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 August 2007, 08:36:59 UTC
33a798c Junio C Hamano 06 August 2007, 07:20:06 UTC setup.c:verify_non_filename(): don't die unnecessarily while disambiguating If you have a working tree _file_ "foo", attempt to refer to a branch "foo/bar" without -- to disambiguate, like this: $ git log foo/bar tried to make sure that foo/bar cannot be naming a working tree file "foo/bar" (in which case we would say "which one do you want? A rev or a working tree file? clarify with -- please"). We run lstat("foo/bar") to check that. If it does not succeed, there is no ambiguity. That is good. But we also checked the error status for the lstat() and expected it to fail with ENOENT. In this particular case, however, it fails with ENOTDIR. That should be treated as "expected error" as well. Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 August 2007, 07:25:35 UTC
4e0b2bb Christian Couder 31 July 2007, 12:48:29 UTC rev-list --bisect: fix allocation of "int*" instead of "int". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 August 2007, 04:07:39 UTC
281a53b Julian Phillips 18 July 2007, 21:33:57 UTC Force listingblocks to be monospaced in manpages For the html output we can use a stylesheet to make sure that the listingblocks are presented in a monospaced font. For the manpages do it manually by inserting a ".ft C" before and ".ft" after the block in question. In order for these roff commands to get through to the manpage they have to be element encoded to prevent quoting. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 July 2007, 23:56:20 UTC
fa2e71c Junio C Hamano 18 July 2007, 05:58:28 UTC Do not expect unlink(2) to fail on a directory. When "git checkout-index" checks out path A/B/C, it makes sure A and A/B are truly directories; if there is a regular file or symlink at A, we prefer to remove it. We used to do this by catching an error return from mkdir(2), and on EEXIST did unlink(2), and when it succeeded, tried another mkdir(2). Thomas Glanzmann found out the above does not work on Solaris for a root user, as unlink(2) was so old fashioned there that it allowed to unlink a directory. As pointed out, this still doesn't guarantee that git won't call "unlink()" on a directory (race conditions etc), but that's fundamentally true (there is no "funlink()" like there is "fstat()"), and besides, that is in no way git-specific (ie it's true of any application that gets run as root). Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 July 2007, 07:53:09 UTC
ffb293b Junio C Hamano 12 July 2007, 19:01:47 UTC GIT 1.5.2.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 July 2007, 19:01:47 UTC
ec0603e Junio C Hamano 12 July 2007, 08:04:16 UTC Teach read-tree 2-way merge to ignore intermediate symlinks Earlier in 16a4c61, we taught "read-tree -m -u" not to be confused when switching from a branch that has a path frotz/filfre to another branch that has a symlink frotz that points at xyzzy/ directory. The fix was incomplete in that it was still confused when coming back (i.e. switching from a branch with frotz -> xyzzy/ to another branch with frotz/filfre). This fix is rather expensive in that for a path that is created we would need to see if any of the leading component of that path exists as a symbolic link in the filesystem (in which case, we know that path itself does not exist, and the fact we already decided to check it out tells us that in the index we already know that symbolic link is going away as there is no D/F conflict). Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 July 2007, 09:22:53 UTC
1b2782a Junio C Hamano 12 July 2007, 08:45:56 UTC Merge branch 'maint' of git://repo.or.cz/git-gui into maint * 'maint' of git://repo.or.cz/git-gui: git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree} git-gui: Don't linewrap within console windows git-gui: Correct ls-tree buffering problem in browser git-gui: Skip nicknames when selecting author initials git-gui: Ensure windows shortcuts always have .bat extension git-gui: Include a Push action on the left toolbar git-gui: Bind M1-P to push action git-gui: Don't bind F5/M1-R in all windows git-gui: Unlock the index when cancelling merge dialog git-gui: properly popup error if gitk should be started but is not installed 12 July 2007, 08:45:56 UTC
20f1a10 Shawn O. Pearce 12 July 2007, 06:31:28 UTC git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree} From Johannes Sixt <J.Sixt@eudaptics.com>: > It seems that MSYS's wish does some quoting for Bourne shells, > in particular, escape the first '{' of the "^{tree}" suffix, but > then it uses cmd.exe to run "git rev-parse". However, cmd.exe does > not remove the backslash, so that the resulting rev expression > ends up in git's guts as unrecognizable garbage: rev-parse fails, > and git-gui hickups in a way that it must be restarted. Johannes originally submitted a patch to this section of commit.tcl to use `git rev-parse $PARENT:`, but not all versions of Git will accept that format. So I'm just taking the really simple approach here of scanning the first line of the commit to grab its tree. About the same cost, but works everywhere. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 July 2007, 06:38:14 UTC
512e44b Shawn O. Pearce 10 July 2007, 01:27:55 UTC Clarify documentation of fast-import's D subcommand The 'D' subcommand within a commit can also delete a directory recursively. This wasn't clear in the prior version of the documentation, leading to a question on the mailing list. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 July 2007, 01:27:55 UTC
e87fb0f Shawn O. Pearce 09 July 2007, 15:14:00 UTC git-gui: Don't linewrap within console windows If we get more than 80 characters of text in a single line odds are it is output from git-fetch or git-push and its showing a lot of detail off to the right edge that is not so important to the average user. We still want to make sure we show everything we need, but we can get away with that information being off to the side with a horizontal scrollbar. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 July 2007, 01:13:26 UTC
56e29f5 Shawn O. Pearce 09 July 2007, 15:55:45 UTC git-gui: Correct ls-tree buffering problem in browser Our file browser was showing bad output as it did not properly buffer a partial record when read from `ls-tree -z`. This did not show up on my Mac OS X system as most trees are small, the pipe buffers generally big and `ls-tree -z` was generally fast enough that all data was ready before Tcl started to read. However on my Cygwin system one of my production repositories had a large enough tree and packfile that it took a couple of pipe buffers for `ls-tree -z` to complete its dump. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 July 2007, 01:12:35 UTC
88dce86 Shawn O. Pearce 09 July 2007, 01:06:43 UTC git-gui: Skip nicknames when selecting author initials Our blame viewer only grabbed the first initial of the git.git author string "Simon 'corecode' Schubert". Here the problem was we looked at Simon, pulled the S into the author initials, then saw the single quote as the start of the next name and did not like this character as it was not an uppercase letter. We now skip over single quoted nicknames placed within the author name field and grab the initials following it. So the above name will get the initials SS, rather than just S. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 July 2007, 01:06:43 UTC
ccd7186 William Pursell 29 June 2007, 13:08:29 UTC user-manual: fix directory name in git-archive example Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 08 July 2007, 22:27:51 UTC
11d5153 J. Bruce Fields 18 June 2007, 20:38:22 UTC user-manual: more explanation of push and pull usage Recently a user on the mailing list complained that they'd read the manual but couldn't figure out how to keep a couple private repositories in sync. They'd tried using push, and were surprised by the effect. Add a little text in an attempt to make it clear that: - Pushing to a branch that is checked out will have odd results. - It's OK to synchronize just using pull if that's simpler. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 08 July 2007, 22:17:47 UTC
f0dc409 J. Bruce Fields 22 June 2007, 03:17:40 UTC tutorial: Fix typo "You" should be "Alice" here. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 08 July 2007, 22:02:16 UTC
5478285 Andy Parkins 12 June 2007, 15:43:19 UTC user-manual: grammar and style fixes - "method of" is vulgar, "method for" is nicer - "recovery" becomes "recovering" from Steve Hoelzer's original version of this patch - "if you want" is nicer as "if you wish" - "you may" should be "you can"; "you may" is "you have permission to" rather than "you can"'s "it is possible to" Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 08 July 2007, 22:01:28 UTC
5fda48d Johannes Schindelin 07 July 2007, 17:50:39 UTC Fix "apply --reverse" with regard to whitespace "git apply" used to take check the whitespace in the wrong direction. Noticed by Daniel Barkalow. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 July 2007, 18:54:51 UTC
47282d4 Shawn O. Pearce 05 July 2007, 22:39:40 UTC git-gui: Ensure windows shortcuts always have .bat extension Apparently under some setups on Windows Tk is hiding our file extension recommendation of ".bat" from the user and that is allowing the user to create a shortcut file which has no file extension. Double clicking on such a file in Windows Explorer brings up the associate file dialog, as Windows does not know what application to launch. We now append the file extension ".bat" to the filename of the shortcut file if it has no extension or if it has one but it is not ".bat". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 July 2007, 08:02:18 UTC
87b49a5 Shawn O. Pearce 06 July 2007, 02:19:33 UTC git-gui: Include a Push action on the left toolbar Pushing changes to a remote system is a very common action for many users of git-gui, so much so that in some workflows a user is supposed to push immediately after they make a local commit so that their change(s) are immediately available for their teammates to view and build on top of. Including the push button right below the commit button on the left toolbar indicates that users should probably perform this action after they have performed the commit action. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 July 2007, 08:02:02 UTC
840bcfa Shawn O. Pearce 06 July 2007, 02:15:00 UTC git-gui: Bind M1-P to push action Users often need to be able to push the current branch so that they can publish their recent changes to anyone they are collaborating with on the project. Associating a keyboard action with this will make it easier for keyboard-oriented users to quickly activate the push features. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 July 2007, 08:01:31 UTC
f1e031b Shawn O. Pearce 06 July 2007, 02:16:38 UTC git-gui: Don't bind F5/M1-R in all windows We actually only want our F5/M1-R keystroke bound in the main window. Within a browser/blame/console window pressing these keys should not execute the rescan action. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 July 2007, 07:59:34 UTC
c8e23aa Shawn O. Pearce 04 July 2007, 06:29:32 UTC git-gui: Unlock the index when cancelling merge dialog Pressing the escape key while in the merge dialog cancels the merge and correctly unlocks the index. Unfortunately this is not true of the Cancel button, using it closes the dialog but does not release the index lock, rendering git-gui frozen until you restart it. We now properly release the index lock when the Cancel button is used. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 July 2007, 06:29:32 UTC
ed5f07a Miklos Vajna 03 July 2007, 23:38:29 UTC Document -<n> for git-format-patch The -<n> option was not mentioned in git-format-patch's manpage till now. Fix this. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 July 2007, 02:02:13 UTC
f8d6957 Johannes Schindelin 03 July 2007, 20:28:24 UTC glossary: add 'reflog' Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 July 2007, 20:56:07 UTC
3cb5673 Johannes Schindelin 03 July 2007, 15:01:06 UTC diff --no-index: fix --name-status with added files Without this patch, an added file would be reported as /dev/null. Noticed by David Kastrup. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 July 2007, 20:44:30 UTC
9cb18f5 Jim Meyering 03 July 2007, 10:40:20 UTC Don't smash stack when $GIT_ALTERNATE_OBJECT_DIRECTORIES is too long There is no restriction on the length of the name returned by get_object_directory, other than the fact that it must be a stat'able git object directory. That means its name may have length up to PATH_MAX-1 (i.e., often 4095) not counting the trailing NUL. Combine that with the assumption that the concatenation of that name and suffixes like "/info/alternates" and "/pack/---long-name---.idx" will fit in a buffer of length PATH_MAX, and you see the problem. Here's a fix: sha1_file.c (prepare_packed_git_one): Lengthen "path" buffer so we are guaranteed to be able to append "/pack/" without checking. Skip any directory entry that is too long to be appended. (read_info_alternates): Protect against a similar buffer overrun. Before this change, using the following admittedly contrived environment setting would cause many git commands to clobber their stack and segfault on a system with PATH_MAX == 4096: t=$(perl -e '$s=".git/objects";$n=(4096-6-length($s))/2;print "./"x$n . $s') export GIT_ALTERNATE_OBJECT_DIRECTORIES=$t touch g ./git-update-index --add g If you run the above commands, you'll soon notice that many git commands now segfault, so you'll want to do this: unset GIT_ALTERNATE_OBJECT_DIRECTORIES Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 July 2007, 19:25:29 UTC
e8964a5 Michael Hendricks 02 July 2007, 16:48:34 UTC Correctly document the name of the global excludes file configuration Signed-off-by: Michael Hendricks <michael@ndrix.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 July 2007, 03:54:01 UTC
8d2244b Andy Parkins 02 July 2007, 12:56:58 UTC Make git-prune submodule aware (and fix a SEGFAULT in the process) I ran git-prune on a repository and got this: $ git-prune error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a commit Segmentation fault (core dumped) This repository was a strange one in that it was being used to provide its own submodule. That is, the repository was cloned into a subdirectory, an independent branch checked out in that subdirectory, and then it was marked as a submodule. git-prune then failed in the above manner. The problem was that git-prune was not submodule aware in two areas. Linus said: > So what happens is that something traverses a tree object, looks at each > entry, sees that it's not a tree, and tries to look it up as a blob. But > subprojects are commits, not blobs, and then when you look at the object > more closely, you get the above kind of object type confusion. and included a patch to add an S_ISGITLINK() test to reachable.c's process_tree() function. That fixed the first git-prune error, and stopped it from trying to process the gitlink entries in trees as if they were pointers to other trees (and of course failing, because gitlinks _aren't_ trees). That part of this patch is his. The second area is add_cache_refs(). This is called before starting the reachability analysis, and was calling lookup_blob() on every object hash found in the index. However, it is no longer true that every hash in the index is a pointer to a blob, some of them are gitlinks, and are not backed by any object at all, they are commits in another repository. Normally this bug was not causing any problems, but in the case of the self-referencing repository described above, it meant that the gitlink hash was being marked as being of type OBJ_BLOB by add_cache_refs() call to lookup_blob(). Then later, because that hash was also pointed to by a ref, add_one_ref() would treat it as a commit; lookup_commit() would return a NULL because that object was already noted as being an OBJ_BLOB, not an OBJ_COMMIT; and parse_commit_buffer() would SEGFAULT on that NULL pointer. The fix made by this patch is to not blindly call lookup_blob() in reachable.c's add_cache_refs(), and instead skip any index entries that are S_ISGITLINK(). Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 July 2007, 23:41:18 UTC
5788744 Junio C Hamano 02 July 2007, 07:35:58 UTC GIT 1.5.2.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 July 2007, 07:35:58 UTC
2064887 Matt Kraai 30 June 2007, 17:05:03 UTC Correct the name of NO_R_TO_GCC_LINKER in the comment describing it. Signed-off-by: Matt Kraai <kraai@ftbfs.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 June 2007, 18:16:09 UTC
181ea68 Sam Vilain 30 June 2007, 08:56:16 UTC git-remote: document -n The 'show' and 'prune' commands accept an option '-n'; document what it does. Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 June 2007, 17:50:28 UTC
38d697a Sam Vilain 30 June 2007, 08:56:12 UTC repack: improve documentation on -a option Some minor enhancements to the git-repack manual page. Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 June 2007, 17:50:18 UTC
7aecb12 Gerrit Pape 29 June 2007, 11:32:29 UTC git-gui: properly popup error if gitk should be started but is not installed On 'Visualize ...', a gitk process is started. Since it is run in the background, catching a possible startup error doesn't work, and the error output goes to the console git-gui is started from. The most probable startup error is that gitk is not installed; so before trying to start, check for the existence of the gitk program, and popup an error message unless it's found. This was noticed and reported by Paul Wise through http://bugs.debian.org/429810 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 30 June 2007, 04:43:20 UTC
b833651 Junio C Hamano 29 June 2007, 04:28:36 UTC Merge branch 'maint' of git://repo.or.cz/git-gui into maint * 'maint' of git://repo.or.cz/git-gui: git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack git-gui: Don't nice git blame on MSYS as nice is not supported git-gui: Don't require $DISPLAY just to get --version git-gui: Bind Tab/Shift-Tab to cycle between panes in blame git-gui: Correctly install to /usr/bin on Cygwin 29 June 2007, 04:28:36 UTC
7e508eb Shawn O. Pearce 26 June 2007, 19:27:35 UTC git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack The Tools/Migrate menu option is a hack just for me. Yes, that's right, git-gui has a hidden feature that really only works for me, and the users that I support within my day-job's great firewall. The menu option is not supported outside of that environment. In the past we only enabled Tools/Migrate if our special local script 'gui-miga' existed in the proper location, and if there was a special '.pvcsrc' in the top level of the working directory. This latter test for the '.pvcsrc' file is now failing, as the file was removed from all Git repositories due to changes made to other tooling within the great firewall's realm. I have changed the test to only work on Cygwin, and only if the special 'gui-miga' is present. This works around the configuration changes made recently within the great firewall's realm, but really this entire Tools/Migrate thing should be abstracted out into some sort of plugin system so other users can extend git-gui as they need. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 27 June 2007, 04:35:30 UTC
fffaaba Shawn O. Pearce 27 June 2007, 04:27:13 UTC git-gui: Don't nice git blame on MSYS as nice is not supported Johannes Sixt reported that MinGW/MSYS does not have a nice.exe to drop the priority of a child process when it gets spawned. So we have to avoid trying to start `git blame` through nice when we are on Windows and do not have Cygwin available to us. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 27 June 2007, 04:27:13 UTC
b69ba46 Frank Lichtenheld 25 June 2007, 14:03:54 UTC config: Change output of --get-regexp for valueless keys Print no space after the name of a key without value. Otherwise keys without values are printed exactly the same as keys with empty values. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2007, 01:20:47 UTC
e373bb7 Frank Lichtenheld 25 June 2007, 14:03:53 UTC config: Complete documentation of --get-regexp The asciidoc documentation of the --get-regexp option was incomplete. Add some missing pieces: - List the option in SYNOPSIS - Mention that key names are printed Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2007, 01:19:20 UTC
e3ae6bb Sam Vilain 26 June 2007, 23:44:22 UTC cleanup merge-base test script Add a picture, and keep the setup and the tests together. Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2007, 01:17:53 UTC
1164f1e Linus Torvalds 26 June 2007, 21:34:02 UTC Fix zero-object version-2 packs A pack-file can get created without any objects in it (to transfer "no data" - which can happen if you use a reference git repo, for example, or just otherwise just end up transferring only branch head information and already have all the objects themselves). And while we probably should never create an index for such a pack, if we do (and we do), the index file size sanity checking was incorrect. This fixes it. Reported-and-tested-by: Jocke Tjernlund <tjernlund@tjernlund.se> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2007, 01:02:15 UTC
582c739 Sven Verdoolaege 26 June 2007, 21:19:41 UTC Ignore submodule commits when fetching over dumb protocols Without this patch, the code would look for the submodule commits in the superproject and (needlessly) fail when it couldn't find them. Signed-off-by: Sven Verdoolaege <skimo@liacs.nl> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2007, 01:02:13 UTC
4e817d1 Shawn O. Pearce 22 June 2007, 05:10:12 UTC git-gui: Don't require $DISPLAY just to get --version Junio asked that we don't force the user to have a valid X11 server configured in $DISPLAY just to obtain the output of `git gui version`. This makes sense, the user may be an automated tool that is running without an X server available to it, such as a build script or other sort of package management system. Or it might just be a user working in a non-GUI environment and wondering "what version of git-gui do I have installed?". Tcl has a lot of warts, but one of its better ones is that a comment can be continued to the next line by escaping the LF that would have ended the comment using a backslash-LF sequence. In the past we have used this trick to escape away the 'exec wish' that is actually a Bourne shell script and keep Tcl from executing it. I'm using that feature here to comment out the Bourne shell script and hide it from the Tcl engine. Except now our Bourne shell script is a few lines long and checks to see if it should print the version, or not. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 22 June 2007, 05:10:12 UTC
fb626dc Shawn O. Pearce 12 June 2007, 04:04:30 UTC git-gui: Bind Tab/Shift-Tab to cycle between panes in blame The blame viewer is composed of two different areas, the file area on top and the commit area on the bottom. If users are trying to shift the focus it is probably because they want to shift from one area to the other, so we just setup Tab and Shift-Tab to jump from the one half to the other in a cycle. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 June 2007, 03:25:23 UTC
82a2d6b Shawn O. Pearce 19 June 2007, 14:48:09 UTC git-gui: Correctly install to /usr/bin on Cygwin Mark Levedahl <mlevedahl@gmail.com> noted that installation on Cygwin to /usr/bin can cause problems with the automatic guessing of our library location. The problem is that installation to /usr/bin means we actually have: /usr/bin = c:\cygwin\bin /usr/share = c:\cygwin\usr\share So git-gui guesses that its library should be found within the c:\cygwin\share directory, as that is where it should be relative to the script itself in c:\cygwin\bin. In my first version of this patch I tried to use `cygpath` to resolve /usr/bin and /usr/share to test that they were in the same relative locations, but that didn't work out correctly as we were actually testing /usr/share against itself, so it always was equal, and we always used relative paths. So my original solution was quite wrong. Mark suggested we just always disable relative behavior on Cygwin, because of the complexity of the mount mapping problem, so that's all I'm doing. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 June 2007, 03:22:49 UTC
c7c8485 Junio C Hamano 16 June 2007, 06:58:18 UTC GIT 1.5.2.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2007, 08:13:35 UTC
4c7100a Junio C Hamano 15 June 2007, 05:20:16 UTC Documentation: adjust to AsciiDoc 8 It turns out that the attribute definition we have had for a long time to hide "^" character from AsciiDoc 7 was not honored by AsciiDoc 8 even under "-a asciidoc7compatible" mode. There is a similar breakage with the "compatible" mode with + characters. The double colon at the end of definition list term needs to be attached to the term, without a whitespace. After this minimum fixups, AsciiDoc 8 (I used 8.2.1 on Debian) with compatibility mode seems to produce reasonably good results. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2007, 08:11:16 UTC
66e41f7 Junio C Hamano 16 June 2007, 06:48:35 UTC Avoid diff cost on "git log -z" Johannes and Marco discovered that "git log -z" spent cycles in diff even though there is no need to actually compute diffs. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2007, 06:48:35 UTC
7b99bef Junio C Hamano 16 June 2007, 06:35:32 UTC git-branch --track: fix tracking branch computation. The original code did not take hierarchical branch names into account at all. [jc: cherry-picked 11f68d9 from 'master'] Tested-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2007, 06:35:32 UTC
1367214 Junio C Hamano 16 June 2007, 06:33:06 UTC $EMAIL is a last resort fallback, as it's system-wide. $EMAIL is a system-wide setup that is used for many many many applications. If the git user chose a specific user.email setup, then _this_ should be honoured rather than $EMAIL. [jc: cherry-picked ec563e8 from 'master'] Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2007, 06:33:06 UTC
fadf488 Johannes Schindelin 05 June 2007, 02:36:49 UTC merge-recursive: refuse to merge binary files [jc: cherry-picked 9f30855 from 'master'] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2007, 06:28:10 UTC
634cd48 Johannes Schindelin 05 June 2007, 02:36:11 UTC Move buffer_is_binary() to xdiff-interface.h We already have two instances where we want to determine if a buffer contains binary data as opposed to text. [jc: cherry-picked 6bfce93e from 'master'] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2007, 06:27:23 UTC
fa0c87c Alex Riesen 13 June 2007, 18:54:32 UTC Add a local implementation of hstrerror for the system which do not have it The function converts the value of h_errno (last error of name resolver library, see netdb.h). One of systems which supposedly do not have the function is SunOS. POSIX does not mandate its presence. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2007, 05:48:34 UTC
18a9368 Jakub Narebski 13 June 2007, 23:12:20 UTC Generated spec file to be ignored is named git.spec and not git-core.spec Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2007, 05:43:58 UTC
4f01d0f Junio C Hamano 13 June 2007, 03:48:31 UTC Merge branch 'ar/clone' into maint * ar/clone: Fix clone to setup the origin if its name ends with .git 13 June 2007, 03:48:31 UTC
44bdc43 Junio C Hamano 13 June 2007, 03:48:21 UTC Merge branch 'sv/objfixes' into maint * sv/objfixes: Don't assume tree entries that are not dirs are blobs 13 June 2007, 03:48:21 UTC
2cf69cf Kristian Høgsberg 11 June 2007, 17:04:40 UTC Unquote From line from patch before comparing with given from address. This makes --suppress-from actually work when you're unfortunate enough to have non-ASCII in your name. Also, if there's a match use the optionally RFC2047 quoted version from the email. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 June 2007, 07:13:49 UTC
6894f49 Luiz Fernando N. Capitulino 11 June 2007, 12:56:56 UTC git-cherry: Document 'limit' command-line option Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 June 2007, 07:13:20 UTC
31c74ca Junio C Hamano 12 June 2007, 07:05:24 UTC Merge branch 'maint' of git://repo.or.cz/git-gui into maint * 'maint' of git://repo.or.cz/git-gui: git-gui: Save geometry before the window layout is damaged git-gui: Give amend precedence to HEAD over MERGE_MSG git-gui: Include 'war on whitespace' fixes from git.git 12 June 2007, 07:05:24 UTC
39fa2a9 Shawn O. Pearce 12 June 2007, 03:52:43 UTC git-gui: Save geometry before the window layout is damaged Because Tk does not assure us the order that it will process children in before it destroys the main toplevel we cannot safely save our geometry data during a "bind . <Destroy>" event binding. The geometry may have already changed as a result of a one or more children being removed from the layout. This was pointed out in gitk by Mark Levedahl, and patched over there by commit b6047c5a8166a71e01c6b63ebbb67c6894d95114. So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when the window is closed by the user, and forward that close event to our main do_quit routine. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 June 2007, 03:52:43 UTC
b2f3bb1 Shawn O. Pearce 11 June 2007, 23:39:55 UTC git-gui: Give amend precedence to HEAD over MERGE_MSG Apparently git-commit.sh (the command line commit user interface in core Git) always gives precedence to the prior commit's message if `commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists. We actually were doing the same here in git-gui, but the amended message got lost if $GIT_DIR/MERGE_MSG already existed because we started a rescan immediately after loading the prior commit's body into the edit buffer. When that happened the rescan found MERGE_MSG existed and replaced the commit message buffer with the contents of that file. This meant the user never saw us pick up the commit message of the prior commit we are about to replace. Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by running `git cherry-pick -n $someid` and then trying to amend the prior commit in git-gui, thus combining the contents of $someid with the contents of HEAD, and reusing the commit message of HEAD, not $someid. With the recent changes to make cherry-pick use the $GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message of $someid, not HEAD. Now we always use HEAD if we are amending. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 11 June 2007, 23:48:41 UTC
615b865 Shawn O. Pearce 11 June 2007, 23:06:10 UTC git-gui: Include 'war on whitespace' fixes from git.git Earlier git.git applied a large "war on whitespace" patch that was created using 'apply --whitespace=strip'. Unfortunately a few of git-gui's own files got caught in the mix and were also cleaned up. That was a6080a0a44d5ead84db3dabbbc80e82df838533d. This patch is needed in git-gui.git to reapply those exact same changes here, otherwise our version generator script is unable to obtain our version number from git-describe when we are hosted in the git.git repository. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 11 June 2007, 23:06:10 UTC
c288a2f Junio C Hamano 11 June 2007, 07:51:39 UTC Merge branch 'maint' of git://repo.or.cz/git-gui into maint * 'maint' of git://repo.or.cz/git-gui: (46 commits) git-gui: Changed blame header bar background to match main window git-gui: Favor the original annotations over the recent ones git-gui: Improve our labeling of blame annotation types git-gui: Use three colors for the blame viewer background git-gui: Jump to original line in blame viewer git-gui: Display both commits in our tooltips git-gui: Run blame twice on the same file and display both outputs git-gui: Display the "Loading annotation..." message in italic git-gui: Rename fields in blame viewer to better descriptions git-gui: Label the uncommitted blame history entry git-gui: Switch internal blame structure to Tcl lists git-gui: Cleanup redundant column management in blame viewer git-gui: Better document our blame variables git-gui: Remove unused commit_list from blame viewer git-gui: Automatically expand the line number column as needed git-gui: Make the line number column slightly wider in blame git-gui: Use lighter colors in blame view git-gui: Remove unnecessary space between columns in blame viewer git-gui: Remove the loaded column from the blame viewer git-gui: Clip the commit summaries in the blame history menu ... 11 June 2007, 07:51:39 UTC
23c9ccb J. Bruce Fields 10 June 2007, 20:20:34 UTC tutorial: use "project history" instead of "changelog" in header The word "changelog" seems a little too much like jargon to me, and beginners must understand section headers so they know where to look for help. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 10 June 2007, 20:46:17 UTC
d9bd321 J. Bruce Fields 06 February 2007, 07:55:07 UTC Documentation: user-manual todo Some more user-manual todo's: how to share objects between repositories, how to recover. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 10 June 2007, 20:39:53 UTC
8ceca74 J. Bruce Fields 05 June 2007, 22:42:58 UTC user-manual: add a missing section ID I forgot to give an ID for this section. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 10 June 2007, 20:38:50 UTC
1da158e Gerrit Pape 05 June 2007, 08:47:51 UTC Fix typo in remote branch example in git user manual In Documentation/user-manual.txt the example $ git checkout --track -b origin/maint maint under "Getting updates with git pull", should read $ git checkout --track -b maint origin/maint This was noticed by Ron, and reported through http://bugs.debian.org/427502 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 10 June 2007, 20:38:50 UTC
99f171b J. Bruce Fields 05 June 2007, 22:33:27 UTC user-manual: quick-start updates Update text to reflect new position in appendix. Update the name to reflect the fact that this is closer to reference than tutorial documentation (as suggested by Jonas Fonseca). Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 10 June 2007, 20:38:50 UTC
29cf5e1 william pursell 09 June 2007, 15:44:12 UTC Make command description imperative statement, not third-person present. In several of the text messages, the tense of the verb is inconsistent. For example, "Add" vs "Creates". It is customary to use imperative for command description. Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 June 2007, 17:42:48 UTC
5035242 Junio C Hamano 08 June 2007, 08:19:13 UTC checkout: do not get confused with ambiguous tag/branch names Although it is not advisable, we have always allowed a branch and a tag to have the same basename (i.e. it is not illegal to have refs/heads/frotz and refs/tags/frotz at the same time). When talking about a specific commit, the interpretation of 'frotz' has always been "use tag and then check branch", although we warn when ambiguities exist. However "git checkout $name" is defined to (1) first see if it matches the branch name, and if so switch to that branch; (2) otherwise it is an instruction to detach HEAD to point at the commit named by $name. We did not follow this definition when $name appeared under both refs/heads/ and refs/tags/ -- we switched to the branch but read the tree from the tagged commit, which was utterly bogus. Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2007, 08:19:13 UTC
d80ded0 Shawn O. Pearce 08 June 2007, 06:02:48 UTC git-gui: Changed blame header bar background to match main window The main window's diff header bar background switched from orange to gold recently, and I liked the effect it had on readability of the text. Since I wanted the blame viewer to match, here it is. Though this probably should be a user defined color, or at least a constant somewhere that everyone can reference. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 June 2007, 06:50:07 UTC
defe13a Alex Riesen 06 June 2007, 23:39:05 UTC Fix clone to setup the origin if its name ends with .git The problem is visible when cloning a local repo. The cloned repository will have the origin url setup incorrectly: the origin name will be copied verbatim in origin url of the cloned repository. Normally, the name is to be expanded into absolute path. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2007, 23:40:03 UTC
e2ac7cb Sam Vilain 06 June 2007, 10:25:17 UTC Don't assume tree entries that are not dirs are blobs When scanning the trees in track_tree_refs() there is a "lazy" test that assumes that entries are either directories or files. Don't do that. Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2007, 22:43:18 UTC
23fcdc7 Michael Milligan 05 June 2007, 06:06:30 UTC git-cvsimport: Make sure to use $git_dir always instead of .git sometimes CVS import was failing on a couple repos I was trying to import. I was setting GIT_DIR=newproj.git and using the -i flag, but this bug was thwarting the effort... evil CVS. Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2007, 22:23:35 UTC
e59ade9 Sam Vilain 06 June 2007, 21:23:16 UTC fix documentation of unpack-objects -n unpack-objects -n didn't print the object list as promised on the manual page, so alter the documentation to reflect the behaviour Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2007, 22:20:13 UTC
a1a5a63 Johannes Sixt 06 June 2007, 08:11:55 UTC Accept dates before 2000/01/01 when specified as seconds since the epoch Tests with git-filter-branch on a repository that was converted from CVS and that has commits reaching back to 1999 revealed that it is necessary to parse dates before 2000/01/01 when they are specified as seconds since 1970/01/01. There is now still a limit, 100000000, which is 1973/03/03 09:46:40 UTC, in order to allow that dates are represented as 8 digits. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2007, 22:20:12 UTC
0f32da5 Shawn O. Pearce 06 June 2007, 07:22:22 UTC git-gui: Favor the original annotations over the recent ones Usually when you are looking at blame annotations for a region of a file you are more interested in why something was originally done then why it is here now. This is because most of the time when we get original annotation data we are looking at a simple refactoring performed to better organize code, not to change its semantic meaning or function. Reorganizations are sometimes of interest, but not usually. We now show the original commit data first in the tooltip. This actually looks quite nice as the original commit will usually have an author date prior to the current (aka move/copy) annotation's commit, so the two commits will now tend to appear in chronological order. I also found myself to always be clicking on the line of interest in the file column but I always wanted the original tracking data and not the move/copy data. So I changed our default commit from $asim_data (the simple move/copy annotation) to the more complex $amov_data (the -M -C -C original annotation). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 07:22:22 UTC
949da61 Shawn O. Pearce 06 June 2007, 07:03:16 UTC git-gui: Improve our labeling of blame annotation types It feels wrong to call the -M -C -C annotations "move/copy tracking" as they are actually the original locations. So I'm relabeling the status bar to show "copy/move tracking annotations" for the current file (no -M -C -C) as that set of annotations tells us who put the hunk here (who moved/copied it). I'm now calling the -M -C -C pass "original location annotations" as that's what we're really digging for. I also tried to clarify some of the text in the hover tooltip. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 07:03:52 UTC
5d198d6 Shawn O. Pearce 06 June 2007, 06:53:36 UTC git-gui: Use three colors for the blame viewer background To prevent neighboring lines that are different commits from using the same background color we now use 3 colors and assign them by selecting the color that is not used before or after the line in question. We still color "on the fly" as we receive hunks from git-blame, but we delay our color decisions until we are getting the original location data (the slower -M -C -C pass) as that is usually more fine-grained than the current location data. Credit goes to Martin Waitz for the tri-coloring concept. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 06:53:36 UTC
0dfed77 Shawn O. Pearce 04 June 2007, 08:07:35 UTC git-gui: Jump to original line in blame viewer When the user clicks on a commit link within one of the columns in the blame viewer we now jump them not just to that commit/file pair but also to the line of the original file. This saves the user a lot of time, as they don't need to search through the new file data for the chunk they were previously looking at. We also restore the prior view when the user clicks the back button to return to a pior commit/file pair that they were looking at. Turned out this was quite tricky to get working in Tk. Every time I tried to jump the text widgets to the correct locations by way of the "yview moveto" or "see" subcommands Tk performed the change until the current event finished dispatching, and then reset the views back to 0, making the change never take place. Forcing Tk to run the pending events before we jump the UI resolves the issue. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:52 UTC
383d4e0 Shawn O. Pearce 02 June 2007, 23:03:55 UTC git-gui: Display both commits in our tooltips If we have commit data from both the simple blame and the rename/move tracking blame and they differ than there is a bigger story to tell. We now include data from both commits so that the user can see that this link as moved, who moved it, and where it originated from. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:52 UTC
172c92b Shawn O. Pearce 02 June 2007, 22:21:18 UTC git-gui: Run blame twice on the same file and display both outputs We now perform two passes over any input file given to the blame viewer. Our first pass is a quick "git-blame" with no options, getting the details of how each line arrived into this file. We are specifically ignoring/omitting the rename detection logic as this first pass is to determine why things got into the state they are in. Once the first pass is complete and is displayed in the UI we run a second pass, using the much more CPU intensive "-M -C -C" options to perform extensive rename/movement detection. The output of this second pass is shown in a different column, allowing the user to see for any given line how it got to be, and if it came from somewhere else, where that is. This is actually very instructive when run on our own lib/branch.tcl script. That file grew recently out of a very large block of code in git-gui.sh. The first pass shows when I created that file, while the second pass shows the original commit information. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:51 UTC
debcd0f Shawn O. Pearce 02 June 2007, 21:15:56 UTC git-gui: Display the "Loading annotation..." message in italic If the user clicks on a line region that we haven't yet received an annotation for from git-blame we show them "Loading annotation". But I don't want the user to confuse this loading message with a commit whose first line is "Loading annotation" and think we messed up our display somehow. Since we never use italics for anything else, I'm going with the idea that italic slant can be used to show data is missing/elided out at the time being. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:51 UTC
fc816d7 Shawn O. Pearce 03 June 2007, 03:26:24 UTC git-gui: Rename fields in blame viewer to better descriptions Calling the commit message pane $w_cmit is a tad confusing when we also have the $w_cgrp column that shows the abbreviated SHA-1s. So w_cmit -> w_cviewer, as it is the "commit viewer"; and w_cgrp -> w_amov as it is the "annotated commit + move tracking" column. Also changed line_data -> amov_data, as that list is exactly the results shown in w_amov. Why call the column "move tracking"? Because this column holds data from "git blame -M -C". I'm considering adding an additional column that holds the data from "git blame" without -M/-C, showing who did the copy/move, and when they did it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:51 UTC
c5db65a Shawn O. Pearce 02 June 2007, 20:03:52 UTC git-gui: Label the uncommitted blame history entry If the user runs the blame viewer on a working directory file instead of a specific commit-ish then we have no value for the commit SHA1 or the summary line; this causes the history menu to get an empty entry at the very bottom. We now look for this odd case and call the meny entry "Working Directory". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:50 UTC
2f85b7e Shawn O. Pearce 02 June 2007, 20:01:43 UTC git-gui: Switch internal blame structure to Tcl lists The Tcl list datatype is significantly faster to work with than the array type, especially if our indexes are a consecutive set of numbers, like say line numbers in a file. This rather large change reorganizes the internal data structure of the blame viewer to use a proper Tcl list for the annotation information about a line. Each line is given its own list within the larger line_data list, where the indexes correspond to various facts about that particular line. The interface does seem to be more responsive this way, with less time required by Tcl to process blame, and to switch to another version of the same file. It could just be a placebo effect, but either way most Tcl experts perfer lists for this type of work over arrays. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:50 UTC
14c4dfd Shawn O. Pearce 02 June 2007, 19:34:52 UTC git-gui: Cleanup redundant column management in blame viewer The code to handle our three different text widgets is a bit on the messy side as we issue the same command on all three widgets one at a time. Adding (or removing) columns from the viewer is messy, as a lot of locations need to have the new column added into the sequence, or removed from it. We also now delete the tags we create for each commit when we switch to display another "commit:path" pair. This way the text viewer doesn't get bogged down with a massive number of tags as we traverse through history. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:50 UTC
c17c175 Shawn O. Pearce 02 June 2007, 19:13:35 UTC git-gui: Better document our blame variables The array variable "order" used to be used to tell us in what order each commit was received in. Recent changes have removed that need for an ordering and the "order" array is now just a boolean 'do we have that commit yet' flag. The colors were moved to fields, so they appear inside of the blame viewer instance. This keeps two different concurrently running blame viewers from stepping on each other's ordering of the colors in group_colors. Most of the other fields were moved around a little bit so that they are organized by major category and value lifespan. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:50 UTC
b611015 Shawn O. Pearce 02 June 2007, 18:45:35 UTC git-gui: Remove unused commit_list from blame viewer This list used to store the commits in the order we received them in. I originally was using it to update the colors of the commit before and the commit after the current commit, but since that interface concept turned out to be horribly ugly and has been removed we no longer need this list. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:49 UTC
81fb7ef Shawn O. Pearce 02 June 2007, 18:41:10 UTC git-gui: Automatically expand the line number column as needed After we finish reading a chunk of data from the file stream we know how many digits we need in the line number column to show the current maximum line number. If our line number column isn't wide enough, we should expand it out to the correct width. Any file over our default allowance of 5 digits (99,999 lines) is so large that the slight UI "glitch" when we widen the column out is trivial compared to the time it will take Git to fully do the annotations. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:49 UTC
375e136 Shawn O. Pearce 02 June 2007, 18:35:44 UTC git-gui: Make the line number column slightly wider in blame Most source code files are under 9,999 lines of text, so using a field width of 5 characters meant that we should have had one char padding on the left edge (because we right-justify the line number). Unfortunately when I added the right margin earlier (when I removed the padding) I ate into the extra character's space, losing the left margin. This put the line numbers too close to the commit column in any file with more than 999 lines in it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:49 UTC
000a106 Shawn O. Pearce 02 June 2007, 18:31:01 UTC git-gui: Use lighter colors in blame view The colors I originally picked out on a Mac OS X system look a tad too dark on a Windows 2000 system; the greys are dark enough to make it difficult to read some lines of text and the green used to highlight the current commit was also difficult to read text on. I also added a third grey to the mix, to try and help some files that wind up with a number of neighboring chunks getting the same colors. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:49 UTC
0632570 Shawn O. Pearce 02 June 2007, 06:55:53 UTC git-gui: Remove unnecessary space between columns in blame viewer On Mac OS X the OS has "features" that like to draw thick black borders around the text field that has focus. This is nice if you want to know where your text is going and are blind as a bat, but it isn't the best thing to have in a table that is being faked through the abuse of Tk text widgets. By setting our takefocus, highlightthickness and padx/y we can get rid of this border and get our text widgets packed right next to each other, with no padding between them. This makes the blame background color smoothly run across the entire line of commit data, line number and file content. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:48 UTC
0eab69a Shawn O. Pearce 02 June 2007, 06:38:26 UTC git-gui: Remove the loaded column from the blame viewer Originally I had placed this loaded column between the line number and the file line data to help users know if a particular line has received annotation data or not yet. This way users would know if the line(s) they were interested in were ready for viewing, or if they still had to wait. It also was an entertaining way for the user to spend their time waiting for git-blame --incremental to compute the complete set of annotations. However it is completely useless now that we show the abbreviated commit SHA-1 and author initials in the leftmost column. That area is empty until we get the annotation data, and as soon as we get it in we display something there, indicating to the user that there is now blame data ready. Further with the tooltips the user is likely to see the data as soon as it comes in, as they are probably not keeping their mouse perfectly still. So I'm removing the field to save screen space for more useful things, like file content. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:48 UTC
b55a243 Shawn O. Pearce 02 June 2007, 04:09:55 UTC git-gui: Clip the commit summaries in the blame history menu Some commit lines can get really long when users enter a lot of text without linewrapping (for example). Rather than letting the menu get out of control in terms of width we clip the summary to the first 50+ characters. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:48 UTC
08dda17 Shawn O. Pearce 02 June 2007, 03:48:18 UTC git-gui: Use a label instead of a button for the back button Apparently Tk on Mac OS X won't draw a button with an image using a transparent background. Instead it draws the button using some sort of 3D effect, even though I asked for no relief and no border. The background is also not our orange that we expected it to be. Earlier I had tried this same trick on Windows and it draws the same way as the button did, so I'm going to switch to the label as that seems to be more portable. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:48 UTC
79c50bf Shawn O. Pearce 02 June 2007, 01:59:29 UTC git-gui: Show original filename in blame tooltip If we have two commits right next to each other in the final file and they were kept as different blocks in the leftmost column then its probably because the original filename was different. To help the user know where they are digging into when they click on that link we now show the original file in the tooltip, but to save space we do so only if the original file is not the same as the file we are currently viewing. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:47 UTC
back to top