Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches

Linus Torvalds [off-list ref] 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 [off-list ref]
        Subject: Necessity of "evil" merge and topic branches
        Cc: git@vger.kernel.org
        Date: Wed, 17 May 2006 23:25:55 -0700
        Message-ID: [off-list ref]

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.

On Mon, 29 May 2006, Junio C Hamano wrote:

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.

It was interesting. I cleaned up the series and switched the order of some 
commits in my tree by doing first a "git rebase" and then cherry-picking 
them into another branch, and using "git commit --amend" to fix up some of 
the things I had missed.

Pretty powerful, although at one point I was wondering about having a "git 
rebase" that could switch commits around or drop unwanted ones (ie let the 
user edit the cherry-picking list before the actual rebase).