[PATCH] merge: warn about adding unstable commit

[Pierre-Yves David]

On 12/31/2015 04:26 PM, timeless wrote:
> Pierre-Yves David wrote:
>> Not really enthusiastic.
>
>> What happen here is that you have an obsolete
>> working copy parent and that will lead to unstable changeset on commit.
>
> Correct
>
>> We -already- have a message for obsolete working copy parent.
>> It live in the evolve extensions.
>
> something parent related:
>          ui.warn(_('working directory parent is obsolete!\n'))
>          if (not ui.quiet) and obsolete.isenabled(repo, commandopt):
>              ui.warn(_('(use "hg evolve" to update to its successor)\n'))
>
> something generic:
>          ui.warn(_('%i new unstable changesets\n') % newunstables)
>
> These are the only messages I could find.

The first one is the one I refer to. When you merge with an obsolete 
changeset, you get and obsolete working copy parent.

>  They aren't very helpful.

Hence (2) improve that unified message if we think we should,

>
>> (used by various command including hg update` and `hg pull`)
>
> Pulls are things which can happen automatically in unrelated actions.
> I certainly don't pay attention to them.
>
>> We should:
>>
>> 1) Use the same message in both case,
>
> I'm +0..-1/2 on this. I'm not sure what the message in evolve says (I
> looked and found the two I mentioned above), but if it says "+2000
> unstable", that's absolutely not a helpful message.
>
> Messages need to be *relevant* to the current action, if they're
> unrelated/irrelevant, they aren't helpful, and might as well be noise
> (and thus would be better served by being omitted).

I do not understant what you are trying to convey here.

>> 2) improve that unified message if we think we should,
>
> I'm leaning toward -1/2 on "unified".
> I'm +1 on trying to improve the evolve ux, although not this year
> (i.e. 2015), and I'd really request someone set up a pushgate.

Unified is very important here. Message related to having an obsolete 
working copy parent have no reason to be different. Do you have argument 
in the other direction?

>> 3) (probably) move this message from evolve into code now that we have a
>> clearer policy about "This is experimental stuff in Core, we can change it
>> until we lift the experimental adjective to t
>
> The terminology bothers me a bunch of ways.

Which are?

> But, I can definitely have obsolete markers from histedit/rebase +
> exchange, so an out of core thing is definitely the wrong place for
> them.

No. When we move obsmarker creation into core we left the message in 
evolve for two reasons:
- backward compatibility on output meant we could not change them even 
(I believe this policy have been relaxed)
- performance, some of the messages involves naif and expensive computation.

>> Let me know if my feedback is clear enough.
>
> Your feedback is clear.
>
> FWIW, an alternative to setting up a pushgate is just to move evolve
> into core's hgext with a big warning saying that it is going to change
> a lot. I'm not sure how we feel about that (if anyone wants to reply
> on this point, please create a new thread).

There is already discussion about plan about this.

-- 
Pierre-Yves David