Re: [Gnu-arch-users] into the ether again: wd factor

[j. rock]

At Tue, 01 Nov 2005 08:20:03 -0800,
Robert Anderson wrote:
> 
> Jeremy Shaw wrote:
> 
> >On Nov 01, 2005 05:35 AM, Robert Anderson <address@hidden>
> >wrote:

> >>I'll throw this one into the ether again:

> >>If there was a way to take a tree and split out changes hunk by hunk 
> >>into two or more trees (including a null tree), wouldn't the power of 
> >>changesets really finally be there in a way that's far more useful?

> >This is the default behaviour in darcs -- when you do 'darcs record',
> >it will iterate through each hunk, rename, etc, and ask if you want
> >to include it in the changeset. You can also do, 'darcs record -a',
> >to record everything.
> >  
> >
> I would like not only to accept/reject, but to factor hunks into an 
> arbitrary number of other trees that I create on the fly during the 
> process.  Disposing of a hunk would be a special case of that.

As a first pass, this could probably be implemented as a third party
tool that splits the changes into a bunch of directories like
,,patch-1 ,,patch-2 ,,patch-3, that can be replayed using 'tla redo -k
,,patch-1' into other branches.

> Having a one-step accept/reject process would be clumsy and redundant if 
> I wanted to split a patch into three parts.  I'd have to reject the 
> hunks that belong in the last patch twice.  I'd rather fan them out in 
> one step.

Yes, I have had to do that type of thing in darcs before, and it was
quite annoying. I think the darcs method is best described as a very
fine grained selective commit.

> Another problem with the accept/reject process that makes it a 
> non-starter IMO is that the tree you are committing never exists as a 
> fully formed tree that you can build/test/etc.  Factoring out into 
> working directories allows you to apply your build/test process to each 
> state of the tree independently before committing.

Excellent point. In this case, using a beefed up commit, still would
not solve the problem. It sounds like you want something more like a
beefed up version of 'tla undo' that let's you interactively sort each
hunk/rename/etc into a different undo changeset. Then you can do 'tla
redo -k ,,changes-1' to redo each change set in the correct location.

In other cases, it may be acceptable (or even neccesary) to commit the
changes without them being tested in isolation. So, similar
functionality would be nice in the commit command. In theory you could
just do a 'tla undo --sorted', and then redo each changeset and
commit. However, this has downside that will cause 'make' to think a
bunch of files have changed, when, in fact, they have not. For large
projects it can take dozens or hundreds of minutes for it to
rebuild. (Unless you can use something like ccache). So, it would be
nice to be able to split a commit into multiple changesets with out
modifying the source tree.

It may also be nice if the interface for viewing and sorting the
patches could be forked off to an external process -- such that
various graphical interfaces could be implemented independently. But,
that may be overkill if a simple enough text based ui can be built.

Jeremy Shaw.