Help designing the evolve UI
Sean Farley
sean.michael.farley at gmail.com
Thu Apr 17 18:53:45 CDT 2014
Angel Ezquerra <angel.ezquerra at gmail.com> writes:
> On Fri, Apr 18, 2014 at 12:05 AM, Jordi Gutiérrez Hermoso
> <jordigh at octave.org> wrote:
>> On Thu, 2014-04-17 at 16:50 +0200, Aurélien Campéas wrote:
>>
>>> Stripping obsolescence markers is useful for the same reason strip
>>> is useful (and to be used wisely & sparingly).
>>>
>>> Now, if there are theoretical or practical objections to that,
>>> I'd like to know them. I'm not, however, interested in anathems.
>>
>> The problem is that stripping obsolescence markers is really the exact
>> same situation as stripping csets: you have to do it locally and then
>> check if you have to do it in any remote repo. Then you're in the same
>> situation we have now with stripping.
>>
>> So why add an obsolescence concept if we already have the same
>> situation with plain stripping?
>>
>> In order for Evolve to work, it *has* to be purely append-only. It
>> cannot delete *any* information -- it can only add information. And
>> this is ok: the phases indicate when this added information is safe
>> and when it is not.
>
> To give a counter argument to this, I sometimes find it annoying to
> use amend with the evolve extension enabled _because_ I know that the
> amend I'm doing is something so trivial that I would not want to
> record the previous state. This happens mostly when I just want to fix
> a typo on the commit message. In those cases I find myself importing
> to MQ and using qrefresh rather than amend, just to avoid the extra
> hidden revisions which make my hidden history more complex.
Wat.
> One could argue that I should not worry about all those obsolete
> revisions, but I do for a couple of reasons:
No, this is it. Don't worry about those obsolete changesets.
More information about the Mercurial-devel
mailing list