How to request a fast-forward pull
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi gitsters,
Quoted 7 lines · Paul Gortmaker
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.
Quoted 8 lines
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.gitlinux-2.6.34.yand 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
Quoted 27 lines · Jonathan Nieder
Quoted 7 lines
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.
Quoted 8 lines
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.gitlinux-2.6.34.yand 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 [...]
Quoted 2 lines
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
Quoted 16 lines · Jeff King
Quoted 14 lines · Jonathan Nieder
Quoted 14 lines
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.gitlinux-2.6.34.y
Quoted 8 lines
Quoted 8 lines
Quoted 1 line
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?
Quoted 16 lines
Quoted 7 lines
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>
Quoted 8 lines
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?
Quoted 5 lines
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.
Quoted 66 lines · Junio C Hamano
Quoted 16 lines · Jeff King
Quoted 14 lines · Jonathan Nieder
Quoted 14 lines
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.gitlinux-2.6.34.yQuoted 8 lines
Quoted 8 lines
Quoted 1 line
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-onlyWhere did the "Greg,\n\n" come from? Isn't it just the matter of adding the "--ff-only" when that string is added?
Quoted 16 lines
Quoted 7 lines
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>Quoted 8 lines
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?
Quoted 5 lines
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.
Quoted 6 lines
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.
Signature · 2 lines
Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones.