On Sat, Sep 03, 2005 at 01:25:50AM -0700, Junio C Hamano wrote:
> Junio C Hamano <[EMAIL PROTECTED]> writes:
> > "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> >
> >> I currently have two klibc trees,
> >
> > I cloned them to take a look.  You_do_ seem to have a lot of
> > renames.
> Well, I think I understand how your trees ancestry looks like,
> but still haven't come up with a good problem definition.  I am
> sorry that this message is not a solution for your problem but
> would end up to be just my rambling and thinking aloud.
> The ancestry looks like this:
>        ----#4-#5---#7   #0: 1.0.14 released, next version is 1.0.15
>       /      /              5691e96ebfccd21a1f75d3518dd55a96b311d1aa
>      /---#1-#3---#6     #1: Explain why execvpe/execlpe work the way they do.
>     //     /                1d774a8cbd8e8b90759491591987cb509122bd78
>   #0-----#2             #2: 1.1 released, next version is 1.1.1
>                             3a41b60f6730077db3f04cf2874c96a0e53da453
>                         #3: Merge of #2 into #1
>                             7ab38d71de2964129cf1d5bc4e071d103e807a0d
>                         #4: socketcalls aren't always *.S files; they can...
>                             f52be163e684fc3840e557ecf242270926136b67
>                         #5: Merge of #3 into #4
>                             2e2a79d62a96b6b0d4bc93697fe77cd3030cdfd9
>                         #6: Warnings cleanup
>                             f5260f8737517f19a03ee906cd64dfc9930221cd
>                         #7: Remove obsoleted files from merge
>                             59709a172ee58c9d529a8c4b6f5cf53460629cb3
> and you are trying to merge #6 into #7 (or #7 into #6).  #6 does
> not have usr/kinit and nfsmount at the top; #7 has nfsmount
> under usr/kinit/.
> The merge base of #6 and #7 is #3.  #3->#7 involves many renames
> like nfsmount/sunrpc.h -> usr/kinit/nfsmount/sunrpc.h, while
> #3->#6 involves no renames.  This can be seen by 
>        $ git-diff-tree -M --diff-filter=R -r '#3' '#7' | wc -l
> These renames are introduced by #5 merge, whose immediate
> ancestors are #3 and #4.
> Now, there is a question.  When you merge #6 and #7, development
> between #3 and #7 have a lot of renames, while #3 and #6 do not.
> What should this merge do?  Should it follow the rename, and if
> so why?

Maybe I am missing something... but why should the merge operation
ignore renames? Is there a merge case when ignoring renames is the
Right Thing to do?

Lets say the branches A and B has the common ancestor C which contains
a file named "foo". If A has renamed "foo" to "foobar" and B has made
some content changes to "foo" shouldn't the result be a file named
"foobar" with the content changes B made to "foo" in it?

As I see it when we rename 'foo' to 'foobar' we say that "this file
should from now on be named 'foobar'". Furthermore, when we make some
content changes to some file we say "this file should have this new
content instead of its old content". In particular I do not think the
user expresses an intent to keep the name of a file just because she
makes some changes to its contents. So IMHO the merge of "this file
should from now on be named 'foobar'" and "this file should have this
new content instead of its old content" should be "this file should
from now on be named 'foobar' and have this new content".

I think it is feasible to teach the merge machinery about those rename
cases, it probably isn't trivial to implement but I certainly think it
is possible. It may be the case that the user should be warned when
such automatic merges involving renames are performed though.

- Fredrik
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to