gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: fixing and extending "selected commit"


From: Robert Anderson
Subject: Re: [Gnu-arch-users] Re: fixing and extending "selected commit"
Date: 02 Oct 2003 09:49:16 -0700

On Wed, 2003-10-01 at 23:39, Miles Bader wrote:
> Jan Hudec <address@hidden> writes:
> > > > I wonder if rather than "restricting attention" you might consider
> > > > actually generating a second tree from the first, with the changes that
> > > > are not to be committed split out into the second tree that is a
> > > > complement of the first.
> > > 
> > > That sounds _way_ more inefficient for large trees (whereas `restricting
> > > attition' could _help_ large trees).  Please think of the large trees.
> > 
> > No, it can't! You have to make full inventory anyway, because renames
> > could cause bad things otherwise.
> 
> It sounded like Robert was suggesting making a _real copy_ of the
> _whole_ tree, way more inefficient than a full inventory (which are
> actually pretty cheap these days).

I'm not sure what a "real copy" is, but I think what I'm suggesting has
some merit that is not being appreciated.

Remember back in the day when the idea was that you had whole-tree
commits, period, and that was a good thing?  It was good because you
ought to at least have the option of running "make check" on the tree
before it gets committed (for example).  This whole "limits" idea takes
away the chance to have a look at and test the tree _in the committed
state_.  I think that's a bad thing.  Or at least, it's not typically
what I want.

What I'm suggesting is splitting "partial commit" into making a "partial
tree" and then using a full-tree commit.  This way, you always get a
unified look at the committed tree state, and you're free to run
what-changed to review the "partial" commit, or run "make check" or
apply whatever criteria you like to committed tree states.

Bob






reply via email to

[Prev in Thread] Current Thread [Next in Thread]