Re: How to request a fast-forward pull

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 20, 2012 at 01:40:33PM -0700, Jonathan Nieder wrote:

> > When you have a moment, would you please migrate this
> > across to your main linux-stable repository?
> >
> > Both a branch and signed tag are present and pointing at
> > the same commit, but "git request-pull" does favour output
> > of the tag over the branch name.
> >
> > But merging the tag will want to create a merge commit.
> >
> > So, to avoid a merge commit in your repo, you can fetch
> > (fast fwd) into your (local) branch from my branch at:
> >
> >  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y
> >
> > and then fetch the signed tag listed below after that.
> 
> Can this be made easier?  I could imagine request-pull learning
> --ff-only that generates a message like
> 
> 	Greg,
> 
> 	Please pull --ff-only
> 
> 	 git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y
> 
> 	to get the following changes [...]
> 
> which could work ok if the recipient notices the --ff-only, but I
> wonder if there is a simpler way.

If it is something important for the sender to communicate to the
recipient as part of the pull command-line, then I would think the
natural place is on the line with the rest of it, like:

  Please pull:

    --ff-only <remote> <ref>

It's maximally noticeable to the recipient, then, and anybody
cutting-and-pasting the whole line would get it automagically. That is
as close to machine-readable as pull-request emails get.

However, I have to wonder if that is a good idea in general. Isn't the
decision to --ff-only or not really the puller's business? In the
general case, I would not expect senders of pull request to have advice
in this area.

This particular case seems to be caused by a policy mismatch between the
project and request-pull. The latter's behavior to favor a matching tag
is because tags carry more information. But in this case, it sounds like
the project would rather avoid the extra merge commits, even if it means
losing information. So the right solution would be to teach request-pull
an option to follow the project's policy better.

Or is this just a one-off thing? In that case, the simplest thing would
be to tweak the pull-request email to mention the branch name instead of
the tag, rather than talking about --ff-only.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]