History editing

[Ben Finney]

Paul Moore <p.f.moore at gmail.com> writes:

> It seems to me that the "history is immutable" philosophy is fine up
> to a point, but only for published history. For private work, I want
> to make things tidy before I publish it, and I think that's a
> reasonable thing to do.

Perhaps I'm spoiled by Bazaar's excellent merging capabilities, but I
can't see why it's so important to “clean up” history. The person
merging the work into another branch will be making their own commit,
with its own message; that's the place to summarise what the meaning of
the change is.

> So here's a question:
> 
> 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?

I can't speak for the Bazaar developers, but for my purposes, such
intermediate commits make no difference to me when merging from your
branch. I simply pick the revision that represents the working tree
state I want, Bazaar copies in the revision data so everything lines up,
and I make a commit message of my own that summarises the meaning of
this merge.

When looking at the history later with ‘log’, I can choose to ignore
foreign revisions and read only the commits made at the level of my
branch (by visually skipping past indented revisions, in current
versions of Bazaar; by specifying an option to ‘log’, in some future
version).

No history editing needs to be done for this use case, as far as I'm
concerned.

-- 
 \     “Are you pondering what I'm pondering?” “I think so, Brain, but |
  `\        why would anyone want a depressed tongue?” —_Pinky and The |
_o__)                                                           Brain_ |
Ben Finney