1. 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: default avatarJunio C Hamano <gitster@pobox.com>
      682853e6
  2. 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: default avatarJunio C Hamano <gitster@pobox.com>
      2ad9ba03
  3. 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: default avatarJunio C Hamano <gitster@pobox.com>
      b7e642ec
  4. 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: default avatarJunio C Hamano <gitster@pobox.com>
      f032d66d
  5. 16 Dec, 2011 1 commit
  6. 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: default avatarJunio C Hamano <gitster@pobox.com>
      d0504645
  7. 05 Oct, 2011 3 commits
  8. 02 Mar, 2011 1 commit
  9. 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: default avatarBrandon Casey <drafnel@gmail.com>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      53dfac44
  10. 01 May, 2010 1 commit
  11. 30 Jan, 2010 1 commit
  12. 29 Jul, 2009 2 commits
  13. 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: default avatarJunio C Hamano <gitster@pobox.com>
      653a31c1
  14. 30 Jun, 2009 1 commit
  15. 17 Nov, 2008 1 commit
  16. 13 Jul, 2008 1 commit
  17. 08 Nov, 2007 1 commit
  18. 06 Nov, 2007 1 commit
  19. 03 Jul, 2007 1 commit
  20. 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: default avatarShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      ff06c743
  21. 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: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      396db813
  22. 14 May, 2006 1 commit
  23. 14 Dec, 2005 1 commit
  24. 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: default avatarJunio C Hamano <junkio@cox.net>
      215a7ad1
  25. 24 Aug, 2005 1 commit
  26. 27 Jul, 2005 2 commits