Rewriting changeset order on push/pull (keeping the history graph tidy)
Greg Ward
greg at gerg.ca
Sun Aug 12 21:51:59 UTC 2012
On 12 August 2012, Stanimir Stamenkov said:
> I wonder how others handle (or don't handle) the case where one
> makes a fork, makes some changes, regularly pulls and merges from
> the upstream repo in between making more changes in the fork repo,
> and finally gets his changes pushed/pulled into the upstream repo.
>
> The problem is the history graph becomes (sometimes much) harder to
> read and less useful after getting the changes back into the
> upstream repo. Here's how a graph looks like while developing in a
> fork repo:
But the benefit is that your version control system accurately
reflects *what really happened*.
[...]
> TortoiseHg shows the above example even worse.
You mean, the history of TortoiseHg is complex, and Mercurial
accurately records that complex history? Some people would call that a
feature, not a bug.
> So does anyone make something to "correct" the given state or
> everyone is just living with it?
The rebase extension will eliminate certain merge changesets. But
rebasing means history no longer records what really happened;
instead, it records what you want history to reflect.
Disclaimer: I use rebase *all the time* and I love it. But I'm fully
aware that I'm rewriting history every time I use it. I'm OK with
that.
Greg
--
Greg Ward http://www.gerg.ca/
A day for firm decisions!!!!! Or is it?
More information about the Mercurial
mailing list