path: root/
AgeCommit message (Collapse)Author
2019-05-28request-pull: warn if the remote object is not the same as the local onePaolo Bonzini
In some cases, git request-pull might be invoked with remote and local objects that differ even though they point to the same commit. For example, the remote object might be a lightweight tag vs. an annotated tag on the local side; or the user might have reworded the tag locally and forgotten to push it. When this happens git-request-pull will not warn, because it only checks that "git ls-remote" returns an SHA1 that matches the local commit (known as $headrev in the script). This patch makes git-request-pull retrieve the tag object SHA1 while processing the "git ls-remote" output, so that it can be matched against the local object. Signed-off-by: Paolo Bonzini <> Signed-off-by: Junio C Hamano <>
2019-05-28request-pull: quote regex metacharacters in local refPaolo Bonzini
The local part of the third argument of git-request-pull is used in a regular expression without quoting it. Use qr{} and \Q\E to ensure that e.g. a period in a tag name does not match any character on the remote side. Signed-off-by: Paolo Bonzini <> Signed-off-by: Junio C Hamano <>
2017-10-03request-pull: capitalise "Git" to make it a proper nounAnn T Ropea
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 " 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 <> Acked-by: Jonathan Nieder <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2017-01-16request-pull: drop old USAGE stuffWolfram Sang
request-pull uses OPTIONS_SPEC, so no need for (meanwhile incomplete) USAGE and LONG_USAGE anymore. Signed-off-by: Wolfram Sang <> Signed-off-by: Junio C Hamano <>
2014-05-19Merge branch 'lt/request-pull'Junio C Hamano
* lt/request-pull: request-pull: resurrect for-linus -> tags/for-linus DWIM
2014-05-16request-pull: resurrect for-linus -> tags/for-linus DWIMJunio C Hamano
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 <>
2014-03-21Merge branch 'lt/request-pull'Junio C Hamano
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
2014-02-25request-pull: resurrect "pretty refname" featureJunio C Hamano
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 <>
2014-02-25request-pull: pick up tag message as beforeJunio C Hamano
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 <>
2014-02-25request-pull: allow "local:remote" to specify names on both endsLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2014-02-25request-pull: more strictly match local/remote branchesLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <> add variable to use the stuck-long modeNicolas Vigier
If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse option parsing is done in --stuck-long mode. Signed-off-by: Nicolas Vigier <> Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2013-12-05Merge branch 'jk/replace-perl-in-built-scripts'Junio C Hamano
* jk/replace-perl-in-built-scripts: use @@PERL@@ in built scripts
2013-10-29use @@PERL@@ in built scriptsJeff King
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 <> Signed-off-by: Junio C Hamano <>
2013-07-17request-pull: improve error message for invalid revision argsDirk Wallenstein
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 <> Signed-off-by: Junio C Hamano <>
2012-06-01request-pull: really favor a matching tagJunio C Hamano
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 <>
2012-02-01request-pull: explicitly ask tags/$name to be pulledJunio C Hamano
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:// 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 <>
2012-01-11request-pull: use the real fork point when preparing the messageJunio C Hamano
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 <>
2011-12-19request-pull: do not emit "tag" before the tagnameJunio C Hamano
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 <>
2011-12-16request-pull: update the "pull" command generation logicJunio C Hamano
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 <>
2011-11-09request-pull: use the annotated tag contentsJunio C Hamano
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 <>
2011-10-05request-pull: use the branch descriptionJunio C Hamano
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 <>
2011-10-05request-pull: state what commit to expectJunio C Hamano
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 <>
2011-10-05request-pull: modernize styleJunio C Hamano
Make it a bit more conforming to Documentation/Codingstyle Signed-off-by: Junio C Hamano <>
2011-03-02git-request-pull: open-code the only invocation of get_remote_urlUwe Kleine-König
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 <> Signed-off-by: Junio C Hamano <> remove -e switch to shell interpreter which breaks kshBrandon Casey
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 <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-05-08Merge branch 'jn/maint-request-pull' into jn/request-pullJunio C Hamano
2010-05-01request-pull: protect against OPTIONS_KEEPDASHDASH from environmentJonathan Nieder
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 <> Acked-by: Miklos Vajna <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-01-30request-pull: avoid mentioning that the start point is a single commitMiklos Vajna
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 <> Signed-off-by: Junio C Hamano <>
2009-07-29request-pull: optionally show a patch as wellJunio C Hamano
Allow git request-pull to append diff body into the pull request. It's useful for small series of commits. Tested-by: Cyrill Gorcunov <> Signed-off-by: Junio C Hamano <>
2009-07-29request-pull: allow ls-remote to notice remote.$nickname.uploadpackTom Grennan
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 <> Signed-off-by: Junio C Hamano <>
2009-07-01request-pull: really really disable pagerMichal Marek
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 <>
2009-06-30request-pull: really disable pagerJunio C Hamano
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 <>
2008-11-17request-pull: make usage string match manpageStefan Naewe
The usage string of 'git request-pull' differs from he manpage which gives the correct 'synopsis'. Signed-off-by: Stefan Naewe <> Signed-off-by: Junio C Hamano <>
2008-07-13git-request-pull: replace call to deprecated peek-remoteRamsay Jones
Signed-off-by: Ramsay Jones <> Signed-off-by: Junio C Hamano <>
2007-11-18Merge branch 'ph/parseopt-sh'Junio C Hamano
* ph/parseopt-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 to use git-rev-parse --parseopt Migrate to use git-rev-parse --parseopt Migrate to use git-rev-parse --parseopt --keep-dashdash Migrate to use git-rev-parse --parseopt Migrate to use git-rev-parse --parseopt Migrate to use git-rev-parse --parseopt Migrate git-clone to use git-rev-parse --parseopt Migrate 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.
2007-11-08Avoid a few unportable, needlessly nested "...`...".Ralf Wildenhues
Signed-off-by: Ralf Wildenhues <> Signed-off-by: Junio C Hamano <>
2007-11-06scripts: Add placeholders for OPTIONS_SPECJunio C Hamano
--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 <>
2007-07-03Rewrite "git-frotz" to "git frotz"Junio C Hamano
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <>
2007-05-04Improve request-pull to handle non-rebased branchesShawn O. Pearce
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 <> Signed-off-by: Junio C Hamano <>
2006-12-04Pass -M to diff in request-pullDavid Miller
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 <> Signed-off-by: Junio C Hamano <>
2006-05-14Convert some "apply --summary" users to "diff --summary".Sean
Signed-off-by: Sean Estabrooks <> Signed-off-by: Junio C Hamano <>
2005-12-14Trivial usage string
Signed-off-by: Fredrik Kuivinen <> Signed-off-by: Junio C Hamano <>
2005-09-08Big tool rename.Junio C Hamano
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 <>