Now all the users of this script detect its exit status and die,
complaining that it is outside git repository. So move the code
that dies from all callers to git-sh-setup script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Luben Tuikov noticed that sometimes being able to say
'git-format-patch <commit>' to format the change a single commit
introduces relative to its parent is handy.
This patch does not support that directly, but it makes sense to
interpret a single argument "rev" to mean "rev^1..rev".
With this, the backward compatibility syntaxes still apply:
- "format-patch master" means "format-patch master..HEAD"
- "format-patch origin master" means "format-patch origin..master"
- "format-patch origin.." means "format-patch origin..HEAD"
But "format-patch a b c d e" formats the changes these five
commits introduce relative to their respective parents. Earlier
it rejected these arguments not in "one..two" form.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I noticed format-patch loses authorship information of Lukas' patch
when I run git tools with LC_LANG set to ja_JP. It turns out that
the sed script to set environment variables were not working on his
name (encoded in UTF-8), which is unfortunate but technically correct.
Force sed invocation under C locale because we always want literal byte
semantics.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Refactored fetch options into separate fetch-options.txt.
Made git-merge use merge-options.
Made git-fetch use fetch-options.
Made git-pull use merge-options and fetch-options.
Added --help option to git-pull and git-format-patch scripts.
Rewrote Documentation/Makefile to dynamically determine
include dependencies.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This enhances set of revs you can give format-patch.
Originally, format-patch took either one rev, or two revs:
format-patch rev1
format-patch rev1 rev2
The first format was a short-hand for "format-patch rev1 HEAD"
(i.e. rev2==HEAD). What this meant was to find commits that are
in branch rev2 that has not been merged to branch rev1.
The above notation is still supported, but now it takes sequence
of "from1..to1 from2..to2 ...". In short, the second format has
become a short-hand for "format-patch rev1..rev2". Commits in
to1 but not in from1, to2 but not in from2, ... are formatted as
emailable patches.
With this, cherry-picking from other branch can be written as:
git-format-patch -k --stdout master..branch1 master..branch2 |
git-am -k -3
which is generally faster than traditional cherry-pick (which
always did 3-way merge) if patches apply cleanly, and still
falls back on 3-way merge if some of them do not.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This new flag generates the mbox formatted output to the standard
output, instead of saving them into a file per patch and implies --mbox.
It also fixes a corner case where the commit does not have *any* message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There was a leftover use of sed that attempted to remove the commit ID
output from git-diff-tree, which turned into an expensive no-op when
git-diff-tree output header format changed about three months ago.
Drop it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This switches the logic to pick which commits to include in the output
from git-rev-list to git-cherry; as a side effect, 'format-patch ^up mine'
would stop working although up..mine would continue to work.
Signed-off-by: Junio C Hamano <junkio@cox.net>
As promised, this is the "big tool rename" patch. The primary differences
since 0.99.6 are:
(1) git-*-script are no more. The commands installed do not
have any such suffix so users do not have to remember if
something is implemented as a shell script or not.
(2) Many command names with 'cache' in them are renamed with
'index' if that is what they mean.
There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support is expected to be removed in the near
future.
Signed-off-by: Junio C Hamano <junkio@cox.net>
