1. 03 Oct, 2017 1 commit
  2. 16 Jan, 2017 1 commit
  3. 16 May, 2014 1 commit
    • Junio C Hamano's avatar
      request-pull: resurrect for-linus -> tags/for-linus DWIM · d952cbb1
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <gitster@pobox.com>
      d952cbb1
  4. 25 Feb, 2014 4 commits
    • Junio C Hamano's avatar
      request-pull: resurrect "pretty refname" feature · 5aae66bd
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <gitster@pobox.com>
      5aae66bd
    • Junio C Hamano's avatar
      request-pull: pick up tag message as before · 4b14ec87
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <gitster@pobox.com>
      4b14ec87
    • Linus Torvalds's avatar
      request-pull: allow "local:remote" to specify names on both ends · dc2eacc5
      Linus Torvalds authored
      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: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      dc2eacc5
    • Linus Torvalds's avatar
      request-pull: more strictly match local/remote branches · 024d34cb
      Linus Torvalds authored
      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: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      024d34cb
  5. 03 Feb, 2014 1 commit
  6. 29 Oct, 2013 1 commit
    • Jeff King's avatar
      use @@perl@@ in built scripts · fcb06a8d
      Jeff King authored
      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: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      fcb06a8d
  7. 17 Jul, 2013 1 commit
  8. 01 Jun, 2012 1 commit
    • Junio C Hamano's avatar
      request-pull: really favor a matching tag · 682853e6
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <gitster@pobox.com>
      682853e6
  9. 01 Feb, 2012 1 commit
    • Junio C Hamano's avatar
      request-pull: explicitly ask tags/$name to be pulled · 2ad9ba03
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <gitster@pobox.com>
      2ad9ba03
  10. 11 Jan, 2012 1 commit
    • Junio C Hamano's avatar
      request-pull: use the real fork point when preparing the message · b7e642ec
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <gitster@pobox.com>
      b7e642ec
  11. 19 Dec, 2011 1 commit
    • Junio C Hamano's avatar
      request-pull: do not emit "tag" before the tagname · f032d66d
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <gitster@pobox.com>
      f032d66d
  12. 16 Dec, 2011 1 commit
  13. 09 Nov, 2011 1 commit
    • Junio C Hamano's avatar
      request-pull: use the annotated tag contents · d0504645
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <gitster@pobox.com>
      d0504645
  14. 05 Oct, 2011 3 commits
  15. 02 Mar, 2011 1 commit
  16. 02 Jun, 2010 1 commit
    • Brandon Casey's avatar
      git-request-pull.sh: remove -e switch to shell interpreter which breaks ksh · 53dfac44
      Brandon Casey authored
      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: 's avatarBrandon Casey <drafnel@gmail.com>
      Signed-off-by: 's avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      53dfac44
  17. 01 May, 2010 1 commit
  18. 30 Jan, 2010 1 commit
  19. 29 Jul, 2009 2 commits
  20. 01 Jul, 2009 1 commit
    • Michal Marek's avatar
      request-pull: really really disable pager · 653a31c1
      Michal Marek authored
      Earlier 476cc724 (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: 's avatarJunio C Hamano <gitster@pobox.com>
      653a31c1
  21. 30 Jun, 2009 1 commit
  22. 17 Nov, 2008 1 commit
  23. 13 Jul, 2008 1 commit
  24. 08 Nov, 2007 1 commit
  25. 06 Nov, 2007 1 commit
  26. 03 Jul, 2007 1 commit
  27. 04 May, 2007 1 commit
    • Shawn O. Pearce's avatar
      Improve request-pull to handle non-rebased branches · ff06c743
      Shawn O. Pearce authored
      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: 's avatarShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
      ff06c743
  28. 04 Dec, 2006 1 commit
    • David Miller's avatar
      Pass -M to diff in request-pull · 396db813
      David Miller authored
      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: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
      396db813
  29. 14 May, 2006 1 commit
  30. 14 Dec, 2005 1 commit
  31. 08 Sep, 2005 1 commit
    • Junio C Hamano's avatar
      Big tool rename. · 215a7ad1
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <junkio@cox.net>
      215a7ad1
  32. 24 Aug, 2005 1 commit
  33. 27 Jul, 2005 2 commits