New evolve docs, take 2: 1/3: index.rst

Angel Ezquerra angel.ezquerra at gmail.com
Sat May 31 10:01:23 UTC 2014


El 31/05/2014 11:26, "Martin Geisler" <martin at geisler.net> escribió:
>
> Greg Ward <greg at gerg.ca> writes:
>
> Hi Greg,
>
> I really like the use cases you've written up! The gradual introduction
> is very nice (fix mistake immediately, fix it later, ...).
>
> > On 30 May 2014, Angel Ezquerra said:
> >> Greg, very nice write up. I have a couple of small comments below.
> > [...]
> >> > Some of the things you can do with ``evolve`` are:
> >> >
> >> >   * Fix a mistake immediately: "Oops! I just committed a changeset
> >> >     with a syntax error―I'll fix that and amend the changeset so no
> >> >     one sees my mistake." (While this is possible using existing
> >> >     features of core Mercurial, ``evolve`` makes it safer.)
> >>
> >> I'd say that evolve makes it safE :-)
> >
> > If there were no such thing as .hg/strip-backup/, then I would agree.
> > But strip isn't *completely* reckless or unsafe. It's just that
> > obsolesence is *safer*.
>
> I'm actually confused why you would call one safer than the other.
> Safety doesn't seem like the diffenting factor to me. Both mechanisms
> leave the data behind: strip places the old data in external bundle
> files and evolve leaves the data in the repository, but marked obsolete.
>
> Compare 'hg commit --amend' with and without evolve enabled: one leaves
> the pre-amend commit in a bundle file, the other marks it as obsolete.

TIL 'hg commit --amend' is actually safe! In retrospect it makes sense if
it uses strip behind the scenes but it never occurred to me to check the
contents of the strip-backup directory after an amend operation.

Thank you Martin!

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20140531/056a0806/attachment-0002.html>


More information about the Evolve-testers mailing list