threads / patch / 105

patchfix bug in read-cache.c which loses files when merging a tree

Subject: [PATCH] fix bug in read-cache.c which loses files when merging a tree

## tl;dr

5 messages between Apr 18, 2005 and Apr 18, 2005. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

James Bottomley· Apr 18, 2005, 18:17 UTC · lore

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).

James

read-cache.c: 4d4d94f75cceb8039eb466c1956f8b54dc0e24b6 --- read-cache.c +++ read-cache.c 2005-04-18 13:08:09.000000000 -0500

Show changes to diff +0 −1

@@ -402,7 +402,6 @@
 	if (pos < active_nr && ce_stage(ce) == 0) {
 		while (same_name(active_cache[pos], ce)) {
 			ok_to_add = 1;
-			active_nr--;
 			if (!remove_entry_at(pos))
 				break;
 		}

Linus Torvalds· Apr 18, 2005, 19:25 UTC · re: James Bottomley · lore

Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree

On Mon, 18 Apr 2005, James Bottomley wrote:

Show 6 quoted lines

>
> 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

Linus Torvalds· Apr 18, 2005, 21:19 UTC · lore

Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree

On Mon, 18 Apr 2005, James Bottomley wrote:

Show 5 quoted lines

> 
> 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

Petr Baudis· Apr 18, 2005, 21:58 UTC · re: Linus Torvalds · lore

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 <torvalds@osdl.org> 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

Linus Torvalds· Apr 18, 2005, 22:09 UTC · re: Petr Baudis · lore

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