Re: Couple of read-tree questions

[Junio C Hamano <junkio@cox.net>]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Is there any current use for read-tree with multiple trees without -m or 
> equivalent?

I did not know it even allowed multiple trees without -m, but
you are right.  It does not seem to complain.

I have never thought about using multiple trees without -m, and
I do not remember hearing any plan nor purpose of using it to do
something interesting from Linus.  I think its allowing multiple
trees without -m is simply a bug.

> Why does --emu23 use I+H for stage 2, rather than just I? Wouldn't this 
> just reintroduce removed files?

They are not "removed files", at least in the original context.

The original intention was that git was supposed to work without
having _any_ files in the working tree.  The reason why
multi-tree read-tree has so many special cases that says "must
match *if* work file exists", is that not having a corresponding
working file was supposed to be equivalent to having the file
checked out *and* unmodified.

That assumption and design goal was partially broken at around
the beginning of June when we started touching working tree
during a merge.  Until that timeframe, we did not touch (nor
even look at) files in the working tree during the merge, mainly
due to the desire of performing the merge operation entirely in
the cache (which was the name of "index file" back then).

I do not think anybody currently uses --emu23.  I did it because
it has a potential of making the two-tree fast forward (which is
used in "git checkout" to switch between branches) easier to
manage when the working tree is dirty than doing straight
two-tree merge, but that is just a theoretical potential never
tested in the field.  Frankly, I do not mind, and I do not think
anybody else minds, too much if you need to break or remove
emu23 if that would make your code clean-up and redoing
read-tree easier.