Commit graph

172 commits

Author SHA1 Message Date
Junio C Hamano
e703d7118c parse-options: multi-word argh should use dash to separate words
"When you need to use space, use dash" is a strange way to say that
you must not use a space.  Because it is more common for the command
line descriptions to use dashed-multi-words, you do not even want to
use spaces in these places.  Rephrase the documentation to avoid
this strangeness.

Fix a few existing multi-word argument help strings, i.e.

 - GPG key-ids given to -S/--gpg-sign are "key-id";
 - Refs used for storing notes are "notes-ref"; and
 - Expiry timestamps given to --expire are "expiry-date".

and update the corresponding documentation pages.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-24 10:43:34 -07:00
Nicolas Vigier
3253553e12 cherry-pick, revert: add the --gpg-sign option
Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-27 15:15:52 -08:00
Junio C Hamano
f2c1b01c24 Merge branch 'hu/cherry-pick-previous-branch'
"git cherry-pick" without further options would segfault.

Could use a follow-up to handle '-' after argv[1] better.

* hu/cherry-pick-previous-branch:
  cherry-pick: handle "-" after parsing options
2013-10-23 13:21:35 -07:00
Jeff King
d644c5502f cherry-pick: handle "-" after parsing options
Currently, we only try converting argv[1] from "-" into "@{-1}".  This
means we do not notice "-" when used together with an option.  Worse,
when "git cherry-pick" is run with no options, we segfault.  Fix this
by doing the substitution after we have checked that there is
something in argv to cherry-pick and know any remaining options are
meant for the revision-listing machinery.

This still does not handle "-" after the first non-cherry-pick option.
For example,

	git cherry-pick foo~2 - bar~5

and

	git cherry-pick --no-merges -

will still dump usage.

Reported-by: Stefan Beller <stefanbeller@googlemail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-10-10 15:33:46 -07:00
Junio C Hamano
08092082b7 Merge branch 'hu/cherry-pick-previous-branch'
Just like "git checkout -" knows to check out and "git merge -"
knows to merge the branch you were previously on, "git cherry-pick"
now understands "git cherry-pick -" to pick from the previous
branch.

* hu/cherry-pick-previous-branch:
  cherry-pick: allow "-" as abbreviation of '@{-1}'
2013-09-20 12:29:58 -07:00
Hiroshige Umino
182d7dc46b cherry-pick: allow "-" as abbreviation of '@{-1}'
"-" abbreviation is handy for "cherry-pick" like "checkout" and "merge".

It's also good for uniformity that a "-" stands as
the name of the previous branch where a branch name is
accepted and it could not mean any other things like stdin.

Signed-off-by: Hiroshige Umino <hiroshige88@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09 11:17:11 -07:00
Stefan Beller
84d83f642a revert: use the OPT_CMDMODE for parsing, reducing code
The revert command comes with their own implementation of checking
for exclusiveness of parameters.
Now that the OPT_CMDMODE is in place, we can also rely on that macro
instead of cooking that solution for each command itself.

This commit also replaces OPT_BOOLEAN, which was deprecated by b04ba2bb
(parse-options: deprecate OPT_BOOLEAN, 2011-09-27). Instead OPT_BOOL is
used.

Signed-off-by: Stefan Beller <stefanbeller@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-07 08:37:12 -07:00
Ramsay Jones
9fe3edc47f Add the LAST_ARG_MUST_BE_NULL macro
The sentinel function attribute is not understood by versions of
the gcc compiler prior to v4.0. At present, for earlier versions
of gcc, the build issues 108 warnings related to the unknown
attribute. In order to suppress the warnings, we conditionally
define the LAST_ARG_MUST_BE_NULL macro to provide the sentinel attribute
for gcc v4.0 and newer.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-19 09:26:15 -07:00
Jeff King
eccb614924 use "sentinel" function attribute for variadic lists
This attribute can help gcc notice when callers forget to
add a NULL sentinel to the end of the function. This is our
first use of the sentinel attribute, but we shouldn't need
to #ifdef for other compilers, as __attribute__ is already a
no-op on non-gcc-compatible compilers.

Suggested-by: Bert Wesarg <bert.wesarg@googlemail.com>
More-Spots-Found-By: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 22:23:09 -07:00
Kevin Bracey
2130bf3ca9 cherry-pick/revert: make usage say '<commit-ish>...'
The usage string for cherry-pick and revert has never been updated to
reflect their ability to handle multiple commits. Other documentation is
already correct.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-24 09:48:01 -07:00
Junio C Hamano
c2b927932d Merge branch 'mz/cherry-pick-cmdline-order'
"git cherry-pick A C B" used to replay changes in A and then B and
then C if these three commits had committer timestamps in that
order, which is not what the user who said "A C B" naturally expects.

* mz/cherry-pick-cmdline-order:
  cherry-pick/revert: respect order of revisions to pick
  demonstrate broken 'git cherry-pick three one two'
  teach log --no-walk=unsorted, which avoids sorting
2012-09-10 15:42:55 -07:00
Junio C Hamano
096bbd6537 Merge branch 'nd/i18n-parseopt-help'
A lot of i18n mark-up for the help text from "git <cmd> -h".

* nd/i18n-parseopt-help: (66 commits)
  Use imperative form in help usage to describe an action
  Reduce translations by using same terminologies
  i18n: write-tree: mark parseopt strings for translation
  i18n: verify-tag: mark parseopt strings for translation
  i18n: verify-pack: mark parseopt strings for translation
  i18n: update-server-info: mark parseopt strings for translation
  i18n: update-ref: mark parseopt strings for translation
  i18n: update-index: mark parseopt strings for translation
  i18n: tag: mark parseopt strings for translation
  i18n: symbolic-ref: mark parseopt strings for translation
  i18n: show-ref: mark parseopt strings for translation
  i18n: show-branch: mark parseopt strings for translation
  i18n: shortlog: mark parseopt strings for translation
  i18n: rm: mark parseopt strings for translation
  i18n: revert, cherry-pick: mark parseopt strings for translation
  i18n: rev-parse: mark parseopt strings for translation
  i18n: reset: mark parseopt strings for translation
  i18n: rerere: mark parseopt strings for translation
  i18n: status: mark parseopt strings for translation
  i18n: replace: mark parseopt strings for translation
  ...
