[RFC] history editing vs history presentation

Andrew Cowie andrew at operationaldynamics.com
Wed Jun 10 07:50:15 BST 2009


On Tue, 2009-06-09 at 16:12 +1000, Robert Collins wrote:

> most of these
> activities are very isolated due to the social/technical impact of doing
> them: 

I think you have made a significant contribution to the debate here.
There is a vast difference between enumerating all the possibilities and
figuring out which are needed, and when.

> as soon as some code becomes integrated nearly all history
> polishing will stop; as soon as integrated code is released, the
> threshold for which a history tweak is acceptable will go up
> significantly.

It occurred to me reading your essay that the Bazaar community
frequently falls into the trap of violently agreeing with each other -
or, at least we would if we were actually talking about the same thing.
Which we usually aren't because we're usually using the same term to
describe different things [witness the endless Turnbull - Finney
debates :)].

I know personally when I think of "history editing" I actually mean
"fixing formatting issues in commit messages", whereas Robert has quite
reasonably described history in the DVCS sense of "the trend of
revisions which led to a state". 

Nevertheless, it was quite difficult for me to keep reminding myself
that Robert was talking about [much] more than "fixing commit messages"
- you know, editing history :)

Anyway, I will put forward that virtually the only time that anyone
would need to do so is either immediately before or soon after
"integration" ie as I review an inbound branch, or just after I merge it
into 'mainline' (which is how I understood you to mean that).

Just one person's data point, but that part of your analysis seemed to
resonate.

        Aside: Right now the UIs (both console and GTK) make it pretty
        hard to see revision _commit_ messages ("history" :)) until
        after the merge is committed [can we somehow show "pending
        revisions" in bzr-gtk's visualize?], so I have to "fix" commit
        messages after merge, which is of course not really possible at
        the moment.

And while release, per se, would not (and I should hope not be a barrier
preventing me from) deciding to clean up history ^W (damn, did it again)
_commit messages_, I certainly agree that it would be rare in general to
have to so [supposing, of course, we had the capability to have cleaned
up such things in progress as we integrated].

AfC
Sydney

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090610/501aa487/attachment-0001.pgp 


More information about the bazaar mailing list