How to request a fast-forward pull

How to request a fast-forward pull

[Jonathan Nieder]

Hi gitsters,

Paul Gortmaker 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.

Thanks for the food for thought,
Jonathan

Re: How to request a fast-forward pull

[Jeff King]

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

Re: How to request a fast-forward pull

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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

Where did the "Greg,\n\n" come from?  Isn't it just the matter of
adding the "--ff-only" when that string is added?

>> 
>> 	 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.

Yes, absolutely.  The advice of the sender that would be more
helpful is not "how", but "where"/"when".  Is the topic meant for
the maintenance track?  Why is it appropriate to pull this series at
this moment in the history of the overall project?

> 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.

That's a project decision and can be done by whoever is pulling, as
you mentioned earlier.

In any case, why is this even become an issue in the context of
linux-stable?  I thought people over there were working hard to
*increase* verifiability of the history by using signed merges,
while strongly discouraging to rebase history (which is wholly
incompatible with insisting on fast-forwardness).  I _think_ the
original submitter meant to say "the whole of my work is based on
your latest, so you _could_ fast forward", and did not even mean "I
do not want to see any merge commit (or I understand you do not want
to see one), and here is an instruction to work my pull request
around".  If the latter were the case (which I doubt is the case
here, as it is a stupid thing to say in the context of Linux kernel
project), your "mention the branch name instead" would make sense.

Re: How to request a fast-forward pull

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 3926 bytes --]

On Tue, 2012-08-21 at 10:22 -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > 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
> 
> Where did the "Greg,\n\n" come from?  Isn't it just the matter of
> adding the "--ff-only" when that string is added?
> 
> >> 
> >> 	 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.
> 
> Yes, absolutely.  The advice of the sender that would be more
> helpful is not "how", but "where"/"when".  Is the topic meant for
> the maintenance track?  Why is it appropriate to pull this series at
> this moment in the history of the overall project?
> 
> > 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.
> 
> That's a project decision and can be done by whoever is pulling, as
> you mentioned earlier.
> 
> In any case, why is this even become an issue in the context of
> linux-stable?  I thought people over there were working hard to
> *increase* verifiability of the history by using signed merges,
[...]

Each *stable update* series is a single branch made up almost entirely
of cherry-picked commits, possibly managed as a quilt series before
being reviewed and then committed.  Tags are signed, and each commit has
a reference to the original (though the format of that reference isn't
well standardised).

Although Greg owns the linux-stable.git repository, several stable
updates series and the corresponding branches are maintained by others,
such as Paul and myself.  When Greg pulls from them, he's mirroring the
other maintainer's branch and never merging with anyone else's work.  So
it should always be a fast-forward merge.  Further, the head of the
branch is always going to have a tag signed by the respective
maintainer.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]