Theodore Tso <tytso@mit.edu> writes:

quoted text
> The argument would be that for SCM that properly tracked user
> intentions, you did the wrong thing.  If the SCM properly understood
> directory renames, there is a big differene between this:
>
> 	scm mvdir db innodb
>
> and this
>
> 	scm mv db/* innodb
>
> You see?  The first moves the *directory* db to innodb.  The second

Then please s/scm mv/scm mvdir/ before reading my example.  The
hypothetical "scm mv" command in my example just knew it was fed an
directory and interpreted it as an intention to move the directory, not
all its contents.

quoted text
> Of course, this distinction does not exist in git, because we track
> content only.  And a number of other SCM's like Hg, which only track
> file renames, wouldn't get this right either.  In order to get this
> right, you need to treat directory renames as separate and distinct
> operations from file renames, because they have different merge
> implications.
> ...
>> See how that argument is flawed?  The point of my example is that the line
>> between your example (1) and (2) in the previous message is blurry.
>
> It's blurry if you don't properly make the distinction between file
> and directory renames, yes.

My point was even if you (in the example, who said "I want to move db
directory to innodb directory") had two different operations, it is not
enough, because you cannot capture that "I want to move db directory to
innodb directory" was contingent on "because I know everything in my db
directory should belong to innodb -- in fact in my history of db/, there
is nothing but innodb support".  The other person you will eventually be
merging with may not share that precondition, as the project started out
to hold anything databasey in db/ and between the two branches being
merged, only you changed the semantics of what each directory means.

quoted text
> However, your argument that it's not possible to determine whether the
> new file should appear as db/gdbm.c or innodb/gdm.c is an argument
> content-tracking alone isn't enough. 

Yes, but it is stronger than that. It is not just "content-tracking alone"
is not enough.  Even systems that have distinction between "scm mv" and
"scm mvdir" are not enough.  That is what I was trying to illustrate.

Your plug-in example differentiates two cases, one of which is that the
renaming branch would move the directory and the other is the branch moved
files under one directory to a new directory while keeping the original
directory, and two cases should produce different results.  If I
understand your argument correctly, it is that in the latter case the
outcome may be ambiguous, but in the former case, it is clear that the
intention of the remaning branch is to rename the directory itself and the
addition to the directory done in the other branch being merged should
automatically be done to the renamed directory while merging.  Most
importantly, the argument makes the assumption that the intention of the
non-renaming branch (iow, why he added the new files in the directory)
does not matter and does not affect the outcome.

The source tree restructuring example I brought in questions that
assumption.  It illustrates that the intention of the side that added the
new file matters.  Is it an innodb support enhancement?  Then it should
follow the renamer's intention to move rename db/ to innodb/.  Is it
adding something unrelated to the new meaning of "innodb" directory given
by the renaming side?  Then it is very likely that it should not go to the
renamed innodb/ directory, even though we may not be able to decide where
it *should* go automatically.  The point to consider is that recording the
renamer's intention to rename the directory and not just its contents is
not enough and does not help the merge.

quoted text
> Personally, I think the scenario I used of renaming plugins is more
> likely that the sort of source reorganization which you've posited,
> but I agree they are both possible scenarios.  The question for git
> development is whether these sorts of issues ar ones that we should
> try to handle or not?

That entirely depends on your definition of "handle", I think.

I personally think that it is better for the tool to make its best effort
but stop and let the human inspect the result if the validitly of the
result is not so cut-and-dried, than blindly saying "the user said move
the directory, so I'll move the directory and move any and all new files
to it" and produce a potentially wrong result.  My comment in the previous
message about <db/gdbm.c> was not that it is 100% correct to leave it
there, nor it is 100% correct to move it elsewhere.  The point was it is a
case you cannot say what is correct even with help from "scm mvdir", and
the tool should stop and ask for confirmation.

Boasting that "unlike git that does not record renames, we correctly
resolve this case automatically, because our superiour design records the
user's intention to rename directory" is simply embarrassing yourself.
You may be silently producing a wrong result, which is nothing to boast
about.

I think it is Ok to assume that most of the time it is correct to move the
new file if the other branch "renamed" the directory in the situation the
example depicts, and I do not mind if the "best effort" the tool makes is
to move it to make it easy for the user to say "Yup, that is the right
outcome" and conclude the merge, but I think a tool is broken if it does
not give the user an opportunity to examine the situation and say "Oh, no,
that is not correct in *this* case" and fix it up.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html