2012-09-07 11:09:09 -07:00
Martin von Zweigbergk
a73e22e963 cherry-pick/revert: respect order of revisions to pick
When giving multiple individual revisions to cherry-pick or revert, as
in 'git cherry-pick A B' or 'git revert B A', one would expect them to
be picked/reverted in the order given on the command line. They are
instead ordered by their commit timestamp -- in chronological order
for "cherry-pick" and in reverse chronological order for
"revert". This matches the order in which one would usually give them
on the command line, making this bug somewhat hard to notice. Still,
it has been reported at least once before [1].

It seems like the chronological sorting happened by accident because
the revision walker has traditionally always sorted commits in reverse
chronological order when rev_info.no_walk was enabled. In the case of
'git revert B A' where B is newer than A, this sorting is a no-op. For
'git cherry-pick A B', the sorting would reverse the arguments, but
because the sequencer also flips the rev_info.reverse flag when
picking (as opposed to reverting), the end result is a chronological
order. The rev_info.reverse flag was probably flipped so that the
revision walker emits B before C in 'git cherry-pick A..C'; that it
happened to effectively undo the unexpected sorting done when not
walking, was probably a coincidence that allowed this bug to happen at
all.

Fix the bug by telling the revision walker not to sort the commits
when not walking. The only case we want to reverse the order is now
when cherry-picking and walking revisions (rev_info.no_walk = 0).

 [1] http://thread.gmane.org/gmane.comp.version-control.git/164794

Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30 14:00:23 -07:00
Martin von Zweigbergk
ca92e59e30 teach log --no-walk=unsorted, which avoids sorting
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two revisions share the commit date, in which case they
will retain the order given on the command line). As the commit that
introduced --no-walk (8e64006 (Teach revision machinery about
--no-walk, 2007-07-24)) points out, the sorting is intentional, to
allow things like

 git log --abbrev-commit --pretty=oneline --decorate --all --no-walk

to show all refs in order by commit date.

But there are also other cases where the sorting is not wanted, such
as

 <command producing revisions in order> |
       git log --oneline --no-walk --stdin

To accomodate both cases, leave the decision of whether or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.

Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30 12:26:50 -07:00
Nguyễn Thái Ngọc Duy
a3b26dc78d i18n: revert, cherry-pick: mark parseopt strings for translation
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-20 12:23:20 -07:00
Chris Webb
4bee958479 cherry-pick: add --allow-empty-message option
Scripts such as "git rebase -i" cannot currently cherry-pick commits
which have an empty commit message, as git cherry-pick calls git
commit without the --allow-empty-message option.

Add an --allow-empty-message option to git cherry-pick which is passed
through to git commit, so this behaviour can be overridden.

Signed-off-by: Chris Webb <chris@arachsys.com>
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-06 09:59:53 -07:00
Junio C Hamano
1692579dd3 Merge branch 'nh/empty-rebase'
"git rebase" learned to optionally keep commits that do not introduce
any change in the original history.

By Neil Horman
* nh/empty-rebase:
  git-rebase: add keep_empty flag
  git-cherry-pick: Add test to validate new options
  git-cherry-pick: Add keep-redundant-commits option
  git-cherry-pick: add allow-empty option
2012-04-30 14:58:01 -07:00
Junio C Hamano
0fe59d7686 Merge branch 'cb/cherry-pick-rev-path-confusion'
The command line parser choked "git cherry-pick $name" when $name can be
both revision name and a pathname, even though $name can never be a path
in the context of the command.

The issue the patch addresses is real, but the way it is implemented felt
unnecessarily invasive a bit.  It may be cleaner for this caller to add
the "--" to the end of the argv_array it passes to setup_revisions().

By Clemens Buchacher
* cb/cherry-pick-rev-path-confusion:
  cherry-pick: do not expect file arguments
2012-04-27 13:58:02 -07:00
Neil Horman
b27cfb0d8d git-cherry-pick: Add keep-redundant-commits option
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal.  By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out.  This option allows us to override that behavior and
include redundant commits as empty commits in the change history.

Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run.  The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty).  With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24 14:52:12 -07:00
Junio C Hamano
8939cfb5cf Merge branch 'cc/fix-missing-va-end-in-revert'
By Christian Couder
* cc/fix-missing-va-end-in-revert:
  revert: add missing va_end
2012-04-24 14:41:16 -07:00
Christian Couder
5ba9b5e7e3 revert: add missing va_end
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-21 22:18:44 -07:00
Clemens Buchacher
6d5b93f29f cherry-pick: do not expect file arguments
If a commit-ish passed to cherry-pick or revert happens to have a file
of the same name, git complains that the argument is ambiguous and
advises to use '--'. To make things worse, the '--' argument is removed
by parse_options, und so passing '--' has no effect.

Instead, always interpret cherry-pick/revert arguments as revisions.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15 13:33:31 -07:00
Neil Horman
df478b744c git-cherry-pick: add allow-empty option
git cherry-pick fails when picking a non-ff commit that is empty.  The advice
given with the failure is that a git-commit --allow-empty should be issued to
explicitly add the empty commit during the cherry pick.  This option allows a
user to specify before hand that they want to keep the empty commit.  This
eliminates the need to issue both a cherry pick and a commit operation.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11 13:46:08 -07:00
Ramkumar Ramachandra
043a4492b3 sequencer: factor code out of revert builtin
Expose the cherry-picking machinery through a public
sequencer_pick_revisions() (renamed from pick_revisions() in
builtin/revert.c), so that cherry-picking and reverting are special
cases of a general sequencer operation.  The cherry-pick builtin is
now a thin wrapper that does command-line argument parsing before
calling into sequencer_pick_revisions().  In the future, we can write
a new "foo" builtin that calls into the sequencer like:

  memset(&opts, 0, sizeof(opts));
  opts.action = REPLAY_FOO;
  opts.revisions = xmalloc(sizeof(*opts.revs));
  parse_args_populate_opts(argc, argv, &opts);
  init_revisions(opts.revs);
  sequencer_pick_revisions(&opts);

