History editing (Was: Will re-basing support be added into Bazaar core?)
andrew at operationaldynamics.com
Tue Apr 21 08:22:03 BST 2009
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
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 :(
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.¹
¹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
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090421/2a3f436a/attachment.pgp
More information about the bazaar