The parser was inconsistently done, in that it did not look at
the last command line parameter to see if it could be an unknown
option, although it was designed to notice unknown options if
they were given in positions the command expects to find them
(i.e. everything except the last parameter, which ought to be
<commit-ish>). This prevented a very natural invocation
$ git cherry-pick --usage
from issuing the usage help.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now write to MERGE_MSG, not .msg. I missed this earlier
when I changed the target we write to.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than storing the temporary commit message data in .msg (in
the working tree) we now store the message data in .git/MERGE_MSG.
By storing the message in the .git/ directory we are sure we will
never have a collision with a user file, should a project actually
have a ".msg" file in their top level tree. We also don't need to
worry about leaving this stale file behind during a `reset --hard`
and have it show up in the output of status.
We are using .git/MERGE_MSG here to store the temporary message as
it is an already established convention between git-merge, git-am
and git-rebase that git-commit will default the user's edit buffer
to the contents of .git/MERGE_MSG. If the user is going to need
to resolve this commit or wants to edit the message on their own
prepping that file with the desired message "just works".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When converting from the shell script, based on a misreading of the
sed invocation, the builtin included the abbreviated commit name,
and did _not_ include the quotes around the oneline message.
This fixes it.
[jc: with a fix for the typo/thinko spotted by Linus, and also
removing the unwanted abbrev at the beginning.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new builtin-revert code introduces a few new compiler errors
when I'm building with my stricter set of checks enabled in CFLAGS.
These all just stem from trying to store a constant string into
a non-const char*. Simple fix, make the variables const char*.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Another change by me is removing the va_list variants of run_command,
one of which is used by builtin-revert.c. To avoid compile errors
I'm refactoring builtin-revert to use the char** variant instead,
as that variant is staying.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somewhere along the line (in abd6970a) git-revert.sh learned to
omit the private object name from the new commit message *unless*
-x was supplied on the command line by the user.
The way this was implemented is really non-obvious in the original
script. Setting replay=t (the default) means we don't include the
the private object name, while setting reply='' (the -x flag) means
we should include the private object name. These two settings now
relate to the replay=1 and replay=0 cases in the C version, so we
need to negate replay to test it is 0.
I also noticed the C version was adding an extra LF in the -x case,
where the older git-revert.sh was not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a cherry-pick failed, we used to recommend setting environment
variables to retain the authorship. It is much easier, though, to use
the "-c" flag of git-commit.
Print this message also when merge-recursive fails (the code used to
exit(1) in that case, never reaching the proper failure path).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
