On Fri, Aug 04, 2017 at 10:44:31AM -0700, Junio C Hamano wrote: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > > > On Wed, Aug 2, 2017 at 5:28 PM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > >> > >> I would say that if you rebase someone's commit(s), then you are on the > >> "patch's delivery path" and so should add a Signed-off-by tag. > > > > Yeah, I agree. Rebasing really is pretty much the exact same thing as > > applying a patch. > > > >> "git rebase" does have a "--signoff" option. > > > > I think you end up signing off twice using that. I don't think it's > > smart enough to say "oh, you already did it once". > > Git avoids duplication only when your SoB appears as the last > existing one, so that we can capture a flow of a patch which you > originally signed off, picked up and tweaked further by somebody > else, which comes back to you and you sign it off again. > > We may drop yours even when yours is not the last in the existing > chain, but that would be a bug; at least the above is what we try to > do. > > > And in general, you simply should never rebase commits that have > > already been publicized. And the fact that you didn't commit them in > > the first place definitely means that they've been public somewhere. > > > > So I would definitely suggest against the "git rebase --signoff" > > model, even if git were to do the "right thing". It's simply > > fundamentally the wrong thing to do. > > When those involved are using push/pull as a replacement for > e-mailed patch exchange, then such a workflow should be OK. There > needs to be a shared understanding that the branch(es) used for such > exchange are unstable and should not be built directly on to be > merged, of course. > Thanks Junio, I don't think I correctly parsed "should not be built directly on to be merged", can you rephrase? -- Darren Hart VMware Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