This patch does not intend to make any functional changes.  Check
with:

  $ git blame -s -C HEAD^..HEAD -- sequencer.c | grep -C3 '^[^^]'

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-11 18:11:49 -08:00
Ramkumar Ramachandra
644a36908d revert: prepare to move replay_action to header
REVERT and CHERRY_PICK and are unsuitable names for an enumerator in a
public interface, because they are generic enough to be likely to
clash with identifiers with other meanings.  Rename to REPLAY_REVERT
and REPLAY_PICK as preparation for exposing them.

Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-11 18:08:22 -08:00
Junio C Hamano
c0129439d0 Merge branch 'rr/revert-cherry-pick'
* rr/revert-cherry-pick:
  t3502, t3510: clarify cherry-pick -m failure
  t3510 (cherry-pick-sequencer): use exit status
  revert: simplify getting commit subject in format_todo()
  revert: tolerate extra spaces, tabs in insn sheet
  revert: make commit subjects in insn sheet optional
  revert: free msg in format_todo()
2011-12-22 15:30:22 -08:00
Junio C Hamano
2e05710a16 Merge branch 'nd/resolve-ref'
* nd/resolve-ref:
  Rename resolve_ref() to resolve_ref_unsafe()
  Convert resolve_ref+xstrdup to new resolve_refdup function
  revert: convert resolve_ref() to read_ref_full()
2011-12-19 16:05:50 -08:00
Ramkumar Ramachandra
9e1313648d revert: simplify getting commit subject in format_todo()
format_todo() calls get_message(), but uses only the subject line of
the commit message.  As a minor optimization, save work and
unnecessary memory allocations by using find_commit_subject() instead.
Also, remove the unnecessary check on cur->item->buffer: the
lookup_commit_reference() call in parse_insn_line() has already made
sure of this.

Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15 13:16:52 -08:00
Ramkumar Ramachandra
0db76962d1 revert: tolerate extra spaces, tabs in insn sheet
Tolerate extra spaces and tabs as part of the the field separator in
'.git/sequencer/todo', for people with fat fingers.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15 13:15:46 -08:00
Ramkumar Ramachandra
6bc1a235b1 revert: make commit subjects in insn sheet optional
Change the instruction sheet format subtly so that the subject of the
commit message that follows the object name is optional.  As a result,
an instruction sheet like this is now perfectly valid:

  pick 35b0426
  pick fbd5bbcbc2e
  pick 7362160f

While at it, also fix a bug introduced by 5a5d80f4 (revert: Introduce
--continue to continue the operation, 2011-08-04) that failed to read
lines that are too long to fit on the commit-id-shaped buffer we
currently use; eliminate the need for the buffer altogether.  In
addition to literal SHA-1 hexes, you can now safely use expressions
like the following in the instruction sheet:

  featurebranch~4
  rr/revert-cherry-pick-continue^2~12@{12 days ago}

[jc: simplify parsing]

Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15 13:14:49 -08:00
Ramkumar Ramachandra
bf3de2b373 revert: free msg in format_todo()
Memory allocated to the fields of msg by get_message() isn't freed.
This is potentially a big leak, because fresh memory is allocated to
store the commit message for each commit.  Fix this using
free_message().

Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15 13:00:22 -08:00
Jonathan Nieder
d596118d7a revert: stop creating and removing sequencer-old directory
Now that "git reset" no longer implicitly removes .git/sequencer that
the operator may or may not have wanted to keep, the logic to write a
backup copy of .git/sequencer and remove it when stale is not needed
any more.  Simplify the sequencer API and repository layout by
dropping it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:33:53 -08:00
Jonathan Nieder
218b65fbf9 revert: do not remove state until sequence is finished
As v1.7.8-rc0~141^2~4 (2011-08-04) explains, git cherry-pick removes
the sequencer state just before applying the final patch.  In the
single-pick case, that was a good thing, since --abort and --continue
work fine without access to such state and removing it provides a
signal that git should not complain about the need to clobber it ("a
cherry-pick or revert is already in progress") in sequences like the
following:

	git cherry-pick foo
	git read-tree -m -u HEAD; # forget that; let's try a different one
	git cherry-pick bar

After the recent patch "allow single-pick in the middle of cherry-pick
sequence" we don't need that hack any more.  In the new regime, a
traditional "git cherry-pick <commit>" command never looks at
.git/sequencer, so we do not need to cripple "git cherry-pick
<commit>..<commit>" for it any more.

So now you can run "git cherry-pick --abort" near the end of a
multi-pick sequence and it will abort the entire sequence, instead of
misbehaving and aborting just the final commit.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:33:53 -08:00
Jonathan Nieder
7acaaac275 revert: allow single-pick in the middle of cherry-pick sequence
After messing up a difficult conflict resolution in the middle of a
cherry-pick sequence, it can be useful to be able to

	git checkout HEAD . && git cherry-pick that-one-commit

to restart the conflict resolution. The current code however errors out
saying that another cherry-pick is already in progress.

Suggested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:32:16 -08:00
Jonathan Nieder
7f13334e07 revert: pass around rev-list args in already-parsed form
Since 7e2bfd3f (revert: allow cherry-picking more than one commit,
2010-07-02), the pick/revert machinery has kept track of the set of
commits to be cherry-picked or reverted using commit_argc and
commit_argv variables, storing the corresponding command-line
parameters.

Future callers as other commands are built in (am, rebase, sequencer)
may find it easier to pass rev-list options to this machinery in
already-parsed form.  Teach cmd_cherry_pick and cmd_revert to parse
the rev-list arguments in advance and pass the commit set to
pick_revisions() as a rev_info structure.

Original patch by Jonathan, tweaks and test from Ram.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:32:16 -08:00
Jonathan Nieder
093a309136 revert: allow cherry-pick --continue to commit before resuming
When "git cherry-pick ..bar" encounters conflicts, permit the operator
to use cherry-pick --continue after resolving them as a shortcut for
"git commit && git cherry-pick --continue" to record the resolution
and carry on with the rest of the sequence.

This improves the analogy with "git rebase" (in olden days --continue
was the way to preserve authorship when a rebase encountered
conflicts) and fits well with a general UI goal of making "git cmd
--continue" save humans the trouble of deciding what to do next.

Example: after encountering a conflict from running "git cherry-pick
foo bar baz":

	CONFLICT (content): Merge conflict in main.c
	error: could not apply f78a8d98c... bar!
	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'

We edit main.c to resolve the conflict, mark it acceptable with "git
add main.c", and can run "cherry-pick --continue" to resume the
sequence.

	$ git cherry-pick --continue
	[editor opens to confirm commit message]
	[master 78c8a8c98] bar!
	 1 files changed, 1 insertions(+), 1 deletions(-)
	[master 87ca8798c] baz!
	 1 files changed, 1 insertions(+), 1 deletions(-)

This is done for both codepaths to pick multiple commits and a single
commit.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:31:32 -08:00
Jonathan Nieder
1df9bf46d6 revert: give --continue handling its own function
This makes pick_revisions() a little shorter and easier to read
straight through.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:06:36 -08:00
Nguyễn Thái Ngọc Duy
e4776bd936 revert: convert resolve_ref() to read_ref_full()
This is the follow up of c689332 (Convert many resolve_ref() calls to
read_ref*() and ref_exists() - 2011-11-13). See the said commit for
rationale.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 09:30:23 -08:00
Jonathan Nieder
b15aa973b2 revert --abort: do not leave behind useless sequencer-old directory
The "git cherry-pick --abort" command currently renames the
.git/sequencer directory to .git/sequencer-old instead of removing it
on success due to an accident.  cherry-pick --abort is designed to
work in three steps:

 1) find which commit to roll back to
 2) call "git reset --merge <commit>" to move to that commit
 3) remove the .git/sequencer directory

But the careless author forgot step 3 entirely.  The only reason the
command worked anyway is that "git reset --merge <commit>" renames the
.git/sequencer directory as a secondary effect --- after moving to
<commit>, or so the logic goes, it is unlikely but possible that the
caller of git reset wants to continue the series of cherry-picks that
was in progress, so git renames the sequencer state to
.git/sequencer-old to be helpful while allowing the cherry-pick to be
resumed if the caller did not want to end the sequence after all.

By running "git cherry-pick --abort", the operator has clearly
indicated that she is not planning to continue cherry-picking.  Remove
the (renamed) .git/sequencer directory as intended all along.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-23 10:56:29 -08:00
Johannes Sixt
2a4037d0a7 Fix revert --abort on Windows
On Windows, it is not possible to rename or remove a directory that has
open files. 'revert --abort' renamed .git/sequencer when it still had
.git/sequencer/head open. Close the file as early as possible to allow
the rename operation on Windows.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-23 10:54:57 -08:00
Nguyễn Thái Ngọc Duy
b4524d343b revert: do not pass non-literal string as format to git_path()
This fixes the following warning.

    CC builtin/revert.o
builtin/revert.c: In function ‘write_cherry_pick_head’:
builtin/revert.c:311: warning: format not a string literal and no format arguments

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-23 09:29:53 -08:00
Jonathan Nieder
c427b211b3 revert: remove --reset compatibility option
Remove the "git cherry-pick --reset" option, which has a different
preferred spelling nowadays ("--quit").  Luckily the old --reset name
was not around long enough for anyone to get used to it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22 18:18:02 -08:00
Jonathan Nieder
539047c19e revert: introduce --abort to cancel a failed cherry-pick
After running some ill-advised command like "git cherry-pick
HEAD..linux-next", the bewildered novice may want to return to more
familiar territory.  Introduce a "git cherry-pick --abort" command
that rolls back the entire cherry-pick sequence and places the
repository back on solid ground.

Just like "git merge --abort", this internally uses "git reset
--merge", so local changes not involved in the conflict resolution are
preserved.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22 18:16:59 -08:00
Jonathan Nieder
82433cdf4d revert: write REVERT_HEAD pseudoref during conflicted revert
When conflicts are encountered while reverting a commit, it can be
handy to have the name of that commit easily available.  For example,
to produce a copy of the patch to refer to while resolving conflicts:

	$ git revert 2eceb2a8
	error: could not revert 2eceb2a8... awesome, buggy feature
	$ git show -R REVERT_HEAD >the-patch
	$ edit $(git diff --name-only)

Set a REVERT_HEAD pseudoref when "git revert" does not make a commit,
for cases like this.  This also makes it possible for scripts to
distinguish between a revert that encountered conflicts and other
sources of an unmerged index.

After successfully committing, resetting with "git reset", or moving
to another commit with "git checkout" or "git reset", the pseudoref is
no longer useful, so remove it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22 13:34:44 -08:00
Jonathan Nieder
b8c74690b2 revert: improve error message for cherry-pick during cherry-pick
In the spirit of v1.6.3.3~3^2 (refuse to merge during a merge,
2009-07-01), "git cherry-pick" refuses to start a new cherry-pick when
in the middle of an existing conflicted cherry-pick in the following
sequence:

 1. git cherry-pick HEAD..origin
 2. resolve conflicts
 3. git cherry-pick HEAD..origin (instead of "git cherry-pick
    --continue", by mistake)

Good.  However, the error message on attempting step 3 is more
convoluted than necessary:

  $ git cherry-pick HEAD..origin
  error: .git/sequencer already exists.
  error: A cherry-pick or revert is in progress.
  hint: Use --continue to continue the operation
  hint: or --quit to forget about it
  fatal: cherry-pick failed

Clarify by removing the redundant first "error:" message, simplifying
the advice, and using lower-case and no full stops to be consistent
with other commands that prefix their messages with "error:", so it
becomes

  error: a cherry-pick or revert is already in progress
  hint: try "git cherry-pick (--continue | --quit)"
  fatal: cherry-pick failed

The "fatal: cherry-pick failed" line seems unnecessary, too, but
that can be fixed some other day.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22 13:33:49 -08:00
Jonathan Nieder
dffc860028 revert: rearrange pick_revisions() for clarity
Deal completely with "cherry-pick --quit" and --continue at the
beginning of pick_revisions(), leaving the rest of the function for
the more interesting "git cherry-pick <commits>" case.

No functional change intended.  The impact is just to unindent the
code a little.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22 13:33:01 -08:00
Jonathan Nieder
f80a87262a revert: rename --reset option to --quit
The option to "git cherry-pick" and "git revert" to discard the
sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
--reset to remove sequencer state, 2011-08-04) has a confusing name.
Change it now, while we still have the time.

