Linus Torvalds <torvalds@xxxxxxxx> writes:
> Ok, this is largely the same series as the previous 1..4 patches, but
> rebased on top of the current master tree because the cache-tree patches
> added some tree_entry_list walkers (which accounts for one extra patch in
> the series, and some trivial merge fixups).
>
> Two new patches then clean up fsck-objects, which really didn't want the
> old tree_entry_list at all (and had added some hacks to the list entry
> just because fsck actually needed to check the raw data).
>
> Another two new patches convert the last remnant of tree_entry_list in
> revision.c and fetch.c respectively to the new world order.
>
> And the final patch then moves the "tree_entry_list" crud into the only
> remaining user, namely builtin-read-tree.c. That file is pretty messy and
> hard to convert, and I don't want to touch it right now, so I left it with
> the nasty compatibility functions. But now that's at least well-contained.
>
> I think the series is all good, and should replace the old one in "next"
> (and cook there for a while just to make sure it's ok).
Sorry for having you have done this -- last night I've merged
the series without rebasing and have the result in "next". I'll
compare to see if you have spotted my mismerges there tonight.
This reminds me of one issue.
From: Junio C Hamano <junkio@xxxxxxx>
Subject: Necessity of "evil" merge and topic branches
Cc: git@xxxxxxxxxxxxxxx
Date: Wed, 17 May 2006 23:25:55 -0700
Message-ID: <7vy7wz6e8c.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
I have such an evil-merge branch merged in "next" to deal with
necessarily adjustments; it is 0a2586c, which is the tip of its
own branch. I was hoping this way I can merge it in to "master"
when I want to pull your yesterday's series.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html