Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Michał Górny <mgorny@g.o>
Subject: Re: Re: Portage Git migration - clean cut or git-cvsserver
Date: Fri, 1 Jun 2012 06:05:26 +0200
On Thu, 31 May 2012 16:27:48 -0400
Michael Orlitzky <michael@...> 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
Attachment:
signature.asc (PGP signature)
Replies:
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
References:
Re: Portage Git migration - clean cut or git-cvsserver
-- Alexey Shvetsov
Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
Re: Portage Git migration - clean cut or git-cvsserver
-- Duncan
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Dirkjan Ochtman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
Re: Portage Git migration - clean cut or git-cvsserver
-- Duncan
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Dirkjan Ochtman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- William Hubbs
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Michał Górny
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Michał Górny
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Michael Orlitzky
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Next by thread:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Previous by date:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Next by date:
Re: Re: Portage Git migration - clean cut or git-cvsserver


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.