Gentoo Archives: gentoo-dev

From: Kent Fredric <kentfredric@×××××.com>
To: gentoo-dev@l.g.o
Cc: williamh@g.o
Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Date: Thu, 31 May 2012 22:00:55
In Reply to: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver by Rich Freeman
On 1 June 2012 07:58, Rich Freeman <rich0@g.o> wrote:
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@g.o> 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. > > Rich >
I think you're conflating "rebasing" and "squashing commits". You should rebase a long commit sequence and squash pointless fixup commits, and to make the commit sequence logical and ordered, possibly divided by logical changes that one may wish to later revert. ( That way, backing out a problem is simply reversing that commit and applying the reversal patch ) You should not rebase for the purpose of squashing an entire history of changes into a single scattered commit. Rebasing is more to make the history itself linear and non-complex, as when walking backwards through history, there being 2 parallel histories that generated a merged commit can be confusing for humans, so eliminating the parallel histories is one of the primary purposes I advocate use of rebase for. Squashed commits are a handy feature of rebase, but I wouldn't want to see an entire overlay squashed into the main tree as a single squashed commit. Another bad reason for squashed commits: if you're getting rid of the Changes files, you'll have no history on anything if you just group long histories into a single commit. None. -- Kent perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"