The new name for "cherry-pick, please get out of my way, since I've
long forgotten about the sequence of commits I was cherry-picking when
you wrote that old .git/sequencer directory" is --quit.  Mnemonic:
this is analagous to quiting a program the user is no longer using ---
we just want to get out of the multiple-command cherry-pick procedure
and not to reset HEAD or rewind any other old state.

The "--reset" option is kept as a synonym to minimize the impact.  We
might consider dropping it for simplicity in a separate patch, though.

Adjust documentation and tests to use the newly preferred name (--quit)
instead of --reset.  While at it, let's clarify the short descriptions
of these operations in "-h" output.

Before:

	--reset		forget the current operation
	--continue	continue the current operation

After:

	--quit		end revert or cherry-pick sequence
	--continue	resume revert or cherry-pick sequence

Noticed-by: Phil Hord <phil.hord@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22 13:30:35 -08:00
Jonathan Nieder
418c9b176c do not let git_path clobber errno when reporting errors
Because git_path() calls vsnprintf(), code like

	fd = open(git_path("SQUASH_MSG"), O_WRONLY | O_CREAT, 0666);
	die_errno(_("Could not write to '%s'"), git_path("SQUASH_MSG"));

can end up printing an error indicator from vsnprintf() instead of
open() by mistake.  Store the path we are trying to write to in a
temporary variable and pass _that_ to die_errno(), so the messages
written by git cherry-pick/revert and git merge can avoid this source
of confusion.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-17 15:06:27 -08:00
Ramkumar Ramachandra
5e1e6b93d0 revert: prettify fatal messages
Some of the fatal messages printed by revert and cherry-pick look ugly
like the following:

  fatal: Could not open .git/sequencer/todo.: No such file or directory

The culprit here is that these callers of the die_errno() function did not
take it into account that the message string they give to it is followed
by ": <strerror>", hence the message typically should not end with the
full-stop.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-15 16:59:46 -08:00
Junio C Hamano
541b9cf146 Merge branch 'js/no-cherry-pick-head-after-punted'
* js/no-cherry-pick-head-after-punted:
  cherry-pick: do not give irrelevant advice when cherry-pick punted
  revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
2011-10-19 10:49:05 -07:00
Junio C Hamano
af543833d4 Merge branch 'jc/parse-options-boolean'
* jc/parse-options-boolean:
  apply: use OPT_NOOP_NOARG
  revert: use OPT_NOOP_NOARG
  parseopt: add OPT_NOOP_NOARG
  archive.c: use OPT_BOOL()
  parse-options: deprecate OPT_BOOLEAN

Conflicts:
	builtin/revert.c
2011-10-12 12:34:15 -07:00
Ramsay Jones
27c0f76884 Fix some "variable might be used uninitialized" warnings
In particular, gcc complains as follows:

        CC tree-walk.o
    tree-walk.c: In function `traverse_trees':
    tree-walk.c:347: warning: 'e' might be used uninitialized in this \
        function

        CC builtin/revert.o
    builtin/revert.c: In function `verify_opt_mutually_compatible':
    builtin/revert.c:113: warning: 'opt2' might be used uninitialized in \
        this function

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-09 13:28:04 -07:00
Junio C Hamano
278f7e6f6d Merge branch 'js/maint-no-cherry-pick-head-after-punted' into js/no-cherry-pick-head-after-punted
* js/maint-no-cherry-pick-head-after-punted:
  cherry-pick: do not give irrelevant advice when cherry-pick punted
  revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so

Conflicts:
	builtin/revert.c
2011-10-06 17:02:11 -07:00
Jay Soffian
82352cb633 cherry-pick: do not give irrelevant advice when cherry-pick punted
If a cherry-pick did not even start because the working tree had local
changes that would overlap with the operation, we shouldn't be advising
the users to resolve conflicts nor to conclude it with "git commit".

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 16:56:49 -07:00
Jay Soffian
9fa8aecdeb revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
do_pick_commit() writes out CHERRY_PICK_HEAD before invoking merge (either
via do_recursive_merge() or try_merge_command()) on the assumption that if
the merge fails it is due to conflict. However, if the tree is dirty, the
merge may not even start, aborting before do_pick_commit() can remove
CHERRY_PICK_HEAD.

Instead, defer writing CHERRY_PICK_HEAD till after merge has returned.
At this point we know the merge has either succeeded or failed due
to conflict. In either case, we want CHERRY_PICK_HEAD to be written
so that it may be picked up by the subsequent invocation of commit.

Note that do_recursive_merge() aborts if the merge cannot start, while
try_merge_command() returns a non-zero value other than 1.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 16:56:34 -07:00
Junio C Hamano
cd4093b603 Merge branch 'rr/revert-cherry-pick-continue'
* rr/revert-cherry-pick-continue:
  builtin/revert.c: make commit_list_append() static
  revert: Propagate errors upwards from do_pick_commit
  revert: Introduce --continue to continue the operation
  revert: Don't implicitly stomp pending sequencer operation
  revert: Remove sequencer state when no commits are pending
  reset: Make reset remove the sequencer state
  revert: Introduce --reset to remove sequencer state
  revert: Make pick_commits functionally act on a commit list
  revert: Save command-line options for continuing operation
  revert: Save data for continuing after conflict resolution
  revert: Don't create invalid replay_opts in parse_args
  revert: Separate cmdline parsing from functional code
  revert: Introduce struct to keep command-line options
  revert: Eliminate global "commit" variable
  revert: Rename no_replay to record_origin
  revert: Don't check lone argument in get_encoding
  revert: Simplify and inline add_message_to_msg
  config: Introduce functions to write non-standard file
  advice: Introduce error_resolve_conflict
