[PATCH 6 of 7] strip: introduce a soft strip option

[Boris FELD]

On 07/01/2019 22:19, Augie Fackler wrote:
>
>
>> On Jan 4, 2019, at 08:09, Pulkit Goyal <7895pulkit at gmail.com
>> <mailto:7895pulkit at gmail.com>> wrote:
>>
>>
>>
>> On Fri, Jan 4, 2019 at 4:31 AM Augie Fackler <raf at durin42.com
>> <mailto:raf at durin42.com>> wrote:
>>
>>
>>
>>     > On Jan 3, 2019, at 10:23 AM, Pulkit Goyal <7895pulkit at gmail.com
>>     <mailto:7895pulkit at gmail.com>> wrote:
>>     >
>>     >
>>     >
>>     > On Thu, Jan 3, 2019 at 4:14 AM Boris Feld
>>     <boris.feld at octobus.net <mailto:boris.feld at octobus.net>> wrote:
>>     > # HG changeset patch
>>     > # User Boris Feld <boris.feld at octobus.net
>>     <mailto:boris.feld at octobus.net>>
>>     > # Date 1539697680 -7200
>>     > #      Tue Oct 16 15:48:00 2018 +0200
>>     > # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
>>     > # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
>>     > # EXP-Topic archived-phase-UX
>>     > # Available At https://bitbucket.org/octobus/mercurial-devel/
>>     > #              hg pull
>>     https://bitbucket.org/octobus/mercurial-devel/ -r a82909c0da7c
>>     > strip: introduce a soft strip option
>>     >
>>     > This is the first user-accessible way to use the archived phase
>>     introduced in
>>     > 4.8. This implements a feature implemented during the Stockholm
>>     sprint. The
>>     > archived phase behave as stripping, changesets are no longer
>>     accessible, but
>>     > pulling/unbundling them will make then reappear. The only
>>     notable difference
>>     > is that unlike hard stripping, soft stripping does not affect
>>     obsmarkers.
>>
>>     I’m not thrilled with this: I had envisioned the archived state
>>     as not full of garbage, but full of things that might merit
>>     revisiting some day. When I strip (or prune it) it’s usually a
>>     dead end, whereas I’d like a way to say “this isn’t interesting
>>     now, but it might be again some day”.
>>
>>     I have no idea if I’m in the minority, and I know this is very
>>     late feedback (because of the holidays I haven’t been at a
>>     computer much) but hopefully it’s useful.
>>
>>
>> Interesting idea.
>>
>> According to my understanding of discussion happened during sprint,
>> we want to use phases to make strip command and stripping less bad. I
>> like that goal and very much want us to move in that direction.
>>
>> Talking about your idea, we might need a phase for things which merit
>> revisiting someday. Do you mean that archived phase should be used
>> for that and we should use some other phase for stripping?
>
> Yes, STRIPPED would be more like INTERNAL (all garbage, fine to
> delete), whereas ARCHIVED would be "please don't delete this, but hide
> it by default". Does that make sense?
>
> (I fully acknowledge I kind of am asking for a pony here.)
The INTERNAL phase is for internal use only to hide the byproducts
commits of hg commands (eg shelve). No user-created commit should end up
in the INTERNAL phase.

Using the ARCHIVED phase now is a nice trick to make history rewriting
commands faster until obsolescence is activated by default. Once
obsolescence is activated by default, the pony you described should be
yours. In the mean-time, I would prefer not to introduce a third phase
that we would have around forever.
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190110/5afc66b1/attachment.html>