Of the many ways to spell the three-letter word, the variant "Git"
should be used when referring to a repository in a description; or, in
general, when it is used as a proper noun.
We thus change the pull-request template message so that it reads
"...in the Git repository at:"
Besides, this brings us in line with the documentation, see
Documentation/howto/using-signed-tag-in-pull-request.txt
Signed-off-by: Ann T Ropea <bedhanger@gmx.de>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
request-pull uses OPTIONS_SPEC, so no need for (meanwhile incomplete)
USAGE and LONG_USAGE anymore.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Older versions of Git before v1.7.10 did not DWIM
$ git pull $URL for-linus
to the tag "tags/for-linus" and the users were required to say
$ git pull $URL tags/for-linus
instead. Because newer versions of Git works either way,
request-pull used to show tags/for-linus when asked
$ git request-pull origin/master $URL for-linus
The recent updates broke this and in the output we see "for-linus"
without the "tags/" prefix.
As v1.7.10 is more than 2 years old, this should matter very little
in practice, but resurrecting it is very simple.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Discard the accumulated "heuristics" to guess from which branch the
result wants to be pulled from and make sure what the end user
specified is not second-guessed by "git request-pull", to avoid
mistakes.
* lt/request-pull:
request-pull: documentation updates
request-pull: resurrect "pretty refname" feature
request-pull: test updates
request-pull: pick up tag message as before
request-pull: allow "local:remote" to specify names on both ends
request-pull: more strictly match local/remote branches
When asking to fetch/pull a branch whose name is B or a tag whose
name is T, we used to show the command to run as:
git pull $URL B
git pull $URL tags/T
even when B and T were spelled in a more qualified way in order to
disambiguate, e.g. heads/B or refs/tags/T, but the recent update
lost this feature. Resurrect it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous two steps were meant to stop updating the explicit
refname the user gave to the command to a different ref that points
at it. Most notably, we no longer substitute a branch name the user
used with a name of the tag that points at the commit at the tip of
the branch (it still can be done with "local-branch:remote-tag").
However, they also lost the code that included the message in a
tag when the user _did_ ask the tag to be pulled. Resurrect it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows a user to say that a local branch has a different name on
the remote server, using the same syntax that "git push" uses to create
that situation.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).
To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).
The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse
option parsing is done in --stuck-long mode.
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>
Several of the built shell commands invoke a bare "perl" to
perform some one-liners. This will use the first perl in the
PATH rather than the one specified by the user's SHELL_PATH.
We are not asking these perl invocations to do anything
exotic, so typically any old system perl will do; however,
in some cases the system perl may have unexpected behavior
(e.g., by handling line endings differently). We should err
on the side of using the perl the user pointed us to.
The downside of this is that on systems with a sane perl
setup, we no longer find the perl at runtime, but instead
point to a static perl (like /usr/bin/perl). That means we
will not handle somebody moving perl without rebuilding git,
whereas before we tracked it just fine. This is probably not
a big deal, though, as the built perl scripts already
suffered from this.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, when an invalid revision is specified, the error message is:
fatal: Needed a single revision
This is misleading because, you might think there is something wrong
with the command line as a whole.
Now the user gets a more meaningful error message, showing the invalid
revision.
Signed-off-by: Dirk Wallenstein <halsmit@t-online.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After tagging the tip of "dev" branch with a "for-linus" tag and
pushing both out, running
$ git request-pull $url $last_release dev
would produce an output asking the 'dev' branch of $url to be
pulled, because that is what the user asked the message to say.
We already detect this situation locally and include the contents of
the tag in the output; if the $url has that tag, favor that tag
(i.e. "for-linus") in the generated message over the branch name the
user gave us (i.e. "dev") from the command line, to make the output
look more consistent.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When asking for a tag to be pulled, disambiguate by leaving tags/ prefix
in front of the name of the tag. E.g.
... in the git repository at:
git://example.com/git/git.git/ tags/v1.2.3
for you to fetch changes up to 123456...
This way, older versions of "git pull" can be used to respond to such a
request more easily, as "git pull $URL v1.2.3" did not DWIM to fetch
v1.2.3 tag in older versions. Also this makes it clearer for humans that
the pull request is made for a tag and he should anticipate a signed one.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command takes the "start" argument and computes the merge base
between it and the commit to be pulled so that we can show the diffstat,
but uses the "start" argument as-is when composing the message
The following changes since commit $X are available
to tell the integrator which commit the work is based on. Giving "origin"
(most of the time it resolves to refs/remotes/origin/master) as the start
argument is often convenient, but it is usually not the fork point, and
does not help the integrator at all.
Use the real fork point, which is the merge base we already compute, when
composing that part of the message.
Suggested-by: Linus Torvalds
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The whole point of the recent update to allow "git pull $url $tagname" is
so that the integrator does not have to store the (signed) tag that is
used to convey authenticity to be recorded in the resulting merge in the
local repository's tag namespace. Asking for a merge be made with "git
pull $url tag $tagname" defeats it.
Note that the request can become ambiguous if the requestor has a branch
with the same name as the tag, but that is not a new problem limited to
pulling. I wouldn't mind if somebody wants to add disambiguation to the
find_matching_ref logic in the script as a separate patch, though.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old code that insisted on asking for the tip of a branch to be pulled
were not updated when we started allowing for a tag to be pulled. When a
tag points at an older part of the history and there is no branch that
points at the tagged commit, the script failed to say which ref is to be
pulled.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The integrator tool will start allowing to pull a signed or an annotated
tag, i.e.
$ git pull $there tags/for-linus
and the description in the tag is used to convey a meaningful message from
the lieutenant to the integrator to justify the history being pulled.
Include the message in the pull request e-mail, as the same information is
useful in this context, too. It would encourage the lieutenants to write
meaningful messages in their signed tags.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now we have branch descriptions stored in the repository, we can
use it when preparing the request-pull message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The message gives a detailed explanation of the commit the requester based
the changes on, but lacks information that is necessary for the person who
performs a fetch & merge in order to verify that the correct branch was
fetched when responding to the pull request.
Add a few more lines to describe the commit at the tip expected to be
fetched to the same level of detail as the base commit.
Also update the warning message slightly when the script notices that the
commit may not have been pushed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So sh:get_remote_url can go now and git-request-pull
doesn't need to source git-parse-remote. anymore.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The -e option causes the shell to exit immediately when a command exits
with a non-zero exit status. This does not seem to cause a problem for
Bash, but it does cause a problem for the Korn shell, like Solaris's
xpg4/sh, whose unset utility returns non-zero if it is passed a variable
name which was not previously set. When using xpg4/sh, git-request-pull
exits while sourcing git-sh-setup since git-sh-setup tries to unset the
CDPATH environment variable.
When git-request-pull was originally written, it did not do any error
checking and it used this shell feature to exit when an error occurred.
This script now performs proper error checking and provides useful error
messages, so this -e option appears to be merely a historical artifact and
can be removed.
Kudos to Jonathan Nieder for introducing t5150 which exercises the
request-pull code path.
Suggested-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like most git commands, request-pull supports a -- delimiter to allow
callers to pass arguments that would otherwise be treated as an option
afterwards. The internal OPTIONS_KEEPDASHDASH variable is passed
empty to git-sh-setup to indicate that request-pull itself does not
care about the position of the -- delimiter. But if the user has
that variable in her environment, request-pull will see the “--” and
fail.
Empty it explicitly to guard against this. While at it, make the
corresponding fix to git-resurrect, too (all other scripts in git.git
already protect themselves).
Acked-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously we ran shortlog on the start commit which always printed
"(1)" after the start commit, which gives no information, but makes the
output less easy to read. Instead of giving the author name of the
commit, use the space for committer timestamp to help recipient judge
the freshness of the offered branch more easily.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow git request-pull to append diff body into the pull request.
It's useful for small series of commits.
Tested-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The location to pull from should be converted from the configured nickname
to URL in the message, but ls-remote should be fed the nickname so that
the command uses remote.$nickname.* variables, most notably "uploadpack".
Signed-off-by: Tom Grennan <tgrennan@redback.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier 476cc72 (request-pull: really disable pager, 2009-06-30)
tried to use the correct environment variable to disable paging
from multiple calls to "git log" and friends, but there was one
extra call to "git log" that was not covered by the trick.
Move the setting and exporting of GIT_PAGER much earlier in the
script to cover everybody.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ff06c74 (Improve request-pull to handle non-rebased branches, 2007-05-01)
attempted to disable pager when running subcommands in this script, but
with a wrong variable. If GIT_PAGER is set, it takes precedence over
PAGER.
Noticed by Michal Marek.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The usage string of 'git request-pull' differs from he manpage
which gives the correct 'synopsis'.
Signed-off-by: Stefan Naewe <stefan.naewe@atlas-elektronik.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 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>
