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

Augie Fackler raf at durin42.com
Thu Jan 10 13:49:13 EST 2019



> On Jan 10, 2019, at 12:24, Boris FELD <boris.feld at octobus.net> wrote:
> 
> 
> 
> On 07/01/2019 22:19, Augie Fackler wrote:
>> 
>> 
>>> On Jan 4, 2019, at 08:09, Pulkit Goyal <7895pulkit at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Jan 4, 2019 at 4:31 AM Augie Fackler <raf at durin42.com> wrote:
>>> 
>>> 
>>> > On Jan 3, 2019, at 10:23 AM, Pulkit Goyal <7895pulkit at gmail.com> wrote:
>>> > 
>>> > 
>>> > 
>>> > On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld at octobus.net> wrote:
>>> > # HG changeset patch
>>> > # User Boris Feld <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.

I guess I was confused by the placement of this functionality in the `strip` command then. I'm not sure where else to put it (given that we already burned the `archive` name for making zipfiles etc.) but maybe strip (-> destroy this change please) is a suboptimal place.

I guess if we mark it as experimental so we can move it later, that seems fine.

(Do I have a more correct understanding now? I think I was talking past the intent here...)

>> 
>> _______________________________________________
>> Mercurial-devel mailing list
>> 
>> Mercurial-devel at mercurial-scm.org
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list