Re: Moved files and merges

2005-09-05 Thread H. Peter Anvin
Junio C Hamano wrote: 1 / \ 0-2-3-5-7 \ / 4-6 It shouldn't matter to the merge at 7 if the 2-3 reorganization was done locally, by applying a patch, or by merging. There was another problem in my message that treated #3 specially. I did it that way primarily because I wanted to

Re: Moved files and merges

2005-09-05 Thread Linus Torvalds
On Mon, 5 Sep 2005, H. Peter Anvin wrote: It would also hade the somewhat interesting possibility that one could remove and recreate a file and have it exist as a different entity. That probably needs to be a user option. It's a totally broken model. Really. You think it solves issues,

Re: Moved files and merges

2005-09-05 Thread H. Peter Anvin
Linus Torvalds wrote: It's a totally broken model. Really. You think it solves issues, but it just creates more bugs and problems than it solves. Trust me. The whole point of git is that content is the only thing that matters, and that there isn't any other meta-data. If you break that

Re: Moved files and merges

2005-09-05 Thread Junio C Hamano
Linus Torvalds [EMAIL PROTECTED] writes: Of course, if you don't push it back, but keep the two trees separate and keep on modifying files that have different names in the other repository, you'll keep on getting into the situation that the trivial merge doesn't work. So we _do_ want to

Re: Moved files and merges

2005-09-05 Thread H. Peter Anvin
Junio C Hamano wrote: But previous argument by Linus made in a distant (in git timescale) past is now ingrained in my brain: the additional metadata recorded at the commit time can only help us what we envisioned in the past when the tool to record that metadata was written. If we try to track

Re: Moved files and merges

2005-09-05 Thread Junio C Hamano
H. Peter Anvin [EMAIL PROTECTED] writes: One question, of course, is if one should simply keep additional metadata around to handle this sort of situations. One could, for example, keep a UUID for each file,... If I am not mistaken, that is exactly what tla does. It seems to work well in

Re: Moved files and merges

2005-09-04 Thread Junio C Hamano
Junio C Hamano [EMAIL PROTECTED] writes: All true. Let's redraw that simplified scenario, and see if what I said still holds. It may be interesting to store my previous message and this one in a file and run diff between them. There are a couple of things worth mentioning about the two

Re: Moved files and merges

2005-09-04 Thread Daniel Barkalow
On Sun, 4 Sep 2005, Junio C Hamano wrote: Sam Ravnborg [EMAIL PROTECTED] writes: If the problem is not fully understood it can be difficult to come up with the proper solution. And with the example above the problem should be really easy to understand. Then we have the tree as used by

Re: Moved files and merges

2005-09-04 Thread Junio C Hamano
Daniel Barkalow [EMAIL PROTECTED] writes: I think this is actually quite a regular merge, and I think we should be able to offer some assistance. The situation with K is normal: case #3ALT. If someone introduces a file and there's no file or directory with that name in other trees, we

Re: Moved files and merges

2005-09-03 Thread Junio C Hamano
This is a simplified scenario of klibc vs klibc-kbuild HPA had trouble with, to help us think of a way to solve this interesting merge problem. #1 - #3 - #5 - #7 // / #0 - #2 - #4 - #6 There are two lines of developments. #0-#2 renames F to G and introduces K.

Re: Moved files and merges

2005-09-03 Thread Sam Ravnborg
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

Re: Moved files and merges

2005-09-03 Thread Junio C Hamano
Fredrik Kuivinen [EMAIL PROTECTED] writes: 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

Re: Moved files and merges

2005-09-03 Thread Fredrik Kuivinen
On Sat, Sep 03, 2005 at 11:46:53AM -0700, Junio C Hamano wrote: [lots of good stuff] I obviously misunderstood the complexity of this merge case. Thank you for the explanation. - Fredrik - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED]

Re: Moved files and merges

2005-09-03 Thread Junio C Hamano
Sam Ravnborg [EMAIL PROTECTED] writes: As explained in another mail what we want to do is actually to transpose the changes made to F to the now renamed file G. So we end up with G containing the modifications made to F. Also we want to include the new file K. Thanks for the clarification.

Re: Moved files and merges

2005-09-03 Thread Sam Ravnborg
On Sat, Sep 03, 2005 at 12:32:03PM -0700, Junio C Hamano wrote: Sam Ravnborg [EMAIL PROTECTED] writes: As explained in another mail what we want to do is actually to transpose the changes made to F to the now renamed file G. So we end up with G containing the modifications made to F.

Re: Moved files and merges

2005-09-03 Thread H. Peter Anvin
Martin Langhoff wrote: Probably should be hacked into cg-merge. When the merge reports a file is missing, what happens? Does it leave a .rej file or anything? The error message is: MERGE ERROR: nfsmount/mount.c: Not handling case 3225ecdf8d172cda2a6ea5276af0d3edc566a0e7 - -

Re: Moved files and merges

2005-09-02 Thread Junio C Hamano
H. Peter Anvin [EMAIL PROTECTED] writes: I currently have two klibc trees, rsync://rsync.kernel.org/pub/scm/libs/klibc/klibc.git and rsync://rsync.kernel.org/pub/scm/libs/klibc/klibc-kbuild.git I cloned them to take a look. You_do_ seem to have a lot of renames. $ git clone