On Fri, 15 Apr 2005, David Woodhouse wrote:
>
> I suspect that finding the common commit is actually a per-file thing;
> it's not just something you do for the _commit_ graph, then use for
> merging each file in the two branches you're trying to merge.
I disagree.
Conceptually, you should never do _anything_ on a file level. Why? Because
individual files don't matter. You shouldn't merge two files cleanly just
because they look fine - they _depend_ on the other files in the archive,
and that's quite fundamentally why per-file tracking is really wrong from
a project standpoint.
So if you can't merge two files cleanly because the "project" history
ended up being further back than the "file" history, then that's a _good_
thing. You don't know what the hell happened to the other files that this
file depended on. Merging one file independently of the others is WRONG.
Also, I suspect that you'll find that if you do cross-merges, you'll
basically always end up in:
> (I think it's a coincidence that in my example the useful files 'A2' and
> 'B2' actually do end up in a single tree together at some point.)
nope, I don't think that's coincidence. I think that's the normal case.
Your file-based history is the one that can _incorrectly_ and
coincidentally happen to have a single file at some point, but since that
file doesn't stand alone, that's really not a fundamentally good reason to
merge it.
Really, this "individual files matter" approach is a _disease_. They
don't. Individual files DO NOT EXIST. Files always exist as part of the
project, and the _only_ time you track a single file is when the project
is a single file (and then that will be very very obvious in a git
archive, thank you very much).
So the single-file mentality is a disease brought on by decades of _crap_.
And by the fact that it ends up limiting the problem scope, so you can do
certain things easier.
For example, just doing intra-file diffs is a lot _easier_ and less
time-consuming than doing inter-file diffs. Bit it is _absolutely_ not
better. In fact, it is clearly inferior to anybody who spends even five
seconds thinking about it - yet we still do it, because of the historical
(and INCORRECT) mindset that "files matter".
Files DO NOT matter. Never have. It's an implementation limitation to
think they do. You'll screw yourself up, and when somebody comes up with a
half-way efficient way to generate inter-fiel diffs, your architecture is
totally and utterly unable to handle it.
I don't care what you do at an SCM level, and if the crud you put on top
of git wants to perpetuate mistakes of yesteryear, that's _your_ issue.
But dammit, git is designed to do the right thing, and I will fight tooth
and nail against anybody who thinks individual files matter.
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