2011-10-05 12:36:19 -07:00
René Scharfe
7cfc60576a revert: use OPT_NOOP_NOARG
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-28 12:46:32 -07:00
Junio C Hamano
fb3198c57f builtin/revert.c: make commit_list_append() static
There is nobody outside that calls into this helper function.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-11 15:29:21 -07:00
Junio C Hamano
7abd8fb36d Merge branch 'jn/plug-empty-tree-leak'
* jn/plug-empty-tree-leak:
  merge-recursive: take advantage of hardcoded empty tree
  revert: plug memory leak in "cherry-pick root commit" codepath
2011-08-25 16:00:29 -07:00
Jonathan Nieder
127f045222 revert: plug memory leak in "cherry-pick root commit" codepath
The empty tree passed as common ancestor to merge_trees() when
cherry-picking a parentless commit is allocated on the heap and never
freed.  Leaking such a small one-time allocation is not a very big
problem, but now that "git cherry-pick" can cherry-pick multiple
commits it can start to add up.

Avoid the leak by storing the fake tree exactly once in the BSS
section (i.e., use a static).  While at it, let's add a test to make
sure cherry-picking multiple parentless commits continues to work.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-16 10:51:34 -07:00
Ramkumar Ramachandra
cf3e2486d6 revert: Propagate errors upwards from do_pick_commit
Currently, revert_or_cherry_pick can fail in two ways.  If it
encounters a conflict, it returns a positive number indicating the
intended exit status for the git wrapper to pass on; for all other
errors, it calls die().  The latter behavior is inconsiderate towards
callers, as it denies them the opportunity to recover from errors and
do other things.

After this patch, revert_or_cherry_pick will still return a positive
return value to indicate an exit status for conflicts as before, while
for some other errors, it will print an error message and return -1
instead of die()-ing.  The cmd_revert and cmd_cherry_pick are adjusted
to handle the fatal errors by die()-ing themselves.

While the full benefits of this patch will only be seen once all the
"die" calls are replaced with calls to "error", its immediate impact
is to change some "fatal:" messages to say "error:" and to add a new
"fatal: cherry-pick failed" message at the end when the operation
fails.

Inspired-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08 09:28:46 -07:00
Ramkumar Ramachandra
5a5d80f4ca revert: Introduce --continue to continue the operation
Introduce a new "git cherry-pick --continue" command which uses the
information in ".git/sequencer" to continue a cherry-pick that stopped
because of a conflict or other error.  It works by dropping the first
instruction from .git/sequencer/todo and performing the remaining
cherry-picks listed there, with options (think "-s" and "-X") from the
initial command listed in ".git/sequencer/opts".

So now you can do:

  $ git cherry-pick -Xpatience foo..bar
  ... description conflict in commit moo ...
  $ git cherry-pick --continue
  error: 'cherry-pick' is not possible because you have unmerged files.
  fatal: failed to resume cherry-pick
  $ echo resolved >conflictingfile
  $ git add conflictingfile && git commit
  $ git cherry-pick --continue; # resumes with the commit after "moo"

During the "git commit" stage, CHERRY_PICK_HEAD will aid by providing
the commit message from the conflicting "moo" commit.  Note that the
cherry-pick mechanism has no control at this stage, so the user is
free to violate anything that was specified during the first
cherry-pick invocation.  For example, if "-x" was specified during the
first cherry-pick invocation, the user is free to edit out the message
during commit time.  Note that the "--signoff" option specified at
cherry-pick invocation time is not reflected in the commit message
provided by CHERRY_PICK_HEAD; the user must take care to add
"--signoff" during the "git commit" invocation.

Helped-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08 09:28:24 -07:00
Ramkumar Ramachandra
21afd08062 revert: Don't implicitly stomp pending sequencer operation
Protect the user from forgetting about a pending sequencer operation
by immediately erroring out when an existing cherry-pick or revert
operation is in progress like:

  $ git cherry-pick foo
  ... conflict ...
  $ git cherry-pick moo
  error: .git/sequencer already exists
  hint: A cherry-pick or revert is in progress
  hint: Use --reset to forget about it
  fatal: cherry-pick failed

A naive version of this would break the following established ways of
working:

  $ git cherry-pick foo
  ... conflict ...
  $ git reset --hard  # I actually meant "moo" when I said "foo"
  $ git cherry-pick moo

  $ git cherry-pick foo
  ... conflict ...
  $ git commit # commit the resolution
  $ git cherry-pick moo # New operation

However, the previous patches "reset: Make reset remove the sequencer
state" and "revert: Remove sequencer state when no commits are
pending" make sure that this does not happen.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08 09:24:51 -07:00
Ramkumar Ramachandra
2d27daa91d revert: Remove sequencer state when no commits are pending
When cherry-pick or revert is called on a list of commits, and a
conflict encountered somewhere in the middle, the data in
".git/sequencer" is required to continue the operation.  However, when
a conflict is encountered in the very last commit, the user will have
to "continue" after resolving the conflict and committing just so that
the sequencer state is removed.  This is how the current "rebase -i"
script works as well.

  $ git cherry-pick foo..bar
  ... conflict encountered while picking "bar" ...
  $ echo "resolved" >problematicfile
  $ git add problematicfile
  $ git commit
  $ git cherry-pick --continue # This would be a no-op

Change this so that the sequencer state is cleared when a conflict is
encountered in the last commit.  Incidentally, this patch makes sure
that some existing tests don't break when features like "--reset" and
"--continue" are implemented later in the series.

A better way to implement this feature is to get the last "git commit"
to remove the sequencer state.  However, that requires tighter
coupling between "git commit" and the sequencer, a goal that can be
pursued once the sequencer is made more general.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08 09:24:50 -07:00
Ramkumar Ramachandra
26ae337be1 revert: Introduce --reset to remove sequencer state
To explicitly remove the sequencer state for a fresh cherry-pick or
revert invocation, introduce a new subcommand called "--reset" to
remove the sequencer state.

