On Thu, 31 May 2012 15:58:43 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgo...@gentoo.org> > wrote: > > What would git signing work with rebased commits? Would all of them > > have to be signed once again? > > > > The whole point of rebasing is to throw away history (which is either > good or bad based on your perspective). > > So, if 14 devs spend 3 years and 2000 commits working on something in > a branch, and I commit it to master using a rebase, then all you'll > see in the master history is that rich0 committed 20k lines of code to > master on May 31st, and that would be signed by me. > > I think that rebasing before merging is a pretty typical workflow > anyway - when you submit a patch to Linus, he doesn't really care that > you spent six months tweaking it - he just is getting a big blob of > code that either works or doesn't. Does all that sub-history really > matter? You could always push the branch to the repository if you > wanted to keep it on the side. That sounds like a pretty poor workflow to me. If I tweak something for 3 years, I'm likely to have a larger set of logically organized commits. I'm not saying it's unlikely I'm going to rebase fixes for obvious mistakes but putting everything onto one blob just makes the changes harder to read and less maintainable. For example, if I first create a basic function and then add additional options to it, I'm likely to keep those as separate commits. If one of the changes was a really bad idea, I'd like to revert the appropriate commit rather than removing all traces of it by hand and mistakenly introducing even worse breakage. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
