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

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

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


From: Robert Anderson
Subject: [Gnu-arch-users] into the ether again: wd factor
Date: Tue, 01 Nov 2005 05:35:12 -0800
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)


I'll throw this one into the ether again:

A patch based rcs like arch would be far more useful if people actually made logically distinct, clean patches with it. This is _much_ harder than it should be. There's no tools for it. There really ought to be.

The work pattern of "think of clean, logically distinct feature, code it, commit it" doesn't exist in the wild, at least not in my world. Closer to reality is: start working, realize you really need to factor out a helper function first, return to working, clean up some ugliness in unrelated code that you happened to scroll by, return to working, implement a bunch of debug/diagnostic junk that you'll want out later, return to working, repeat various loosely related tasks until you really shouldn't go any further without committing if you have any remaining self respect.

Now you've got a working directly that represents what really ought to be four or five changesets, but there's no good way to split them out without a hell of a lot of careful work, so you commit the whole ball of wax and flog yourself for not being more disciplined in the first place. But hindsight is always 20/20 and you've got to keep moving forward. You can't keep stopping your workflow to consider if every change you make should be predicated by mucking with your rcs. This kind of factoring into clean, logical changesets has to be an aposteriori process in the real world. I'm fully convinced of that.

Then two weeks later you realize you want all that debug junk out, and wish it was its own patch so you could reverse it and move on with your life. Or you realize there's a bug and want to isolate it among the various orthogonal changes all living in that one patch. Too bad. You've got changesets, but you're not really exploiting their full potential.

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 would be an interactive tool, of course, so it's not an arch command, but more the domain of possibly one of the emacs mode writers or one of the wrapper writers.

I'm just really surprised that this hasn't already been done, redone, and perfected years ago, it seems that fundamental to me.

Bob





reply via email to

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