At Tue, 01 Nov 2005 08:20:03 -0800, Robert Anderson wrote: > > Jeremy Shaw wrote: > > >On Nov 01, 2005 05:35 AM, Robert Anderson <[EMAIL PROTECTED]> > >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. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
