Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: michael@××××××××.com
Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Date: Fri, 01 Jun 2012 04:05:13
Message-Id: 20120601060526.50cb1155@pomiocik.lan
In Reply to: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver by Michael Orlitzky
On Thu, 31 May 2012 16:27:48 -0400
Michael Orlitzky <michael@××××××××.com> wrote:

> On 05/31/12 16:09, Michał Górny wrote: > > On Thu, 31 May 2012 15:58:43 -0400 > > 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. > > > > 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. > > > > That isn't what rebasing does, unless you do an interactive rebase and > decide to squash the commits.
Yes, it isn't but such kind of work flow was presented in the message I replied to.
> The usual use case for a rebase is just to avoid the ugly merge > commit.
Which devs should simply do whenever they use the scenario you mentioned. I agree we could block 'auto-merges' when pushing to a modified repo but not disallow a valid merges from devs who know what they're doing. -- Best regards, Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies