summaryrefslogtreecommitdiff
path: root/builtin/revert.c
AgeCommit message (Collapse)AuthorFilesLines
2011-05-16revert: allow reverting a root commitLibravatar Jeff King1-3/+1
Although it is probably an uncommon operation, there is no reason to disallow it, as it works just fine. It is the reverse of a cherry-pick of a root commit, which is already allowed. We do have to tweak one check on whether we have a merge commit, which assumed we had at least one parent. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13revert: Hide '-r' option in default usageLibravatar Ramkumar Ramachandra1-1/+2
The '-r' command-line option is a no-op provided only for backward compatiblity since abd6970 (cherry-pick: make -r the default, 2006-10-05), and somehow ended up surviving across reimplementation in C at 9509af6 (Make git-revert & git-cherry-pick a builtin, 2007-03-01) and another rewrite of the command line parser at f810379 (Make builtin-revert.c use parse_options, 2007-10-07). We should have stopped advertising the option long time ago. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01Merge branch 'ab/i18n-st'Libravatar Junio C Hamano1-30/+42
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh
2011-03-09i18n: git-revert split up "could not revert/apply" messageLibravatar Ævar Arnfjörð Bjarmason1-2/+3
Split up the "could not %s %s... %s" message into "could not revert %s... %s" and "could not apply %s... %s". This makes it easier for translators to understand the message. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-revert literal "me" messagesLibravatar Ævar Arnfjörð Bjarmason1-2/+5
Translate messages that use the `me' variable. These are all error messages referencing the command name, so the name shouldn't be translated. Reported-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-revert "Your local changes" messageLibravatar Ævar Arnfjörð Bjarmason1-5/+13
Translate the "Your local changes [...]" message without using the `me' variable, instead split up the two messages so translators can translate the whole messages as-is. Reported-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-revert basic messagesLibravatar Ævar Arnfjörð Bjarmason1-23/+23
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09Merge branch 'js/cherry-pick-usability'Libravatar Junio C Hamano1-53/+22
* js/cherry-pick-usability: Teach commit about CHERRY_PICK_HEAD bash: teach __git_ps1 about CHERRY_PICK_HEAD Introduce CHERRY_PICK_HEAD t3507: introduce pristine-detach helper
2011-02-21Teach commit about CHERRY_PICK_HEADLibravatar Jay Soffian1-55/+1
Previously the user was advised to use commit -c CHERRY_PICK_HEAD after a conflicting cherry-pick. While this would preserve the original commit's authorship, it would sadly discard cherry-pick's carefully crafted MERGE_MSG (which contains the list of conflicts as well as the original commit-id in the case of cherry-pick -x). On the other hand, if a bare 'commit' were performed, it would preserve the MERGE_MSG while resetting the authorship. In other words, there was no way to simultaneously take the authorship from CHERRY_PICK_HEAD and the commit message from MERGE_MSG. This change fixes that situation. A bare 'commit' will now take the authorship from CHERRY_PICK_HEAD and the commit message from MERGE_MSG. If the user wishes to reset authorship, that must now be done explicitly via --reset-author. A side-benefit of passing commit authorship along this way is that we can eliminate redundant authorship parsing code from revert.c. (Also removed an unused include from revert.c) Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21Introduce CHERRY_PICK_HEADLibravatar Jay Soffian1-2/+25
When a cherry-pick conflicts git advises: $ git commit -c <original commit id> to preserve the original commit message and authorship. Instead, let's record the original commit id in CHERRY_PICK_HEAD and advise: $ git commit -c CHERRY_PICK_HEAD A later patch teaches git to handle the '-c CHERRY_PICK_HEAD' part. Note that we record CHERRY_PICK_HEAD even in the case where there are no conflicts so that we may use it to communicate authorship to commit; this will then allow us to remove set_author_ident_env from revert.c. However, we do not record CHERRY_PICK_HEAD when --no-commit is used, as presumably the user intends to further edit the commit and possibly even cherry-pick additional commits on top. Tests and documentation contributed by Jonathan Nieder. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-28cherry-pick/revert: add support for -X/--strategy-optionLibravatar Jonathan Nieder1-7/+22
For example, this would allow cherry-picking or reverting patches from a piece of history with a different end-of-line style, like so: $ git revert -Xrenormalize old-problematic-commit Currently that is possible with manual use of merge-recursive but the cherry-pick/revert porcelain does not expose the functionality. While at it, document the existing support for --strategy. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29Merge branch 'jn/cherry-pick-refresh-index'Libravatar Junio C Hamano1-2/+16
* jn/cherry-pick-refresh-index: cherry-pick/revert: transparently refresh index
2010-11-10cherry-pick/revert: transparently refresh indexLibravatar Jonathan Nieder1-2/+16
A stat-dirty index is not a detail that ought to concern the operator of porcelain such as "git cherry-pick". Without this change, a cherry-pick after copying a worktree with rsync errors out with a misleading message. $ git cherry-pick build/top error: Your local changes to 'file.h' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Noticed-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27builtin/revert.c: don't dereference a NULL pointerLibravatar Brandon Casey1-1/+1
cherry-pick will segfault when transplanting a root commit if the --ff option is used. This happens because the "parent" pointer is set to NULL when the commit being cherry-picked has no parents. Later, when "parent" is dereferenced, the cherry-pick segfaults. Fix this by checking whether "parent" is NULL before dereferencing it and add a test for this case of cherry-picking a root commit with --ff. Reported-by: Zbyszek Szmek <zbyszek@in.waw.pl> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03Merge branch 'jn/merge-renormalize'Libravatar Junio C Hamano1-0/+7
* jn/merge-renormalize: merge-recursive --renormalize rerere: never renormalize rerere: migrate to parse-options API t4200 (rerere): modernize style ll-merge: let caller decide whether to renormalize ll-merge: make flag easier to populate Documentation/technical: document ll_merge merge-trees: let caller decide whether to renormalize merge-trees: push choice to renormalize away from low level t6038 (merge.renormalize): check that it can be turned off t6038 (merge.renormalize): try checkout -m and cherry-pick t6038 (merge.renormalize): style nitpicks Don't expand CRLFs when normalizing text during merge Try normalizing files to avoid delete/modify conflicts when merging Avoid conflicts when merging branches with mixed normalization Conflicts: builtin/rerere.c t/t4200-rerere.sh
2010-08-31Merge branch 'jn/cherry-revert-message-clean-up'Libravatar Junio C Hamano1-69/+70
* jn/cherry-revert-message-clean-up: tests: fix syntax error in "Use advise() for hints" test cherry-pick/revert: Use advise() for hints cherry-pick/revert: Use error() for failure message Introduce advise() to print hints Eliminate “Finished cherry-pick/revert” message t3508: add check_head_differs_from() helper function and use it revert: improve success message by adding abbreviated commit sha1 revert: don't print "Finished one cherry-pick." if commit failed revert: refactor commit code into a new run_git_commit() function revert: report success when using option --strategy
2010-08-18Merge branch 'cc/find-commit-subject'Libravatar Junio C Hamano1-15/+5
* cc/find-commit-subject: blame: use find_commit_subject() instead of custom code merge-recursive: use find_commit_subject() instead of custom code bisect: use find_commit_subject() instead of custom code revert: rename variables related to subject in get_message() revert: refactor code to find commit subject in find_commit_subject() revert: fix off by one read when searching the end of a commit subject
2010-08-15cherry-pick/revert: Use advise() for hintsLibravatar Jonathan Nieder1-23/+11
When cherry-pick fails after picking a large series of commits, it can be hard to pick out the error message and advice. Prefix the advice with “hint: ” to help. Before: error: could not apply 7ab78c9... foo After resolving the conflicts, mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result with: git commit -c 7ab78c9a7898b87127365478431289cb98f8d98f After: error: could not apply 7ab78c9... foo hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit -c 7ab78c9' Noticed-by: Thomas Rast <trast@student.ethz.ch> Encouraged-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-15cherry-pick/revert: Use error() for failure messageLibravatar Jonathan Nieder1-2/+5
When cherry-pick fails after picking a large series of commits, it can be hard to pick out the error message and advice. Clarify the error and prefix it with “error: ” to help. Before: Automatic cherry-pick failed. [...advice...] After: error: could not apply 7ab78c9... Do something neat. [...advice...] Noticed-by: Thomas Rast <trast@student.ethz.ch> Encouraged-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-15Introduce advise() to print hintsLibravatar Jonathan Nieder1-0/+9
Like error(), warn(), and die(), advise() prints a short message with a formulaic prefix to stderr. It is local to revert.c for now because I am not sure this is the right API (we may want to take an array of advice lines or a boolean argument for easy suppression of unwanted advice). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-15Eliminate “Finished cherry-pick/revert” messageLibravatar Jonathan Nieder1-2/+0
When cherry-pick was written (v0.99.6~63, 2005-08-27), “git commit” was quiet, and the output from cherry-pick provided useful information about the progress of a rebase. Now next to the output from “git commit”, the cherry-pick notification is so much noise (except for the name of the picked commit). $ git cherry-pick ..topic Finished cherry-pick of 499088b. [detached HEAD 17e1ff2] Move glob module to libdpkg Author: Guillem Jover <guillem@debian.org> 8 files changed, 12 insertions(+), 9 deletions(-) rename {src => lib/dpkg}/glob.c (98%) rename {src => lib/dpkg}/glob.h (93%) Finished cherry-pick of ae947e1. [detached HEAD 058caa3] libdpkg: Add missing symbols to Versions script Author: Guillem Jover <guillem@debian.org> 1 files changed, 2 insertions(+), 0 deletions(-) $ The noise is especially troublesome when sifting through the output of a rebase or multiple cherry-pick that eventually failed. With the commit subject, it is already not hard to figure out where the commit came from. So drop the “Finished” message. Cc: Christian Couder <chriscool@tuxfamily.org> Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06merge-recursive --renormalizeLibravatar Jonathan Nieder1-0/+7
Teach "git merge-recursive" a --renormalize option to enable the merge.renormalize configuration. The --no-renormalize option can be used to override it in the negative. So in the future, you might be able to, e.g.: git checkout -m -Xrenormalize otherbranch or git revert -Xrenormalize otherpatch or git pull --rebase -Xrenormalize The bad part: merge.renormalize is still not honored for most commands. And it reveals lots of places that -X has not been plumbed in (so we get "git merge -Xrenormalize" but not much else). NEEDSWORK: tests Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-23revert: rename variables related to subject in get_message()Libravatar Christian Couder1-5/+5
Generic-looking pointer variable "p" was used only to point at subject string and had a rather lifespan. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-23revert: refactor code to find commit subject in find_commit_subject()Libravatar Christian Couder1-12/+2
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-23revert: fix off by one read when searching the end of a commit subjectLibravatar Christian Couder1-1/+1
A test case is added but the problem can only be seen when running the test case with --valgrind. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-16revert: improve success message by adding abbreviated commit sha1Libravatar Christian Couder1-2/+3
Instead of saying "Finished one cherry-pick." or "Finished one revert.", we now say "Finished cherry-pick of commit <abbreviated sha1>." or "Finished revert of commit <abbreviated sha1>." which is more informative, especially when cherry-picking or reverting many commits. In case of failure the message is now "Automatic cherry-pick of commit <abbreviated sha1> failed." instead of "Automatic cherry-pick failed." Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-16revert: don't print "Finished one cherry-pick." if commit failedLibravatar Christian Couder1-12/+5
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-16revert: refactor commit code into a new run_git_commit() functionLibravatar Christian Couder1-25/+27
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-16revert: report success when using option --strategyLibravatar Christian Couder1-22/+29
"git cherry-pick foo" has always reported success with "Finished one cherry-pick" but "cherry-pick --strategy" does not print anything. So move the code to write that message from do_recursive_merge() to do_cherry_pick() so other strategies can share it. This patch also refactors the code that prints a message like "Automatic cherry-pick failed. <help message>". This code was duplicated in both do_recursive_merge() and do_pick_commit(). To do that, now do_recursive_merge() returns an int to signal success or failure. And in case of failure we just return 1 from do_pick_commit() instead of doing "exit(1)" from either do_recursive_merge() or do_pick_commit(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-29revert: do not rebuild argv on heapLibravatar Jonathan Nieder1-16/+16
Set options in struct rev_info directly so we can reuse the arguments collected from parse_options without modification. This is just a cleanup; no noticeable change is intended. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25revert: accept arbitrary rev-list optionsLibravatar Christian Couder1-1/+2
This can be useful to do something like: git rev-list --reverse master -- README | git cherry-pick -n --stdin without using xargs. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02revert: allow cherry-picking more than one commitLibravatar Christian Couder1-10/+41
This makes it possible to pass many commits or ranges of commits to "git cherry-pick" and to "git revert" to process many commits instead of just one. In fact commits are now enumerated with an equivalent of git rev-list --no-walk "$@" so all the following are now possible: git cherry-pick master~2..master git cherry-pick ^master~2 master git cherry-pick master^ master The following should be possible but does not work: git cherry-pick -2 master because "git rev-list --no-walk -2 master" only outputs one commit as "--no-walk" seems to take over "-2". And there is currently no way to continue cherry-picking or reverting if there is a problem with one commit. It's also not possible to abort the whole process. Some future work should provide the --continue and --abort options to do just that. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02revert: change help_msg() to take no argumentLibravatar Christian Couder1-4/+4
This is needed because the following commits will make it possible to cherry-pick many commits instead of just one. So it will be possible to pass for example ranges of commits to "git cherry-pick" and this means that it will not be possible to use the arguments passed to "git cherry-pick" in the help message. The help message will have to use the sha1 of the currently processed commit. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02revert: refactor code into a do_pick_commit() functionLibravatar Christian Couder1-19/+25
This is needed because we are going to make it possible to cherry-pick many commits instead of just one in the following commits. And we will be able to do that by just calling do_pick_commit() once for each commit to cherry-pick. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02revert: use run_command_v_opt() instead of execv_git_cmd()Libravatar Christian Couder1-2/+9
This is needed by the following commits, because we are going to cherry pick many commits instead of just one. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02revert: cleanup code for -x optionLibravatar Christian Couder1-7/+1
There was some dead code and option -x appeared in the short help message of git revert (when running "git revert -h") which was wrong. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-08Merge branch 'cc/revert-strategy'Libravatar Junio C Hamano1-74/+105
* cc/revert-strategy: revert: add "--strategy" option to choose merge strategy merge: make function try_merge_command non static merge: refactor code that calls "git merge-STRATEGY" revert: refactor merge recursive code into its own function revert: use strbuf to refactor the code that writes the merge message Conflicts: builtin/revert.c
2010-05-08cherry-pick: do not dump core when iconv failsLibravatar Jonathan Nieder1-2/+7
When cherry-picking, usually the new and old commit encodings are both UTF-8. Most old iconv implementations do not support this trivial conversion, so on old platforms, out->message remains NULL, and later attempts to read it segfault. Fix this by noticing the input and output encodings match and skipping the iconv step, like the other reencode_string() call sites already do. Also stop segfaulting on other iconv failures: if iconv fails for some other reason, the best we can do is to pass the old message through. This fixes a regression introduced in v1.7.1-rc0~15^2~2 (revert: clarify label on conflict hunks, 2010-03-20). Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-03Merge branch 'jn/merge-diff3-label'Libravatar Junio C Hamano1-39/+64
* jn/merge-diff3-label: merge-recursive: add a label for ancestor cherry-pick, revert: add a label for ancestor revert: clarify label on conflict hunks compat: add mempcpy() checkout -m --conflict=diff3: add a label for ancestor merge_trees(): add ancestor label parameter for diff3-style output merge_file(): add comment explaining behavior wrt conflict style checkout --conflict=diff3: add a label for ancestor ll_merge(): add ancestor label parameter for diff3-style output merge-file --diff3: add a label for ancestor xdl_merge(): move file1 and file2 labels to xmparam structure xdl_merge(): add optional ancestor label to diff3-style output tests: document cherry-pick behavior in face of conflicts tests: document format of conflicts from checkout -m Conflicts: builtin/revert.c
2010-04-01revert: add "--strategy" option to choose merge strategyLibravatar Christian Couder1-2/+23
This patch makes it possible to use a different merge strategy when cherry-picking. This is usefull mainly for debugging purposes as it allows to see if some failures are caused by the merge strategy used or not. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-01revert: refactor merge recursive code into its own functionLibravatar Christian Couder1-48/+58
The code that is used to do a recursive merge is extracted from the revert_or_cherry_pick() function and put into a new do_recursive_merge() function. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-01revert: use strbuf to refactor the code that writes the merge messageLibravatar Christian Couder1-36/+34
The code in this commit was written by Stephan Beyer for the sequencer GSoC project: git://repo.or.cz/git/sbeyer.git Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28Merge branch 'cc/cherry-pick-ff'Libravatar Junio C Hamano1-4/+42
* cc/cherry-pick-ff: revert: fix tiny memory leak in cherry-pick --ff rebase -i: use new --ff cherry-pick option Documentation: describe new cherry-pick --ff option cherry-pick: add tests for new --ff option revert: add --ff option to allow fast forward when cherry-picking builtin/merge: make checkout_fast_forward() non static parse-options: add parse_options_concat() to concat options
2010-03-20cherry-pick, revert: add a label for ancestorLibravatar Jonathan Nieder1-1/+4
When writing conflict hunks in ‘diff3 -m’ format, also add a label to the common ancestor. Especially in a cherry-pick, it is not immediately obvious without such a label what the common ancestor represents. git rerere does not have trouble parsing the new output and its preimage ids are unchanged since it includes its own code for recreating conflict hunks. No other code in git parses conflict hunks. Requested-by: Stefan Monnier <monnier@iro.umontreal.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-20revert: clarify label on conflict hunksLibravatar Jonathan Nieder1-39/+62
When reverting a commit, the commit being merged is not the commit to revert itself but its parent. Add “parent of” to the conflict hunk label to make this more clear. The conflict hunk labels are all pieces of a single string written in the new get_message() function. Avoid some complication by using mempcpy to advance a pointer as the result is written. Also free the corresponding temporary buffer (it was leaked before). This is not important because it is a small one-time allocation. It would become a memory leak if unnoticed when libifying revert. This patch uses calls to strlen() instead of integer constants in some places. GCC will compute the length at compile time; I am not sure about other compilers, but this is not performance-critical anyway. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+460
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>