Take the opportunity to publicly expose the sequencer paths, and a
generic function called "remove_sequencer_state" that various git
programs can use to remove the sequencer state in a uniform manner;
"git reset" uses it later in this series.  Introducing this public API
is also in line with our long-term goal of eventually factoring out
functions from revert.c into a generic commit sequencer.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:41:21 -07:00
Ramkumar Ramachandra
21b14778a9 revert: Make pick_commits functionally act on a commit list
Apart from its central objective of calling into the picking
mechanism, pick_commits creates a sequencer directory, prepares a todo
list, and even acts upon the "--reset" subcommand.  This makes for a
bad API since the central worry of callers is to figure out whether or
not any conflicts were encountered during the cherry picking.  The
current API is like:

  if (pick_commits(opts) < 0)
     print "Something failed, we're not sure what"

So, change pick_commits so that it's only responsible for picking
commits in a loop and reporting any errors, leaving the rest to a new
function called pick_revisions.  Consequently, the API of pick_commits
becomes much clearer:

  act_on_subcommand(opts->subcommand);
  todo_list = prepare_todo_list();
  if (pick_commits(todo_list, opts) < 0)
     print "Error encountered while picking commits"

Now, callers can easily call-in to the cherry-picking machinery by
constructing an arbitrary todo list along with some options.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:45 -07:00
Ramkumar Ramachandra
6f0322633b revert: Save command-line options for continuing operation
In the same spirit as ".git/sequencer/head" and ".git/sequencer/todo",
introduce ".git/sequencer/opts" to persist the replay_opts structure
for continuing after a conflict resolution.  Use the gitconfig format
for this file so that it looks like:

  [options]
	  signoff = true
	  record-origin = true
	  mainline = 1
	  strategy = recursive
	  strategy-option = patience
	  strategy-option = ours

Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:44 -07:00
Ramkumar Ramachandra
04d3d3cfc4 revert: Save data for continuing after conflict resolution
Ever since v1.7.2-rc1~4^2~7 (revert: allow cherry-picking more than
one commit, 2010-06-02), a single invocation of "git cherry-pick" or
"git revert" can perform picks of several individual commits.  To
implement features like "--continue" to continue the whole operation,
we will need to store some information about the state and the plan at
the beginning.  Introduce a ".git/sequencer/head" file to store this
state, and ".git/sequencer/todo" file to store the plan.  The head
file contains the SHA-1 of the HEAD before the start of the operation,
and the todo file contains an instruction sheet whose format is
inspired by the format of the "rebase -i" instruction sheet.  As a
result, a typical todo file looks like:

  pick 8537f0e submodule add: test failure when url is not configured
  pick 4d68932 submodule add: allow relative repository path
  pick f22a17e submodule add: clean up duplicated code
  pick 59a5775 make copy_ref globally available

Since SHA-1 hex is abbreviated using an find_unique_abbrev(), it is
unambiguous.  This does not guarantee that there will be no ambiguity
when more objects are added to the repository.

These two files alone are not enough to implement a "--continue" that
remembers the command-line options specified; later patches in the
series save them too.

These new files are unrelated to the existing .git/CHERRY_PICK_HEAD,
which will still be useful while committing after a conflict
resolution.

Inspired-by: Christian Couder <chriscool@tuxfamily.org>
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:44 -07:00
Ramkumar Ramachandra
9044143ff1 revert: Don't create invalid replay_opts in parse_args
The "--ff" command-line option cannot be used with some other
command-line options.  However, parse_args still parses these
incompatible options into a replay_opts structure for use by the rest
of the program.  Although pick_commits, the current gatekeeper to the
cherry-pick machinery, checks the validity of the replay_opts
structure before before starting its operation, there will be multiple
entry points to the cherry-pick machinery in future.  To futureproof
the code and catch these errors in one place, make sure that an
invalid replay_opts structure is not created by parse_args in the
first place.  We still check the replay_opts structure for validity in
pick_commits, but this is an assert() now to emphasize that it's the
caller's responsibility to get it right.

Inspired-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:43 -07:00
Ramkumar Ramachandra
89641472aa revert: Separate cmdline parsing from functional code
Currently, revert_or_cherry_pick sets up a default git config, parses
command-line arguments, before preparing to pick commits.  This makes
for a bad API as the central worry of callers is to assert whether or
not a conflict occured while cherry picking.  The current API is like:

  if (revert_or_cherry_pick(argc, argv, opts) < 0)
     print "Something failed, we're not sure what"

Simplify and rename revert_or_cherry_pick to pick_commits so that it
only has the responsibility of setting up the revision walker and
picking commits in a loop.  Transfer the remaining work to its
callers.  Now, the API is simplified as:

  if (parse_args(argc, argv, opts) < 0)
     print "Can't parse arguments"
  if (pick_commits(opts) < 0)
     print "Error encountered in picking machinery"

Later in the series, pick_commits will also serve as the starting
point for continuing a cherry-pick or revert.

Inspired-by: Christian Couder <chriscool@tuxfamily.org>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:43 -07:00
Ramkumar Ramachandra
80e1f79188 revert: Introduce struct to keep command-line options
The current code uses a set of file-scope static variables to tell the
cherry-pick/ revert machinery how to replay the changes, and
initializes them by parsing the command-line arguments.  In later
steps in this series, we would like to introduce an API function that
calls into this machinery directly and have a way to tell it what to
do.  Hence, introduce a structure to group these variables, so that
the API can take them as a single replay_options parameter.  The only
exception is the variable "me" -- remove it since it not an
independent option, and can be inferred from the action.

Unfortunately, this patch introduces a minor regression.  Parsing
strategy-option violates a C89 rule: Initializers cannot refer to
variables whose address is not known at compile time.  Currently, this
rule is violated by some other parts of Git as well, and it is
possible to get GCC to report these instances using the "-std=c89
-pedantic" option.

Inspired-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:43 -07:00
Ramkumar Ramachandra
708f9d96d9 revert: Eliminate global "commit" variable
Functions which act on commits currently rely on a file-scope static
variable to be set before they're called.  Consequently, the API and
corresponding callsites are ugly and unclear.  Remove this variable
and change their API to accept the commit to act on as additional
argument so that the callsites change from looking like

  commit = prepare_a_commit();
  act_on_commit();

