Staging
v0.5.1
https://github.com/git/git

sort by:
Revision Author Date Message Commit Date
806ea70 GIT 1.5.3.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 September 2007, 10:11:28 UTC
8ae6749 Fixed update-hook example allow-users format. The example provided with the update-hook-example does not work on either bash 2.05b.0(1)-release nor 3.1.17(1)-release. The matcher did not match the lines that it advertised to match, such as: refs/heads/bw/ linus refs/heads/tmp/* * In POSIX 1003.2 regular expressions, the star (*), is not an wildcard meaning "match everything", it matches 0 or more matches of the atom preceding it. So to match "refs/heads/bw/topic-branch", the matcher should be written as "refs/heads/bw/.*" to match "refs/heads/bw/" and everything after it. Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 September 2007, 00:38:52 UTC
bd43098 Documentation/git-svn: updated design philosophy notes This section has not been updated in a while and --branches/--tags/--trunk options are commonly used nowadays. Noticed-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 September 2007, 00:07:45 UTC
cd894ee t/t4014: test "am -3" with mode-only change. Earlier commit ece7b74903007cee8d280573647243d46a6f3a95 added a test for rebase that uses "am -3", but this adds a test to check "am -3" itself. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2007, 22:19:47 UTC
3d845d7 Fix lapsus in builtin-apply.c Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2007, 21:09:12 UTC
5c633a4 git-push: documentation and tests for pushing only branches Commit 098e711e caused git-push to match only branches when considering which refs to push. This patch updates the documentation accordingly and adds a test for this behavior. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2007, 21:00:20 UTC
bf1ee63 git-svnimport: Use separate arguments in the pipe for git-rev-parse Some people seem to create SVN branch names with spaces or other shell metacharacters. Signed-off-by: Matthias Urlichs <smurf@smurf.noris.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2007, 21:00:20 UTC
7a461b5 Document ls-files --with-tree=<tree-ish> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2007, 06:57:35 UTC
cba8d48 git-commit: partial commit of paths only removed from the index Because a partial commit is meant to be a way to ignore what are staged in the index, "git rm --cached A && git commit A" should just record what is in A on the filesystem. The previous patch made the command sequence to barf, saying that A has not been added yet. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2007, 06:57:35 UTC
64586e7 git-commit: Allow partial commit of file removal. When making a partial commit, git-commit uses git-ls-files with the --error-unmatch option to expand and sanity check the user supplied path patterns. When any path pattern does not match with the paths known to the index, it errors out, in order to catch a common mistake to say "git commit Makefiel cache.h" and end up with a commit that touches only cache.h (notice the misspelled "Makefile"). This detection however does not work well when the path has already been removed from the index. If you drop a path from the index and try to commit that partially, i.e. $ git rm COPYING $ git commit -m 'Remove COPYING' COPYING the command complains because git does not know anything about COPYING anymore. This introduces a new option --with-tree to git-ls-files and uses it in git-commit when we build a temporary index to write a tree object for the partial commit. When --with-tree=<tree-ish> option is specified, names from the given tree are added to the set of names the index knows about, so we can treat COPYING file in the example as known. Of course, there is no reason to use "git rm" and git-aware people have long time done: $ rm COPYING $ git commit -m 'Remove COPYING' COPYING which works just fine. But this caused a constant confusion. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2007, 06:57:35 UTC
a017f27 Merge branch 'jc/grep-c' into maint * jc/grep-c: Split grep arguments in a way that does not requires to add /dev/null. 18 September 2007, 06:56:40 UTC
9269df9 Merge branch 'maint' of git://repo.or.cz/git-gui into maint * 'maint' of git://repo.or.cz/git-gui: git-gui: Disable native platform text selection in "lists" git-gui: Paper bag fix "Commit->Revert" format arguments git-gui: Provide 'uninstall' Makefile target to undo an installation git-gui: Font chooser to handle a large number of font families git-gui: Make backporting changes from i18n version easier git-gui: Don't delete send on Windows as it doesn't exist git-gui: Trim trailing slashes from untracked submodule names git-gui: Assume untracked directories are Git submodules git-gui: handle "deleted symlink" diff marker git-gui: show unstaged symlinks in diff viewer git-gui: Avoid use of libdir in Makefile git-gui: Disable Tk send in all git-gui sessions git-gui: lib/index.tcl: handle files with % in the filename properly git-gui: Properly set the state of "Stage/Unstage Hunk" action git-gui: Fix detaching current branch during checkout git-gui: Correct starting of git-remote to handle -w option 18 September 2007, 06:50:17 UTC
be510cf send-email: make message-id generation a bit more robust Earlier code took Unix time and appended a few random digits. If you are firing off many messages within a second, you could issue the same id to different messages, which is a no-no. If you send out 31 messages within a single second, with random integer taken out of rand(4200), you have about 10% chance of producing the same message ID. This fixes the problem by uses a prefix string which is constant-per-invocation (time and pid), with a serial number for each message generated by the process appended at the end. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2007, 05:02:19 UTC
d7416ec git-apply: fix whitespace stripping The algorithm isn't right here: it accumulates any set of 8 spaces into tabs even if they're separated by tabs, so <four spaces><tab><four spaces><tab> is converted to <tab><tab><tab> when it should be just <tab><tab> So teach git-apply that a tab hides any group of less than 8 previous spaces in a row. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 September 2007, 09:18:44 UTC
3849bfb git-gui: Disable native platform text selection in "lists" Sometimes we use a Tk text widget as though it were a listbox. This happens typically when we want to show an icon to the left of the text label or just when a text widget is generally a better choice then the native listbox widget. In these cases if we want the user to have control over the selection we implement our own "in_sel" tag that shows the selected region and we perform our own selection management in the background via keybindings and mouse bindings. In such uses we don't want the user to be able to activate the native platform selection by dragging their mouse through the text widget. Doing so creates a very confusing display and the user is left wondering what it may mean to have two different types of selection in the same widget. Tk doesn't allow us to delete the "sel" tag that it uses internally to manage the native selection but it will allow us to make it invisible by setting the tag to have the same display properties as unselected text. So long as we don't actually use the "sel" tag for anything in code its effectively invisible. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 17 September 2007, 03:12:19 UTC
ece7b74 apply --index-info: fall back to current index for mode changes "git diff" does not record index lines for pure mode changes (i.e. no lines changed). Therefore, apply --index-info would call out a bogus error. Instead, fall back to reading the info from the current index. Incidentally, this fixes an error where git-rebase would not rebase a commit including a pure mode change, and changes requiring a threeway merge. Noticed and later tested by Chris Shoemaker. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 September 2007, 01:20:10 UTC
f3caeb9 Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint * 'maint' of git://linux-nfs.org/~bfields/git: core-tutorial: minor cleanup documentation: replace Discussion section by link to user-manual chapter user-manual: todo updates and cleanup user-manual: fix introduction to packfiles user-manual: move packfile and dangling object discussion user-manual: rewrite object database discussion user-manual: reorder commit, blob, tree discussion user-manual: rewrite index discussion user-manual: create new "low-level git operations" chapter user-manual: rename "git internals" to "git concepts" user-manual: move object format details to hacking-git chapter user-manual: adjust section levels in "git internals" 16 September 2007, 06:18:05 UTC
a85feca core-tutorial: minor cleanup Revise the introduction for concision, add pointers to the tutorial and user manual as appropriate, delete cvsimport note from the end, as that work's been done elsewhere already. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:17:24 UTC
40dac51 documentation: replace Discussion section by link to user-manual chapter The "Discussion" section has a lot of useful information, but is a little wordy, especially for an already-long man page, and is designed for an audience more of potential git hackers than users, which probably doesn't make as much sense as git matures. Also, I (perhaps foolishly) forked a version in the user manual, which has been significantly rewritten in an attempt to address some of the above problems. So, remove this section and replace it by a (very terse) summary of the original material--my attempt at the World's Shortest Git Overview--and a reference to the appropriate chapter of the user manual. It's unfortunate to remove something that's been in this place for a long time, as some people may still depend on finding it there. But I think we'll want to do this some day anyway. Cc: Andreas Ericsson <ae@op5.se> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:17:24 UTC
ecd95b5 user-manual: todo updates and cleanup Format a couple lists. Reminder that we may want to add submodule documentation some day. 16 September 2007, 02:17:23 UTC
9644ffd user-manual: fix introduction to packfiles Actually I don't think we've previously mentioned .git/objects, so we need a different introduction here. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:17:23 UTC
09eff7b user-manual: move packfile and dangling object discussion The discussions of packfiles and dangling objects both belong in the object database section. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:17:23 UTC
1bbf1c7 user-manual: rewrite object database discussion Rewrite the introduction. Rewrite each section completely to make them work in the new order, to add some examples, and to move plumbing commands (like git-commit-tree) to the following chapter. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:17:23 UTC
513d419 user-manual: reorder commit, blob, tree discussion The bottom-up blog, tree, commit order makes sense unless you want to give explicit examples--it's easier to discover objects to examine if you go in the other order...., Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:17:23 UTC
1c09789 user-manual: rewrite index discussion Add an example using git-ls-files, standardize on the new "index" terminology (as opposed to "cache"), attempt to clarify discussion and make it a little shorter, avoid some unnecessary jargon ("write-back cache"). Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:17:23 UTC
1c6045f user-manual: create new "low-level git operations" chapter The low-level index operations aren't as important to regular users as the rest of this "git concepts" chapter; so move it into a separate chapter, and do some minor cleanup. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:17:05 UTC
036f819 user-manual: rename "git internals" to "git concepts" "git internals" sounds like something only git developers must know about, but this stuff should be of wider interest. Rename the chapter and give it a slightly friendlier introduction. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:13:31 UTC
f2327c6 user-manual: move object format details to hacking-git chapter Most of this is probably only of interest to git developers. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:13:31 UTC
971aa71 user-manual: adjust section levels in "git internals" The descriptions of the various object types should all be a subsection of the "Object Database" section. I cribbed most of this chapter from the README (now core-intro.txt and git(7)), because there's stuff in there people need to know and I was too lazy to rewrite it. The audience isn't quite right, though--the chapter is a mixture of user- and developer- level documentation that isn't as appropriate now as it was originally. So, reserve this chapter for stuff users need to know, and move the source code introduction into a new "git hacking" chapter where we'll also move any hacker-only technical details. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> 16 September 2007, 02:13:31 UTC
023756f revision walker: --cherry-pick is a limited operation We used to rely on the fact that cherry-pick would trigger the code path to set limited = 1 in handle_commit(), when an uninteresting commit was encountered. However, when cherry picking between two independent branches, i.e. when there are no merge bases, and there is only linear development (which can happen when you cvsimport a fork of a project), no uninteresting commit will be encountered. So set limited = 1 when --cherry-pick was asked for. Noticed by Martin Bähr. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 September 2007, 23:34:11 UTC
e598c51 git-sh-setup: typofix in comments Noticed by Anupam Srivastava. Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 September 2007, 23:33:22 UTC
d99ebf0 Split grep arguments in a way that does not requires to add /dev/null. In order to (almost) always show the name of the file without relying on "-H" option of GNU grep, we used to add /dev/null to the argument list unless we are doing -l or -L. This caused "/dev/null:0" to show up when -c is given in the output. It is not enough to add -c to the set of options we do not pass /dev/null for. When we have too many files, we invoke grep multiple times and we need to avoid giving a widow filename to the last invocation -- otherwise we will not see the name. This keeps two filenames when the argv[] buffer is about to overflow and we have not finished iterating over the index, so that the last round will always have at least two paths to work with (and not require /dev/null). An obvious and the only exception is when there is only 1 file that is given to the underlying grep, and in that case we avoid passing /dev/null and let the external "grep -c" report only the number of matches. Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 22:16:43 UTC
7c8b5ea Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot Bram Schoenmakers noticed that git-config document was formatted incorrectly. Depending on the version of AsciiDoc and docbook toolchain, it is sometimes taken as a numbered example by AsciiDoc, some other times passed intact to roff format to confuse "man". Since we refer to the repository metadata directory as $GIT_DIR elsewhere, work it around by using that symbolic name. Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 21:51:08 UTC
43b98ac Add test to check recent fix to "git add -u" An earlier commit fixed type-change case in "git add -u". This adds a test to make sure we do not introduce regression. At the same time, it fixes a stupid typo in the error message. Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 21:30:05 UTC
42b5f86 Documentation/git-archive.txt: a couple of clarifications. The description of the option gave impression that there were several formats available by using three dots. There are no other formats than tar and gzip currently supported. Clarify that the archive goes to the standard output. Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 19:17:11 UTC
0024a54 Fix the rename detection limit checking This adds more proper rename detection limits. Instead of just checking the limit against the number of potential rename destinations, we verify that the rename matrix (which is what really matters) doesn't grow ridiculously large, and we also make sure that we don't overflow when doing the matrix size calculation. This also changes the default limits from unlimited, to a rename matrix that is limited to 100 entries on a side. You can raise it with the config entry, or by using the "-l<n>" command line flag, but at least the default is now a sane number that avoids spending lots of time (and memory) in situations that likely don't merit it. The choice of default value is of course very debatable. Limiting the rename matrix to a 100x100 size will mean that even if you have just one obvious rename, but you also create (or delete) 10,000 files, the rename matrix will be so big that we disable the heuristics. Sounds reasonable to me, but let's see if people hit this (and, perhaps more importantly, actually *care*) in real life. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 19:12:57 UTC
b78281f diff --no-index: do not forget to run diff_setup_done() Code inspection by Linus found this. Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 19:12:32 UTC
8419d2e git-format-patch --in-reply-to: accept <message@id> with angle brackets This will allow RFC-literate users to say: format-patch --in-reply-to='<message.id@site.name>' without forcing them to strip the surrounding angle brackets like this: format-patch --in-reply-to='message.id@site.name' We accept both forms, and the latter gets necessary < and > around it as before. Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 07:49:12 UTC
767c98a git-add -u: do not barf on type changes Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 07:45:29 UTC
f5de799 Remove duplicate note about removing commits with git-filter-branch A duplicate of an already existing section in the documentation of git-filter-branch was added in commit f95eef15f2f8a336b9a42749f5458c841a5a5d63. This patch removes that redundant section. Signed-off-by: Ulrik Sverdrup <ulrik.sverdrup@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 05:53:53 UTC
f28dd47 git-clone: improve error message if curl program is missing or not executable If the curl program is not available (or not executable), and git clone is started to clone a repository through http, this is the output Initialized empty Git repository in /tmp/puppet/.git/ /usr/bin/git-clone: line 37: curl: command not found Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? This patch improves the error message by checking the return code when running curl to exit immediately if it's 126 or 127; the error output now is Initialized empty Git repository in /tmp/puppet/.git/ /usr/bin/git-clone: line 37: curl: command not found Adrian Bridgett noticed this and reported through http://bugs.debian.org/440976 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 05:39:22 UTC
c32da69 hooks--update: Explicitly check for all zeros for a deleted ref. The previous check caused the hook to reject as unannotated any tag whose SHA1 starts with a zero. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 September 2007, 05:33:11 UTC
55bad4f git-gui: Paper bag fix "Commit->Revert" format arguments The recent bug fix to correctly handle filenames with %s (or any other valid Tcl format specifier) missed a \ on this line and caused the remaining format arguments to not be supplied when we updated the status bar. This caused a Tcl error anytime the user was trying to perform a file revert. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 September 2007, 00:08:53 UTC
042f53c git-gui: Provide 'uninstall' Makefile target to undo an installation Several users have requested a "make uninstall" target be provided in the stock git-gui Makefile so that they can undo an install if git-gui goes to the wrong place during the initial install, or if they are unhappy with the tool and want to remove it from their system. We currently assume that the complete set of files we need to delete are those defined by our Makefile and current source directory. This could differ from what the user actually has installed if they installed one version then attempt to use another to perform the uninstall. Right now I'm just going to say that is "pilot error". Users should uninstall git-gui using the same version of source that they used to make the installation. Perhaps in the future we could read tclIndex and base our uninstall decisions on its contents. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 September 2007, 00:02:39 UTC
afe2098 git-gui: Font chooser to handle a large number of font families Simon Sasburg noticed that on X11 if there are more fonts than can fit in the height of the screen Tk's native tk_optionMenu does not offer scroll arrows to the user and it is not possible to review all choices or to select those that are off-screen. On Mac OS X the tk_optionMenu works properly but is awkward to navigate if the list is long. This is a rewrite of our font selection by providing a new modal dialog that the user can launch from the git-gui Options panel. The dialog offers the user a scrolling list of fonts in a pane. An example text shows the user what the font looks like at the size they have selected. But I have to admit the example pane is less than ideal. For example in the case of our diff font we really should show the user an example diff complete with our native diff syntax coloring. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Acked-by: Simon Sasburg <simon.sasburg@gmail.com> 13 September 2007, 23:07:46 UTC
e7034d6 git-gui: Make backporting changes from i18n version easier This is a very trivial hack to define a global mc procedure that does not actually perform i18n translations on its input strings. By declaring an mc procedure here in our maint version of git-gui we can take patches that are intended for the latest development version of git-gui and easily backport them without needing to tweak the mc calls first. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 13 September 2007, 23:04:14 UTC
3d80017 Merge branch 'sp/maint-no-thin' into maint * sp/maint-no-thin: Make --no-thin the default in git-push to save server resources 12 September 2007, 20:07:06 UTC
6143fa2 stash: end index commit log with a newline There was no newline at the end of the index commit message, putting the shell prompt at its end after a 'git cat-file commit $id'. This is similar to what was fixed in 843103d69388a5c74ed99753e1c162a66835b04d. Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 September 2007, 19:05:56 UTC
4fb5fd5 git-commit: Disallow amend if it is going to produce an empty non-merge commit Right now one can amend the last non-merge commit using a dirty index and in the process maybe cause the last commit to have the same tree as its parent. In such a case one would want to discard the last commit instead of amending it. This reverts commit 8588452ceb78b1da17652ba03f9942ef740e07ea. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 September 2007, 17:50:27 UTC
3803bce git-send-email.perl: Add angle brackets to In-Reply-To if necessary Although message-id by defintion should have surrounding angle brackets, there is no point forcing people to type them in. Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 September 2007, 07:57:38 UTC
060fe57 Fix a test failure (t9500-*.sh) on cygwin On filesystems where it is appropriate to set core.filemode to false, test 29 ("commitdiff(0): mode change") fails when git-commit does not notice a file (execute) permission change. A fix requires noting the new file execute permission in the index with a "git update-index --chmod=+x", prior to the commit. Add a function (note_chmod) which implements this idea, and insert a call in each test that modifies the x permission. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 September 2007, 06:05:35 UTC
63c4024 git-gui: Don't delete send on Windows as it doesn't exist The Windows port of Tk does not have the send command so we cannot delete it from our global namespace, but the Mac OS X and X11 ports do have it. Switching this delete attempt into a catch makes send go away, or stay away. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 11 September 2007, 22:57:18 UTC
a4503a1 Make --no-thin the default in git-push to save server resources 1) pushes happen less often than fetches, so the bandwidth saving is much less visible in that case overall. 2) thin packs have to be complemented with missing delta bases to be valid, so many received thin packs will take more disk space. 3) the bother of repacking should be distributed amongst "clients" i.e. fetchers and pushers as much as possible, and not the server being fetched or pushed, to keep disk and CPU usage low on the server. This is why a fetch should get thin packs but a push should not. Both Nico and I have been assuming that --no-thin was the default behavior of git-push ever since Nico introduced --fix-thin into the index-pack process, which allowed fetch and receive-pack to avoid exploding packfiles received during transfer. This patch finally makes it so. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 September 2007, 07:00:26 UTC
05cc2ff fix doc for --compression argument to pack-objects Remove obsolete details (core.legacyheaders is always true now). Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 September 2007, 06:58:56 UTC
aba9119 git-tag -s must fail if gpg cannot sign the tag. Most of this patch code and message was written by Shawn O. Pearce. I made some tests to know what the problem was, and then I changed the code related with the SIGPIPE signal. If the user has misconfigured `user.signingkey` in their .git/config or just doesn't have any secret keys on their keyring and they ask for a signed tag with `git tag -s` we better make sure the resulting tag was actually signed by gpg. Prior versions of builtin git-tag allowed this failure to slip by without error as they were not checking the return value of the finish_command() so they did not notice when gpg exited with an error exit status. They also did not fail if gpg produced an empty output or if read_in_full received an error from the read system call while trying to read the pipe back from gpg. Finally, we did not actually honor any return value from the do_sign function as it returns ssize_t but was being stored into an unsigned long. This caused the compiler to optimize out the die condition, allowing git-tag to continue along and create the tag object. However, when gpg gets a wrong username, it exits before any read was done and then the writing process receives SIGPIPE and program is terminated. By ignoring this signal, anyway, the function write_or_die gets EPIPE from write_in_full and exits returning 0 to the system without a message. Here we better call to write_in_full directly so we can fail printing a message and return safely to the caller. With these issues fixed `git-tag -s` will now fail to create the tag and will report a non-zero exit status to its caller, thereby allowing automated helper scripts to detect (and recover from) failure if gpg is not working properly. Proposed-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 September 2007, 04:30:54 UTC
8938410 git-gui: Trim trailing slashes from untracked submodule names Oddly enough `git ls-files --others` supplies us the name of an untracked submodule by including the trailing slash but that same git version will not accept the name with a trailing slash through `git update-index --stdin`. Stripping off that final slash character before loading it into our file lists allows git-gui to stage changes to submodules just like any other file. This change should give git-gui users some basic submodule support, but it is strictly at the plumbing level as we do not actually know about calling the git-submodule porcelain that is a recent addition to git 1.5.3. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 September 2007, 00:39:47 UTC
3b9dfde git-gui: Assume untracked directories are Git submodules If `git ls-files --others` returned us the name of a directory then it is because Git has decided that this directory itself contains a valid Git repository and its files shouldn't be listed as untracked for this repository. In such a case we should label the object as a Git repository and not just as a directory. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 September 2007, 00:39:42 UTC
4ed1a19 git-gui: handle "deleted symlink" diff marker Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 23:47:26 UTC
2d19f8e git-gui: show unstaged symlinks in diff viewer git-gui has a minor problem with regards to symlinks that point to directories. git init mkdir realdir ln -s realdir linkdir git gui Now clicking on file names in the "unstaged changes" window, there's a problem coming from the "linkdir" symlink: git-gui complains with error reading "file4": illegal operation on a directory ...even though git-gui can add that same symlink to the index just fine. This patch fix this by adding a check. [sp: Minor fix to use {link} instead of "link" in condition and to only open the path if it is not a symlink.] Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 23:47:22 UTC
7b02b85 git-svn: understand grafts when doing dcommit Use the rev-list --parents functionality to read the parents of the commit. cat-file only shows the raw object with the original parents and doesn't take into account grafts; so we'll rely on rev-list machinery for the smarts here. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 September 2007, 09:30:33 UTC
5701115 git-diff: don't squelch the new SHA1 in submodule diffs The code to squelch empty diffs introduced by commit fb13227e089f22dc31a3b1624559153821056848 would inadvertently populate filespec "two" of a submodule change using the uninitialized (null) SHA1, thereby replacing the submodule SHA1 by 0{40} in the output. This change teaches diffcore_skip_stat_unmatch to handle submodule changes correctly. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 September 2007, 09:28:57 UTC
c63fe3b git-gui: Avoid use of libdir in Makefile Dmitry V. Levin pointed out that on GNU linux libdir is often used in Makefiles to mean "/usr/lib" or "/usr/lib64", a directory that is meant to hold platform-specific binary files. Using a different libdir meaning here in git-gui's Makefile breaks idomatic expressions like rpm specifile "make libdir=%_libdir". Originally I asked that the git.git Makefile undefine libdir before it calls git-gui's own Makefile but it turns out this is very hard to do, if not impossible. Renaming our libdir to gg_libdir resolves this case with a minimum amount of fuss on our part. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 09:03:12 UTC
cff9339 git-gui: Disable Tk send in all git-gui sessions The Tk designers blessed us with the "send" command, which on X11 will allow anyone who can connect to your X server to evaluate any Tcl code they desire within any running Tk process. This is just plain nuts. If git-gui wants someone running Tcl code within it then would ask someone to supply that Tcl code to it; waiting for someone to drop any random Tcl code into us is not fantastic idea. By renaming send to the empty name the procedure will be removed from the global namespace and Tk will stop responding to random Tcl evaluation requests sent through the X server. Since there is no facility to filter these requests it is unlikely that we will ever consider enabling this command. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 03:47:10 UTC
0b883ab git-gui: lib/index.tcl: handle files with % in the filename properly Steps to reproduce the bug: $ mkdir repo && cd repo && git init Initialized empty Git repository in .git/ $ touch 'foo%3Fsuite' $ git-gui Then click on the 'foo%3Fsuite' icon to include it in a changeset, a popup comes with: 'Error: bad field specifier "F"' Vincent Danjean noticed the problem and also suggested the fix, reported through http://bugs.debian.org/441167 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 September 2007, 03:06:26 UTC
a51cdb0 git-svn: fix "Malformed network data" with svn:// servers We have a workaround for the reparent function not working correctly on the SVN native protocol servers. This workaround opens a new connection (SVN::Ra object) to the new URL/directory. Since libsvn appears limited to only supporting one connection at a time, this workaround invalidates the Git::SVN::Ra object that is $self inside gs_fetch_loop_common(). So we need to restart that connection once all the fetching is done for each loop iteration to be able to run get_log() successfully. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 September 2007, 05:23:48 UTC
ee834cf (cvs|svn)import: Ask git-tag to overwrite old tags. If the tag was moved in CVS or SVN history, it will be moved in the imported history as well. Tag history is not tracked. Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 September 2007, 04:02:39 UTC
451e593 Documentation / grammer nit If we're counting, a smaller number is 'fewer' not 'less' Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 September 2007, 04:01:33 UTC
4e56015 Include a git-push example for creating a remote branch Many users get confused when `git push origin master:foo` works when foo already exists on the remote repository but are confused when foo doesn't exist as a branch and this form does not create the branch foo. This new example highlights the trick of including refs/heads/ in front of the desired branch name to create a branch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 September 2007, 06:25:09 UTC
432e93a Cleanup unnecessary file modifications in t1400-update-ref Kristian Høgsberg pointed out that the two file modifications we were doing during the 'creating initial files' step are not even used within the test suite. This was actually confusing as we do not even need these changes for the tests to pass. All that really matters here is the specific commit dates are used so that these appear in the branch's reflog, and that the dates are different so that the branch will update when asked and the reflog entry is also updated. There is no need for the file modification. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 September 2007, 06:17:04 UTC
6b1b40d Makefile: Add cache-tree.h to the headers list The dependency was missing. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 September 2007, 06:08:22 UTC
ea09ea2 Don't allow contrib/workdir/git-new-workdir to trash existing dirs Recently I found that doing a sequence like the following: git-new-workdir a b ... git-new-workdir a b by accident will cause a (and now also b) to have an infinite cycle in its refs directory. This is caused by git-new-workdir trying to create the "refs" symlink over again, only during the second time it is being created within a's refs directory and is now also pointing back at a's refs. This causes confusion in git as suddenly branches are named things like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the more commonly accepted "refs/heads/foo". Plenty of commands start to see ambiguous ref names and others just take ages to compute. git-clone has the same safety check, so git-new-workdir should behave just like it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 September 2007, 05:24:54 UTC
6b763c4 git-apply: do not read past the end of buffer When the preimage we are patching is shorter than what the patch text expects, we tried to match the buffer contents at the "original" line with the fragment in full, without checking we have enough data to match in the preimage. This caused the size of a later memmove() to wrap around and attempt to scribble almost the entire address space. Not good. The code that follows the part this patch touches tries to match the fragment with line offsets. Curiously, that code does not have the problem --- it guards against reading past the end of the preimage. Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 September 2007, 04:58:40 UTC
047d94d git-gui: Properly set the state of "Stage/Unstage Hunk" action Today I found yet another way for the "Stage Hunk" and "Unstage Hunk" context menu actions to leave the wrong state enabled in the UI. The problem this time was that I connected the state determination to the value of $::current_diff_side (the side the diff is from). When the user was last looking at a diff from the index side and unstages everything the diff panel goes empty, but the action stayed enabled as we always assumed unstaging was a valid action. This change moves the logic for determining when the action is enabled away from the individual side selection, as they really are two unrelated concepts. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 September 2007, 03:03:52 UTC
881d8f2 git-gui: Fix detaching current branch during checkout If the user tried to detach their HEAD while keeping the working directory on the same commit we actually did not completely do a detach operation internally. The problem was caused by git-gui not forcing the HEAD symbolic ref to be updated to a SHA-1 hash when we were not switching revisions. Now we update the HEAD ref if we aren't currently detached or the hashes don't match. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 September 2007, 03:01:44 UTC
6e4ba05 git-gui: Correct starting of git-remote to handle -w option Current versions of git-remote apparently are passing the -w option to Perl as part of the shbang line: #!/usr/bin/perl -w this caused a problem in git-gui and gave the user a Tcl error with the message: "git-remote not supported: #!/usr/bin/perl -w". The fix for this is to treat the shbang line as a Tcl list and look at the first element only for guessing the executable name. Once we know the executable name we use the remaining elements (if any exist) as arguments to the executable, before the script filename. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 September 2007, 03:01:44 UTC
5587cac GIT 1.5.3.1: obsolete git-p4 in RPM spec file. HPA noticed that yum does not like the newer git RPM set; it turns out that we do not ship git-p4 anymore but existing installations do not realize the package is gone if we do not tell anything about it. David Kastrup suggests using Obsoletes in the spec file of the new RPM to replace the old package, so here is a try. Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 September 2007, 08:28:37 UTC
030e0e5 Typofix: 1.5.3 release notes 02 September 2007, 22:03:26 UTC
86bab96 GIT 1.5.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 September 2007, 07:00:00 UTC
4e837a9 Merge branch 'jp/send-email-cc' * jp/send-email-cc: git-send-email --cc-cmd 01 September 2007, 20:15:27 UTC
a94eda6 Mention -m as an abbreviation for --merge Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 17:36:56 UTC
947ad2e Update my contact address as the maintainer. 01 September 2007, 11:09:51 UTC
f368f5a Documentation: minor AsciiDoc mark-up fixes. Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 11:06:13 UTC
2e77666 URL: allow port specification in ssh:// URLs Allow port specification in ssh:// URLs in the usual notation: ssh://[user@]host.domain[:<port>]/<path> This allows git to be used over ssh-tunneling networks. Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 10:35:29 UTC
c7965af Avoid one-or-more (\+) non BRE in sed scripts. Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 09:35:30 UTC
7afa845 rebase -m: Fix incorrect short-logs of already applied commits. When a topic branch is rebased, some of whose commits are already cherry-picked upstream: o--X--A--B--Y <- master \ A--B--Z <- topic then 'git rebase -m master' would report: Already applied: 0001 Y Already applied: 0002 Y With this fix it reports the expected: Already applied: 0001 A Already applied: 0002 B As an added bonus, this change also avoids 'echo' of a commit message, which might contain escapements. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 09:23:05 UTC
aecbf91 git-diff: resurrect the traditional empty "diff --git" behaviour The warning message to suggest "Consider running git-status" from "git-diff" that we experimented with during the 1.5.3 cycle turns out to be a bad idea. It robbed cache-dirty information from people who valued it, while still asking users to run "update-index --refresh". It was hoped that the new behaviour would at least have some educational value, but not showing the cache-dirty paths like before meant that the user would not even know easily which paths were cache-dirty, and it made the need to refresh the index look like even more unnecessary chore. This commit reinstates the traditional behaviour, but with a twist. By default, the empty "diff --git" output is totally squelched out from "git diff" output. At the end of the command, it automatically runs "update-index --refresh" as needed, without even bothering the user. In other words, people who do not care about the cache-dirtyness do not even have to see the warning. The traditional behaviour to see the stat-dirty output and to bypassing the overhead of content comparison can be specified by setting the configuration variable diff.autorefreshindex to false. Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 06:30:14 UTC
18e32b5 git-tag: Fix -l option to use better shell style globs. This patch removes certain behaviour of "git tag -l foo", currently listing every tag name having "foo" as a substring. The same thing now could be achieved doing "git tag -l '*foo*'". This feature was added recently when git-tag.sh got the -n option for showing tag annotations, because that commit also replaced the old "grep pattern" behaviour with a more preferable "shell pattern" behaviour (although slightly modified as you can see). Thus, the following builtin-tag.c implemented it in order to ensure that tests were passing unchanged with both programs. Since common "shell patterns" match names with a given substring _only_ when * is inserted before and after (as in "*substring*"), and the "plain" behaviour cannot be achieved easily with the current implementation, this is mostly the right thing to do, in order to make it more flexible and consistent. Tests for "git tag" were also changed to reflect this. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 06:24:16 UTC
751eb39 git-svn: fix dcommit clobbering upstream when committing multiple changes Although dcommit could detect if the first commit in the series would conflict with the HEAD revision in SVN, it could not detect conflicts in further commits it made. Now we rebase each uncommitted change after each revision is committed to SVN to ensure that we are up-to-date. git-rebase will bail out on conflict errors if our next change cannot be applied and committed to SVN cleanly, preventing accidental clobbering of changes on the SVN-side. --no-rebase users will have trouble with this, and are thus warned if they are committing more than one commit. Fixing this for (hopefully uncommon) --no-rebase users would be more complex and will probably happen at a later date. Thanks to David Watson for finding this and the original test. Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 06:22:51 UTC
eeebd8d git-svn: Protect against "diff.color = true". If the configuration of the user has "diff.color = true", the output from "log" we invoke internally added color codes, which broke the parser. Signed-off-by: Junio C Hamano <gitster@pobox.com> Tested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Acked-by: Eric Wong <normalperson@yhbt.net> 01 September 2007, 06:22:51 UTC
f95eef1 filter-branch: introduce convenience function "skip_commit" With this function, a commit filter can leave out unwanted commits (such as temporary commits). It does _not_ undo the changeset corresponding to that commit, but it _skips_ the revision. IOW no tree object is changed by this. If you like to commit early and often, but want to filter out all intermediate commits, marked by "@@@" in the commit message, you can now do this with git filter-branch --commit-filter ' if git cat-file commit $GIT_COMMIT | grep '@@@' > /dev/null; then skip_commit "$@"; else git commit-tree "$@"; fi' newbranch Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 06:22:51 UTC
7e0f170 filter-branch: provide the convenience functions also for commit filters Move the convenience functions to the top of git-filter-branch.sh, and return from the script when the environment variable SOURCE_FUNCTIONS is set. By sourcing git-filter-branch with that variable set automatically, all commit filters may access the convenience functions like "map". Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 06:22:51 UTC
f0fd889 rebase -i: mention the option to split commits in the man page The interactive mode of rebase can be used to split commits. Tell the interested parties about it, with a dedicated section in the man page. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 06:22:51 UTC
0820366 filter-branch: fix remnants of old syntax in documentation Some time ago, filter-branch's syntax changed so that more than one ref can be rewritten at the same time. This involved the removal of the ref name for the result; instead, the refs are rewritten in-place. This updates the last leftovers in the documentation to reflect the new behavior. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 September 2007, 06:22:51 UTC
88e21dc Teach bash about completing arguments for git-tag Lately I have been doing a lot of calls to `git tag -d` and also to `git tag -v`. In both such cases being able to complete the names of existing tags saves the fingers some typing effort. We now look for the -d or -v option to git-tag in the bash completion support and offer up existing tag names as possible choices for these. When creating a new tag we now also offer bash completion support for the second argument to git-tag (the object to be tagged) as this can often be a specific existing branch name and is not necessarily the current HEAD. If the -f option is being used to recreate an existing tag we now also offer completion support on the existing tag names for the first argument of git-tag, helping to the user to reselect the prior tag name that they are trying to replace. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 01 September 2007, 03:47:01 UTC
e340d7d Hopefully the final update to draft release notes for 1.5.3. Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2007, 07:36:43 UTC
a65f200 Make "git-log --" without paths behave the same as "git-log" without -- "git log" family of commands, even when run from a subdirectory, do not limit the revision range with the current directory as the path limiter, but with double-dash without any paths after it, i.e. "git log --" do so. It was a mistake to have a difference between "git log --" and "git log" introduced in commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at libifying revlist generation). Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2007, 07:26:41 UTC
75d2449 git-init: autodetect core.symlinks We already autodetect if filemode is reliable on the filesystem to deal with VFAT and friends. Do the same for symbolic link support. Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2007, 07:25:04 UTC
608403d Make git-archimport log entries more consistent When appending the "git-archimport-id:" line to the end of log entries, git-archimport would use two blank lines as a separator when there was no body in the arch log (only a Summary: line), and zero blank lines when there was a body (making it hard to see the break between the actual log message and the git-archimport-id: line). This patch makes git-archimport generate one blank line as a separator in all cases. Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2007, 02:22:02 UTC
9e2d57a fix same sized delta logic The code favoring shallower deltas when size is equal was triggered only when previous delta was also cached. There should be no relation between cached deltas and same sized deltas. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2007, 02:18:31 UTC
55ced83 filter-branch: make sure orig_namespace ends with a single slash. Later in a loop any existing ref whose path begins with it is removed. It would be a disaster if you allowed it to say refs/head for example. Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2007, 02:17:42 UTC
back to top