Backwards compatibility (was Re: how can you tell you have merged?)

[Adrian Buehlmann]

On 11.09.2008 21:24, Matt Mackall wrote:
> On Thu, 2008-09-11 at 20:38 +0200, Adrian Buehlmann wrote:
>> On 11.09.2008 08:13, Patrick Waugh wrote:
>>> After finally getting up and running on ubuntu, I'm now back to
>>> reviewing the hg manual, and on my second read have a question.
>>>
>>> Let's say you do this:
>>>
>>> hg clone hello my-new-hello
>>> cd my-new-hello
>>> sed -i '/printf/i\\tprintf("once more, hello.\\n");' hello.c
>>> hg commit -m 'A new hello for a new day.'
>>> hg pull ../my-hello
>>> hg merge
>>>
>>> Now, how can you tell that you have done a merge?
>>>
>>> hg heads give us:
>>>
>>> patrick at psychotic:~/repos/my-new-hello$ hg heads
>>> 6[tip]:4   90f041906e70   2008-09-10 23:26 -0500   patrick
>>>   Added extra line of output
>>>
>>> 5   53781dd78cf6   2008-09-11 00:38 -0500   patrick
>>>   A new hello for a new day.
>>>
>>> So, since I'm still seeing two heads, how would I know (if I left,
>>> came back and had forgot I had done a merg) that the merge was
>>> complete but that I still needed a commit?
>>>
>> Maybe, it would be helpful if hg status would print a special
>> notice at the end _if_ the working directory has *two* parent
>> revisions.
> 
> I would really appreciate it if people who are not new here would
> refrain from suggesting changes that break backwards compatibility.

See below.

> We can't change the default output of status, it will kill dozens of
> innocent programs including people's build systems and IDEs. Such
> changes are categorically off-limits and I'm growing quite weary of
> pointing that out (it feels like it's a daily occurrence).

Did you notice that I was just thinking about changing the
default output *if* there is an uncommitted merge?

Doing a merge is not really something that should be done
by a build system or some automated tool without user
interaction, no?

I believe I even read something from you along these lines
somewhere.

> If you're going to suggest any sort of behavior change, you have to
> first consider the impact on:
> 
> - people who've been using hg for the past 3 years
> - all the tools they've built (most of which are not public)
> - all the automated systems they've built

I have actually thought about that, yes.

> These people are our primary customers, /not/ impatient new users.