root-ids changing for some merges

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-07-06 11:55 AM, vila wrote:
>>>>>> Aaron Bentley <aaron at aaronbentley.com> writes:

>     > It's not helpful to repeat this without the *why*.
> 
> Hence that test added at the end of the mail you're replying to so you
> can see for yourself: confusing and useless renames. I'd rather keep the
> root-id and avoid them completely.

Yeah, but the repetition isn't helpful.  I already knew what you wanted.
 "Confusing and useless renames" would have been an excellent "why",
especially in the first email.

>     > And again, what are the unwanted changes, as opposed to the
>     > expected and deliberately introduced changes?
> 
> I think the unwanted change is that the new root-id is propagated in all
> cases (and triggers confusing renames as explained in http://pad.lv/806536)

Propagating the the new root-id is the deliberately-introduced change.
I can't think of a clean way of propagating the new root-id only some of
the time, given a tree with two roots.


> 
>     >> Why the test suite didn't expose this in a
>     >> more obvious way is another debate.
> 
>     > It's not ideal, but not very surprising.
> 
> When one realizes what is going on, it's not surprising anymore but
> that's not the case for the average user.

But the average user isn't running the test suite, so they wouldn't be
surprised anyway.

>     > Root ids are pretty unimportant most of the time, and we tend to
>     > hide them.
> 
> Exactly, that's the main issue: since they are hidden there is no way
> for the user to modify them so we need to make sure we always do the
> right choice.

I don't think it's possible to always do the right thing.  Either choice
will be wrong some of the time.  If we do it the way you propose, the
user will never have the opportunity to select OTHER as their tree root.
 Really, we should conflict so that the user can select how they want to
resolve it.

> AIUI, there are only two cases where we want to propagate the root-it:
> - merging into an empty tree,

Merging into an empty tree is different, because there's no existing root.

>     > For example, we don't bother telling the user when a tree root is
>     > newly-added (i.e.  before the first commit).
> 
> And what if the empty tree had *no* root-id instead like the 'null:'
> revision tree ?

That is already the case.  The empty tree is the null: revision tree.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4UjiQACgkQ0F+nu1YWqI0zywCghuUcnE6voP8u2inUv9pqUwxE
fEQAnjlCGueKV3rMHUuomjzjf9hS1Mxu
=coui
-----END PGP SIGNATURE-----