History editing (Was: Will re-basing support be added into Bazaar core?)

[Andrew Cowie]

On Mon, 2009-04-20 at 21:39 +1000, Ian Clatworthy wrote:
> Paul Moore wrote:
> > If I submitted a change to Bazaar, with commits in there such as
> > 
> > - Fixed typo
> > - Fixed another typo
> > - No more time today, committing so I can pick it up tomorrow
> > - Broke the test suite, but getting somewhere, try to fix it up later
> 
> > would that change be accepted (assuming the end result was clean!)? Or
> > would the nature of the intermediate commits be an issue?
> 
> Yes. We review the *overall* patch diff, not the individual steps used
> to get there.

I think this is missing an important point [and, incidentally, why I am
so persistent in my attempts to stop bzr treating the left-hand-most
(mostly merge) revisions as if they were something special]:


While the end result *diff* is what we [ie any arbitrary upstream
maintainer] review when considering a contributor, once accepted the
individual revisions retain their identity *and their revision message*.


Which means (taking Paul's example above) that if the 3rd revision
contains a huge amount of acceptable work, then future runs of:

$ bzr gannotate

are, for a *long* time to come, going to have

"No more time today, committing so I can pick it up tomorrow"

as the revision message associated with that piece of code.

Not very useful.

So much so that I've at last started to question why we bother with
revision messages at all.

        [That's a notion which, frankly, shakes the very foundation of
        my worldview - but which I am starting to consider because I am
        getting extraordinarily tired of being the only person in my
        project who writes decent commit messages - not to mention being
        the guy who has to write all the merge commit messages.
        
        So, no, I'm not going to do that, but one does get a bit tired
        of shouting at the rain. And (on the subject of this thread)
        since revision messages can't ever even be fixed, said poorly
        written commit messages persist forevermore in all their
        horrible hideousness for the rest of time in the history of your
        project. Very rude to have that inflicted on you, but the real
        grievance is that our tools don't allow us to do anything about
        it. Kind of lame, really.
        
        Ok, yes, I could reject the patch, but the combination of a)
        once a patch is good enough for acceptance it's time to merge
        it; you can only push back on someone so much, and if after all
        the trouble of getting a patch up to standard you then turn
        around and reject it because it turns out they ALSO didn't have
        good commit messages, you can kiss that new contributor goodbye;
        and b) as it stands right now, you don't see full text of
        revision messages until after you have committed a merge and
        then run `bzr log` or `bzr viz` on the thing... only to discover
        you just accepted a branch that has enlivening messages like
        "Die bazaar, die". (Yes, that happened to me. That text, in
        fact. Thankfully I hadn't pushed the project's 'mainline' branch
        public yet, so I was able to uncommit and back out. But in the
        general case one doesn't notice until later, and then it's too
        late]

Anyway, as it stands right now, it's not the nicely polished text of the
merge revision that is associated with a line of code. It's the revision
which created|changed it - the very same revisions buried deep that bzr
tries so hard to ignore by only presenting left-hand (mostly merge)
revisions. Yup, the one with "Die bazaar, die" in it.

It would seem our options are to either stop presenting those revisions'
commit messages entirely and introduce some notion of rolling up
changelog messages (in the same way that actual code is rolled up;
Robert told me vaguely about an idea along those lines once), or to
allow the editing [for cosmetic purposes] of history.

Or you rebase :(

++

Two observations:

1. It's interesting that one of the debates you see as people have
switched from centralized version control to Git is people wondering if
they still need to maintain a "ChangeLog" file in the face of
distributed version control tools maintaining (and distributing) full
history. At first I was of the opinion "of course you don't need one of
those anymore" (and the constant conflict resolution on such a ChangeLog
or NEWS file is tremendously boring to deal with) and so don't have such
files in the projects I maintain. But in view of the fact that you *can*
edit a ChangeLog file - and *cannot* do anything about the "Die bazaar,
die" commit messages, I'm starting to wonder.

2. Things like Ohloh are smart enough to present a flat view of history,
so the deeply buried work of the people who actually made the
contributions is a bit closer to the sunlight. Yes, perhaps that's just
an obvious optimization (not to mention, who on earth wants to navigate
a tree widget constantly expanding rows just to see history?) inherited
from the CVS / Subversion legacy, but still. If I were them I wouldn't
bother changing to a tree UI - after all - who cares about the
gatekeeper doing all the merges, or the PQM bot doing all the merges?
You care about the real contributors - and that's what a flat [versus
left hand bias] history presents. In fact, I'd go one further and
actively not display or count revisions that don't change anything - ie,
most merges, especially left-hand ones.¹

AfC
Sydney


¹That having to manually commit each merge is a good idea is a Bazaar
precept that I accept despite the fact it's such a hard sell. But that
doesn't mean we have to _show_ the empty ones to people, right?
-------------- 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/20090421/2a3f436a/attachment.pgp