To rerwite history or not - that's the question

[Mathieu Courtois]

Hi,

Have a look at Obsolescence concept and the Evolve extension too.

http://mercurial.selenic.com/wiki/ChangesetEvolution

MC


2013/2/21 Isaac Jurado <diptongo at gmail.com>

> On Thu, Feb 21, 2013 at 3:09 PM, Roger Kratz <Roger.Kratz at teleopti.com>
> wrote:
> > Hi
> >
> > In git repos, I get the impression that (one of the) normal workflows
> > involves a lot of history rewrites. In Mercurial this seems to be more
> > uncommon. Why is that? Because of the tool or the people?
>
> It's the combination of different facts:
>
>   - Git has a larger userbase, so you can expect more creative ways of
>     using it.
>
>   - Git has all its functionality available.  Whereas in Mercurial,
>     features targeted to advanced users are disabled by default (by
>     having them as extensions).
>
>   - History rewriting has also been available very early in Git's
>     development.  Mercurial, which has also a smaller developer base,
>     didn't have history rewriting among its priorities.  This is now
>     changing.
>
>   - From my point of view, the fact that Git does object repacking and
>     garbage collection does indeed give a false impression of
>     transience.
>
>   - In Git there are quite a few ways to rewrite history, as part of its
>     massive combinations of commands and options, which could also
>     induce you to think that history rewriting is allright.
>
> However, many advertised workflows for Git actually encourage the
> opposite: extensive branching.  Some times even forking linear history
> on purpose [1].  Also, the fact that Git has octopus merges, even though
> almost nobody uses them, could also be interpreted as an aid to
> multi-branching.
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/
>
> As already mentioned, Mercurial has historically been a bit more
> restrictive about history rewriting.  But now I belive this is starting
> to change, specially since the development of the evolution extension
> [2] which enables history rewriting in a safe and distributed manner.
> As far as I know, this is something Git does not support (probably the
> second only feature Mercurial has and Git lacks, after named branches).
>
> [2] http://mercurial.selenic.com/wiki/ChangesetEvolution
>
>
> > When supporting multiple versions/releases, in Hg the recommended (*)
> > way is to fix bugs by merge older releases to newer ones instead of
> > grafting. In git repos it seems more common to back port (cherry-pick)
> > fixes.
>
> Depends on the workflow.  The one you mention looks the same as the Linux
> kernel uses: backporting to divergent branches.  Each time a new kernel
> is released, the mainline repository is cloned.  This new clone becomes
> the maintenance repository for that release (e.g. 3.8.x) which will only
> receive commits cherry picked from mainline.
>
> You could achieve the same workflow with mercurial.  But for the
> cherry-picking operation you could use either export/import combination
> or the transplant extension [3].  I think the graft only works in the
> same repository.
>
> [3] http://mercurial.selenic.com/wiki/TransplantExtension
>
> Again, history rewriting abuse is something relatively new to Mercurial
> so the recommended workflow is also the most tested one.
>
> > After a pull, in Hg the recommended (*) way is to merge multiple
> > heads. In git repos it seems to be standard to rebase.
>
> Not by default.  A pull operation in Git is the Mercurial equivalent to
> pull + merge + commit.  Git does not really encourage the use of rebase,
> it's just that there seems to be less warnings about its usage.
>
> > If a task takes 10 commits in Hg – let’s leave it that way. In git
> > repos it seems to be standard to squash them when ready.
>
> Lack of functionality.  Mercurial now distributes the histedit
> extension and has mechanisms that enable safe history rewriting (phases,
> obsolescence, changelog filtering).  So you can expect a change in this
> trend.
>
> > How do you more experienced guys look at history rewriting? In what
> > context do you use it? And do you know why git:ers use it more
> > frequently (if true – that’s my personal opinion).
>
> I'm not very experienced, but I have to admit that since phases were
> introduced, my rebase and histedit usage has increased significantly and
> my worries have lowered.  Mercurial will not, by default, allow me to
> rewrite history that has been transferred to or from other repositories.
> I don't know how Git handles that.
>
> I hope it helped.  Cheers.
>
> --
> Isaac Jurado
>
> "The noblest pleasure is the joy of understanding"
> Leonardo da Vinci
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20130221/87e0d14b/attachment-0002.html>