Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree
On Mon, 18 Apr 2005, Petr Baudis wrote: > > So, I'm confused. Why did you introduce unpack-file instead of doing > just this? It was code that I already had (ie the old code from "merge-cache" just moved over), and thanks to that, I don't have to worry about broken "mktemp" crap in user space... Linus - 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
Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree
Dear diary, on Mon, Apr 18, 2005 at 11:19:46PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > I suspect that I should just pass in the SHA1 of the files to the > "merge-one-file-script" from "merge-cache", rather than unpacking it. > After all, the merging script can do the unpacking itself with a simple > "cat-file blob $sha1". So, I'm confused. Why did you introduce unpack-file instead of doing just this? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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
Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree
On Mon, 18 Apr 2005, James Bottomley wrote: > > I had a problem with the SCSI tree in that there's a file removal in one > branch. Your git-merge-one-file-script wouldn't have handled this > correctly: It seems to think that the file must be removed in both > branches, which is wrong. Yes, I agree. My current "merge-one-file-script" doesn't actually look at what the original file was in this situation, and clearly it should. I think I'll leave it for the user to decide what happens when somebody has modified the deleted file, but clearly we should delete it if the other branch has not touched it. I suspect that I should just pass in the SHA1 of the files to the "merge-one-file-script" from "merge-cache", rather than unpacking it. After all, the merging script can do the unpacking itself with a simple "cat-file blob $sha1". And the fact is, many of the trivial merges should be handled by just looking at the content, and doing a "cmp" on the files seems to be a stupid way to do that when we had the sha1 earlier. Done, and pushed out. Does the new merge infrastructure work for you? Linus - 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
Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree
On Mon, 18 Apr 2005, James Bottomley wrote: > > I noticed this when I tried a non-trivial scsi merge and checked the > results against BK. The problem is that remove_entry_at() actually > decrements active_nr, so decrementing it in add_cache_entry() before > calling remove_entry_at() is a double decrement (hence we lose cache > entries at the end). Thanks. Just before I was going to hit the same issue, too. I've pushed out my first real content merge: since Daniel Barkalow's object model stuff didn't apply to my tree any more (I had added the commit type tracking to mine after Daniel did his conversion), I instead applied his series to the place they were done against, and used git to merge the result with my current top-of-tree. I based it on the two example scripts I had sent out, but obviously never tested until this point (since both of them had some serious syntax errors, and thus clearly wouldn't work). I also checked in the stupid scripts, in the expectation that somebody else can improve on them and make them useful. For example, firing up an editor when the merge fails is probably a damn good idea. Anyway, it seems to prove the concept of a real three-way merge, and it all actually worked exactly the way I envisioned. Whether the end result works or not, that's a different issue ;) Linus - 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
