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
