On Tue, 19 Apr 2005, Linus Torvalds wrote:
>
> The real expense right now of a merge is that we always forget all the
> stat information when we do a merge (since it does a read-tree). I have a
> cunning way to fix that, though, which is to make "read-tree -m" read in
> the old index state like it used to, and then at the end just throw it
> away except for the stat information.
Ok, done. That was really the plan all along, it just got dropped in the
excitement of trying to get the dang thing to _work_ in the first place ;)
The current version only does
read-tree -m <orig> <branch1> <branch2>
which now reads the old stat cache information, and then applies that to
the end result of any trivial merges in case the merge result matches the
old file stats. It really boils down to this littel gem;
/*
* See if we can re-use the old CE directly?
* That way we get the uptodate stat info.
*/
if (path_matches(result, old) && same(result, old))
*result = *old;
and it seems to work fine.
HOWEVER, I'll also make it do the same for a "single-tree merge":
read-tree -m <newtree>
so that you can basically say "read a new tree, and merge the stat
information from the current cache". That means that if you do a
"read-tree -m <newtree>" followed by a "checkout-cache -f -a", the
checkout-cache only checks out the stuff that really changed.
You'll still need to do an "update-cache --refresh" for the actual new
stuff. We could make "checkout-cache" update the cache too, but I really
do prefer a "checkout-cache only reads the index, never changes it"
world-view. It's nice to be able to have a read-only git tree.
Final note: just doing a plain "read-tree <newtree>" will still throw all
the stat info away, and you'll have to refresh it all...
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
