On Tue, 2012-08-21 at 10:22 -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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:
signature.asc
Description: This is a digitally signed message part