* ph/parseopt-sh:
git-quiltimport.sh fix --patches handling
git-am: -i does not take a string parameter.
sh-setup: don't let eval output to be shell-expanded.
git-sh-setup: fix parseopt `eval` string underquoting
Give git-am back the ability to add Signed-off-by lines.
git-rev-parse --parseopt
scripts: Add placeholders for OPTIONS_SPEC
Migrate git-repack.sh to use git-rev-parse --parseopt
Migrate git-quiltimport.sh to use git-rev-parse --parseopt
Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash
Migrate git-instaweb.sh to use git-rev-parse --parseopt
Migrate git-merge.sh to use git-rev-parse --parseopt
Migrate git-am.sh to use git-rev-parse --parseopt
Migrate git-clone to use git-rev-parse --parseopt
Migrate git-clean.sh to use git-rev-parse --parseopt.
Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt
Add a parseopt mode to git-rev-parse to bring parse-options to shell scripts.
--text follows this line--
These commands currently lack OPTIONS_SPEC; allow people to
easily list with "git grep 'OPTIONS_SPEC=$'" what they can help
improving.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is actually a few different changes to request-pull,
making it slightly smarter:
1) Minor cleanup of revision->base variable names, making it
follow the head/headrev naming convention that is already
in use.
2) Compute the merge-base between the two revisions upfront
and reuse that selected merge-base to create the diffstat.
3) Refuse to generate a pull request for branches that have no
existing relationship. These aren't very common and would mess
up our diffstat generation.
4) Disable the PAGER when running shortlog and diff, as these
would otherwise activate the pager for each command when
git-request-pull is run on a tty. Instead users can get the
entire output paged (if desired) using `git -p request-pull`.
5) Use shortlog rather than `git log | git shortlog` now that
recent shortlog versions are able to run the revision listing
internally.
6) Attempt to resolve the input URL using the user's configured
remotes. This is useful if the URL you want the recipient to
see is also the one you used to push your changes. If not a
config-file remote could easily be setup for the public URL
and request-pull could be passed that name instead.
7) Automatically guess and include the remote branch name in the
body of the message. We list the branch name immediately after
the URL, making it easy for the recipient to copy and paste
the entire line onto a `git pull` command line. Rumor has it
Linus likes this format, for exactly that reason.
If multiple branches at the remote match $headrev we take the
first one returned by peek-remote and assume it is suitable.
If no branches are available we warn the user about the problem,
but insert a static string that is not a valid branch name
and would be obvious to anyone reading the message as being
totally incorrect. This allows users to still generate a
template message without network access (for example) and
hand-correct the bits that cannot be verified.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Linus recommended this, otherwise any renames cause the
diffstat output to be ridiculous in some circumstances.
Because the corresponding "git-pull" done when the requestee
actually makes pull shows the stat with rename detection
enabled, it makes sense to match what the request message
includes to that output, to make the result easier to verify.
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
