Re: [RFH] straightening out "read-tree -m"

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

Matthias Lederhofer <matled@gmx.net> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> A	B	Outcome
>> ----------------------------------------------------------------
>> D	D	No problem.
>> 
>> D	F	This should result in refusal when there are
>>                 local modification to paths in "foo" directory,
>> 		or there are untracked (but unignored) paths in
>>                 "foo/".
>
> What about ignored configuration files like config.mak?
> Let's say there is an ignored configuration file in a subdirectory.
> If this subdirectory is replaced by a file git would delete the
> ignored configuration file?

You certainly could argue that way.  At that point switching
from branch A to branch B would become impossible after building
in A ("foo/hello.o" is built but that is ignored) without
running "make clean" first, but I do not think it is a big deal.

Anyway, my Request For Help was not about such details about
what to do with untracked working tree files.  It was about a
more fundamental issue, the confused behaviour of unpack-trees
engine (switching branches, and performing tree-level 3-way
merges), which is used by both read-tree and merge-recursive.
It's so central in everyday git operation, that leaving it buggy
in the presense of D/F conflict is an more serious issue, and
compared to that what we may end up doing to untracked working
tree files is secondary.  We'll get to it eventually but we need
to deal with bigger issue first, as its resolution would change
how the code to deal with the untracked files will be
implemented.

In any case, the reason why for full two years this switching
between branches that have "foo/" and "foo" never surfaced as an
issue is that people are saner than doing that in practice (and
I think people coming from CVS couldn't do that before so they
may not even think about doing so).

For example, if you are writing a paper, it may start out as a
small single file, paper.txt (or paper.tex), then as it grows
you might split it and give it its own subdirectory. You would
not create paper.txt directory and have its chapters in separate
files paper.txt/ch01.txt, paper.txt/ch02.txt, etc. when you do
so in practice. Your directory would most likely be named just
"paper", and the chapters are in paper/ch01.txt, paper/ch02.txt.

So in that sense, switching branches with D/F conflict is much
lower priority item in the real world sense than others cooking
right now.  But I hate leaving known bugs in such a core piece
like unpack-trees, and that was why I sent out my RFH.

By the way, setting Mail-Followup-To: to me is rude.  Please
don't.  The person who wants to talk to you about _your_ message
may not be interested in bothering me.