summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2008-06-09git-read-tree: document -v option.Libravatar Miklos Vajna1-0/+3
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-08Remove exec bit from builtin-fast-export.cLibravatar Johannes Sixt1-0/+0
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-07GIT 1.5.5.4Libravatar Junio C Hamano4-3/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-06git-for-each-ref.txt: minor improvementsLibravatar Lea Wiemann1-8/+9
Rewrapped synopsis and removed wrong asterisk behind --count option; clarified --sort=<key> description for multiple keys; documented that for-each-ref supports not only glob patterns but also prefixes like "refs/heads" as patterns, and that multiple patterns can be given. Signed-off-by: Lea Wiemann <LeWiemann@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-05name-rev: Fix segmentation fault when using --allLibravatar Björn Steinbrink1-2/+6
In commit da2478db "describe --always: fall back to showing an abbreviated object name" we lost the check that skips empty entries in the object hash table when iterating over it in cmd_name_rev. That may cause a NULL pointer being handed to show_name(), leading to a segmentation fault. So add that check back again. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-04describe: match pattern for lightweight tags tooLibravatar Michael Dressel2-4/+27
The <pattern> given "git describe --match" was used only to filter tag objects, and not to filter lightweight tags. This fixes it. [jc: made the log to clarify this is a bugfix, not an enhancement, with additional test] Signed-off-by: Michael Dressel <MichaelTiloDressel@t-online.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-27GIT 1.5.5.3Libravatar Junio C Hamano4-3/+17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-27commit --interactive: properly update the index before commitingLibravatar Gerrit Pape1-0/+2
When adding files through git commit --interactive, and 'quit' afterwards, the message in the editor of the commit message indicates that many (maybe all) files are deleted from the tree. Dismissing that and running git commit afterwards does the right thing. This commit fixes git commit --interactive to properly update the index before commiting. Reported by Jiří Paleček through http://bugs.debian.org/480429 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-27gitweb: only display "next" links in logs if there is a next pageLibravatar Lea Wiemann1-4/+4
There was a bug in the implementation of the "next" links in format_paging_nav (for log and shortlog), which caused the next links to always be displayed, even if there is no next page. This fixes it. Signed-off-by: Lea Wiemann <LeWiemann@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-27Revert "filter-branch: subdirectory filter needs --full-history"Libravatar Johannes Sixt2-12/+3
This reverts commit cfabd6eee1745cfec58cfcb794ce8847e43b888a. I had implemented it without understanding what --full-history does. Consider this history: C--M--N / / / A--B / \ / D-/ where B and C modify a path, X, in the same way so that the result is identical, and D does not modify it at all. With the path limiter X and without --full-history this is simplified to A--B i.e. only one of the paths via B or C is chosen. I had assumed that --full-history would keep both paths like this C--M / / A--B removing the path via D; but in fact it keeps the entire history. Currently, git does not have the capability to simplify to this intermediary case. However, the other extreme to keep the entire history is not wanted either in usual cases. I think we can expect that histories like the above are rare, and in the usual cases we want a simplified history. So let's remove --full-history again. (Concerning t7003, subsequent tests depend on what the test case sets up, so we can't just back out the entire test case.) Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-27Documentation/git-bundle.txt: fix synopsisLibravatar Gerrit Pape1-1/+1
The <git-rev-list args> are mandatory to git bundle create, not optional. The usage output of git bundle is already right on this. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-26Merge branch 'gp/bisect-fix' into maintLibravatar Junio C Hamano3-10/+55
* gp/bisect-fix: bisect: print an error message when "git rev-list --bisect-vars" fails git-bisect.sh: don't accidentally override existing branch "bisect"
2008-05-26Documentation: fix graph in git-rev-parse.txtLibravatar Michele Ballabio1-10/+12
Preformatted html and man pages show a mangled graph, caused by a backslash. Commit f1ec6b22a8c1ab1cca0f1875f85aea5d2434e5a6 fixed this same issue, but it seems that new versions of the Asciidoc toolchain changed their behaviour. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-26show-branch --current: do not barf on detached HEADLibravatar Junio C Hamano1-2/+2
The code assumed that there always is the current branch, but the result from resolve_ref() on detached HEAD does not even start with "refs/heads/". Originally noticed and fixed by Stephan Beyer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25Merge branch 'jk/maint-send-email-compose' into maintLibravatar Junio C Hamano2-2/+100
* jk/maint-send-email-compose: send-email: rfc2047-quote subject lines with non-ascii characters send-email: specify content-type of --compose body
2008-05-25Merge branch 'hb/maint-send-email-quote-recipients' into maintLibravatar Junio C Hamano1-1/+1
* hb/maint-send-email-quote-recipients: Fix recipient santitization
2008-05-25Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-5/+1
* maint-1.5.4: builtin-fast-export: Only output a single parent per line
2008-05-25builtin-fast-export: Only output a single parent per lineLibravatar Pieter de Bie1-5/+1
According to the git-fast-import man-page, you can only put a single committish per merge: line, like this: merge :10 merge :11 However, git-fast-export puts all parents on a single line, like this: merge :10 :11 This changes fast-export to output a single parent per line. Otherwise neither git-fast-import nor bzr-fast-import can read its output. [jc: fix-up to remove excess LF in the output that makes fast-import barf] Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25Release Notes for 1.5.5.2Libravatar Junio C Hamano2-1/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-23Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-6/+12
* maint-1.5.4: rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref
2008-05-23rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a refLibravatar Johannes Sixt1-6/+12
The intention of --symbolic-full-name is to not print anything if a revision is not an exact ref. But this command: $ git-rev-parse --symbolic-full-name --not master~1 still emitted a sole '^' to stdout (provided that there's no other ref at master~1). This fixes it. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22Add missing "short" alternative to --date in rev-list-options.txtLibravatar Heikki Orsila1-1/+1
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22git-show.txt: Not very stubby these days.Libravatar Jon Loeliger1-2/+0
Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22Clarify repack -n documentationLibravatar Shawn O. Pearce1-2/+5
While repacking a local repository a coworker thought the -n option was necessary to git-repack to keep it from updating some unknown file on the central server we all share. Explaining further what the option is (not) doing helps to make it clear the option does not impact any remote repositories the user may have configured. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano2-3/+3
* maint-1.5.4: git-am: fix typo in usage message doc/git-daemon: s/uploadarchive/uploadarch/
2008-05-21Fix recipient santitizationLibravatar Horst H. von Brand1-1/+1
Need to quote all special characters, not just the first one Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21send-email: rfc2047-quote subject lines with non-ascii charactersLibravatar Jeff King2-2/+32
We always use 'utf-8' as the encoding, since we currently have no way of getting the information from the user. This also refactors the quoting of recipient names, since both processes can share the rfc2047 quoting code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21send-email: specify content-type of --compose bodyLibravatar Jeff King2-0/+68
If the compose message contains non-ascii characters, then we assume it is in utf-8 and include the appropriate MIME headers. If the user has already included a MIME-Version header, then we assume they know what they are doing and don't add any headers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-19git-am: fix typo in usage messageLibravatar Jeff King1-1/+1
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-19doc/git-daemon: s/uploadarchive/uploadarch/Libravatar Jeff King1-2/+2
The git-daemon upload-archive feature has always used the config directive 'daemon.uploadarch'; the documentation which came later seems to have just mistakenly used the wrong name. Noticed by lionel@over-blog.com. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-16git-filter-branch: Clarify file removal example.Libravatar Jon Loeliger1-0/+4
Signed-off-by: Jon Loeliger <jdl@jdl.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-14Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-3/+4
* maint-1.5.4: Documentation/git-describe.txt: make description more readable
2008-05-14Documentation/git-describe.txt: make description more readableLibravatar Ian Hilt1-3/+4
Signed-off-by: Ian Hilt <ian.hilt@gmail.com> Credit-to: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano3-3/+4
* maint-1.5.4: wt-status.h: declare global variables as extern builtin-commit.c: add -u as short name for --untracked-files git-repack: re-enable parsing of -n command line option
2008-05-11wt-status.h: declare global variables as externLibravatar Johannes Sixt1-2/+2
There are linkers out there that complain if a global non-static variable is defined multiple times. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11builtin-commit.c: add -u as short name for --untracked-filesLibravatar Sitaram Chamarty1-1/+1
This makes the C code consistent with the documentation and the old shell code. Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11git-repack: re-enable parsing of -n command line optionLibravatar A Large Angry SCM1-0/+1
In commit 5715d0b (Migrate git-repack.sh to use git-rev-parse --parseopt, 2007-11-04), parsing of the '-n' command line option was accidentally lost when git-repack.sh was migrated to use git-rev-parse --parseopt. This adds it back. Signed-off-by: A Large Angry SCM <gitzilla@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-08Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano2-2/+5
* maint-1.5.4: Documentation/config.txt: Mention branch.<name>.rebase applies to "git pull" doc: clarify definition of "update" for git-add -u
2008-05-08bisect: print an error message when "git rev-list --bisect-vars" failsLibravatar Christian Couder2-2/+24
Before this patch no error was printed when "git rev-list --bisect-vars" failed. This can happen when bad and good revs are mistaken. This patch prints an error message on stderr that describe the likely failure cause. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-08Documentation/config.txt: Mention branch.<name>.rebase applies to "git pull"Libravatar Dustin Sallings1-1/+2
Signed-off-by: Dustin Sallings <dustin@spy.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-08doc: clarify definition of "update" for git-add -uLibravatar Jeff King1-1/+3
The "-u" option is described only in terms of "updating" files, which in turn is described only as "similar to what git commit -a does". Let's be a little more specific about what updating entails. Suggested by Geoffrey Irving. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05git-bisect.sh: don't accidentally override existing branch "bisect"Libravatar Gerrit Pape3-8/+31
If a branch named "bisect" or "new-bisect" already was created in the repo by other means than git bisect, doing a git bisect used to override the branch without a warning. Now if the branch "bisect" or "new-bisect" already exists, and it was not created by git bisect itself, git bisect start fails with an appropriate error message. Additionally, if checking out a new bisect state fails due to a merge problem, git bisect cleans up the temporary branch "new-bisect". The accidental override has been noticed by Andres Salomon, reported through http://bugs.debian.org/478647 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-03Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-2/+2
* maint-1.5.4: filter-branch: Documentation fix.
2008-05-03checkout: don't rfc2047-encode oneline on detached HEADLibravatar Jeff King1-1/+1
When calling pretty_print_commit, there is an implicit assumption that passing in a non-NULL "subject" variable for oneline or email formats means that the output is part of a subject and therefore "subject" to rfc2047 encoding. This is not the desired effect when reporting the movement of detached HEAD. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-03filter-branch: Documentation fix.Libravatar Florian Ragwitz1-2/+2
It's --msg-filter, not --message-filter. Signed-off-by: Florian Ragwitz <rafl@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-30fetch-pack: brown paper bag fixLibravatar Junio C Hamano1-1/+1
When I applied Linus's patch from the list by hand somehow I ended up reversing the logic by mistake. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-29Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano2-3/+6
* maint-1.5.4: cvsimport: always pass user data to "system" as a list fix reflog approxidate parsing bug
2008-04-29cvsimport: always pass user data to "system" as a listLibravatar Jeff King1-1/+1
This avoids invoking the shell. Not only is it faster, but it prevents the possibility of interpreting our arguments in the shell. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-29fix reflog approxidate parsing bugLibravatar Jeff King1-2/+5
In get_sha1_basic, we parse a string like HEAD@{10 seconds ago}:path/to/file into its constituent ref, reflog date, and path components. We never actually munge the string itself, but instead keep offsets into the string with their associated lengths. When we call approxidate on the contents inside braces, however, we pass just a string without a length. This means that approxidate could sometimes look past the closing brace and (erroneously) interpret the rest of the string as part of the date. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-28Fix use after free() in builtin-fetchLibravatar Alex Riesen1-3/+5
As reported by Dave Jones: Since master.kernel.org updated to latest, I noticed that I could crash git-fetch by doing this.. export KERNEL=/pub/scm/linux/kernel/git/ git fetch $KERNEL/torvalds/linux-2.6 master:linus (gdb) bt 0 0x000000349fd6d44b in free () from /lib64/libc.so.6 1 0x000000000048f4eb in transport_unlock_pack (transport=0x7ce530) at transport.c:811 2 0x000000349fd31b25 in exit () from /lib64/libc.so.6 3 0x00000000004043d8 in handle_internal_command (argc=3, argv=0x7fffea4449f0) at git.c:379 4 0x0000000000404547 in main (argc=3, argv=0x7fffea4449f0) at git.c:443 5 0x000000349fd1c784 in __libc_start_main () from /lib64/libc.so.6 6 0x0000000000403ef9 in ?? () 7 0x00007fffea4449d8 in ?? () 8 0x0000000000000000 in ?? () I then remembered, my .bashrc has this.. export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) which is handy for showing up such bugs. More info on this glibc feature is at http://udrepper.livejournal.com/11429.html Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-13 21:23:03 +0000