to looking like

  commit = prepare_a_commit();
  act_on_commit(commit);

This change is also in line with our long-term goal of exposing some
of these functions through a public API.

Inspired-by: Christian Couder <chriscool@tuxfamily.org>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:42 -07:00
Ramkumar Ramachandra
54decbd4d8 revert: Rename no_replay to record_origin
The "-x" command-line option is used to record the name of the
original commits being picked in the commit message.  The variable
corresponding to this option is named "no_replay" for historical
reasons; the name is especially confusing because the term "replay" is
used to describe what cherry-pick does (for example, in the
documentation of the "--mainline" option).  So, give the variable
corresponding to the "-x" command-line option a better name:
"record_origin".

Mentored-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:42 -07:00
Ramkumar Ramachandra
a2ec3ad28f revert: Don't check lone argument in get_encoding
The only place get_encoding uses the global "commit" variable is when
writing an error message explaining that its lone argument was NULL.
Since the function's only caller ensures that a NULL argument isn't
passed, we can remove this check with two beneficial consequences:

1. Since the function doesn't use the global "commit" variable any
   more, it won't need to change when we eliminate the global variable
   later in the series.
2. Translators no longer need to localize an error message that will
   never be shown.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Mentored-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:42 -07:00
Ramkumar Ramachandra
be33c46cda revert: Simplify and inline add_message_to_msg
The add_message_to_msg function has some dead code, an unclear API,
only one callsite.  While it originally intended fill up an empty
commit message with the commit object name while picking, it really
doesn't do this -- a bug introduced in v1.5.1-rc1~65^2~2 (Make
git-revert & git-cherry-pick a builtin, 2007-03-01).  Today, tests in
t3505-cherry-pick-empty.sh indicate that not filling up an empty
commit message is the desired behavior.  Re-implement and inline the
function accordingly, with a beneficial side-effect: don't dereference
a NULL pointer when the commit doesn't have a delimeter after the
header.

Helped-by: Junio C Hamano <gitster@pobox.com>
Mentored-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:41 -07:00
Ramkumar Ramachandra
38ef61cfde advice: Introduce error_resolve_conflict
Enable future callers to report a conflict and not die immediately by
introducing a new function called error_resolve_conflict.
Re-implement die_resolve_conflict as a call to error_resolve_conflict
followed by a call to die.  Consequently, the message printed by
die_resolve_conflict changes from

  fatal: 'commit' is not possible because you have unmerged files.
         Please, fix them up in the work tree ...
         ...

to

  error: 'commit' is not possible because you have unmerged files.
  hint: Fix them up in the work tree ...
  hint: ...
  fatal: Exiting because of an unresolved conflict.

Hints are printed using the same advise function introduced in
v1.7.3-rc0~26^2~3 (Introduce advise() to print hints, 2010-08-11).

Inspired-by: Christian Couder <chistian.couder@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:41 -07:00
Jeff King
fad2652673 revert: allow reverting a root commit
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-05-16 13:01:45 -07:00
Ramkumar Ramachandra
5e31075a19 revert: Hide '-r' option in default usage
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-13 11:02:49 -07:00
Junio C Hamano
6c80cd298a Merge branch 'ab/i18n-st'
* 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-04-01 17:55:55 -07:00
Ævar Arnfjörð Bjarmason
cb6aeb22ac i18n: git-revert split up "could not revert/apply" message
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-09 23:52:57 -08:00
Ævar Arnfjörð Bjarmason
b9c993e017 i18n: git-revert literal "me" messages
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-09 23:52:57 -08:00
Ævar Arnfjörð Bjarmason
d3ee177e50 i18n: git-revert "Your local changes" message
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-09 23:52:57 -08:00
Ævar Arnfjörð Bjarmason
f30f71ce7a i18n: git-revert basic messages
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09 23:52:57 -08:00
Junio C Hamano
66ecd2d053 Merge branch 'js/cherry-pick-usability'
* 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-03-09 15:56:17 -08:00
Jay Soffian
37f7a85793 Teach commit about CHERRY_PICK_HEAD
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-21 22:58:32 -08:00
Jay Soffian
d7e5c0cbfb Introduce CHERRY_PICK_HEAD
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>
2011-02-21 22:58:02 -08:00
Jonathan Nieder
67ac1e1d57 cherry-pick/revert: add support for -X/--strategy-option
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-12-28 11:27:56 -08:00
Junio C Hamano
5eee142c89 Merge branch 'jn/cherry-pick-refresh-index'
* jn/cherry-pick-refresh-index:
  cherry-pick/revert: transparently refresh index
2010-11-29 17:52:34 -08:00
Jonathan Nieder
f6ce1f2588 cherry-pick/revert: transparently refresh index
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-11-10 08:49:26 -08:00
Brandon Casey
6355e505ba builtin/revert.c: don't dereference a NULL pointer
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-27 10:39:54 -07:00
Junio C Hamano
8aed4a5e38 Merge branch 'jn/merge-renormalize'
* 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-09-03 09:43:41 -07:00
Junio C Hamano
ae76cb90cb Merge branch 'jn/cherry-revert-message-clean-up'
* 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-31 16:25:11 -07:00
Junio C Hamano
165dc789d5 Merge branch 'cc/find-commit-subject'
* 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-18 12:46:55 -07:00
Jonathan Nieder
314eeb6e48 cherry-pick/revert: Use advise() for hints
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-15 19:12:08 -07:00
Jonathan Nieder
981ff5c37a cherry-pick/revert: Use error() for failure message
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-15 19:12:07 -07:00
Jonathan Nieder
2a41dfb03b Introduce advise() to print hints
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-15 19:12:05 -07:00
Jonathan Nieder
130ab8ab9c Eliminate “Finished cherry-pick/revert” message
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-15 19:12:00 -07:00
Jonathan Nieder
7610fa57e6 merge-recursive --renormalize
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-08-06 09:20:02 -07:00
Christian Couder
dfe7effe7d revert: rename variables related to subject in get_message()
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-23 16:10:58 -07:00
Christian Couder
11af2aaed6 revert: refactor code to find commit subject in find_commit_subject()
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-23 16:09:28 -07:00