(no subject)

Linus Torvalds wrote:
> What you can do at an SCM level, is that if you want to track renames,
> you track them as a separate commit altogether. Ie if you notice a
> rename, you first commit the rename (and you can _see_ it's a rename,
> since the object didn't change, and the sha1 stayed the same, which in
> git-speak means that it is the same object, ie that _is_ a rename as far
> as git is concerned), and then you create the "this is the data that
> changed" as a _second_ commit.

If a rename and a modification happen at the same time, you'll now have a
point in the history which has the modification but not the rename, which
will probably be completely broken. If a file is deleted and two identical
copies of the file are made at the same time, no inference of renaming can
be made. And sometimes people really do delete one file and make a new
different file with initially identical contents, and this will break that
case.

> But don't make it a new kind of commit. It's just a regular commit,
> dammit. No new abstractions.

You did just introduce a new abstraction, it just happens to be of the 'if
I say X I really mean Y' type, which is far more semantically weighty,
tricky to implement, and on top of that is just plain a gross hack.

> Some "higher level" thing can add its own rules _on_top_ of git rules.
> The same way we have normal applications having their _own_ rules on top
> of the kernel. You do abstraction in layers, but for this to work, the
> base you build on top of had better be damn solid, and not have any ugly
> special cases.

What you're advocating is unclear here, but if you're advocating that the
higher-level system store extra meta-data, not included in git, then that
means the higher-level tools won't be able to interoperate by pointing at
the same git store. And it won't get rid of the problems of storing
information which git doesn't currently, it just makes them be handled by
different code. You can't make these problems go away by getting angry at
them.

I for one am all in favor of blessing Cogito as the 'real' git interface,
with plans to write upgrade scripts which canonically change the current
git format into a new format when upgrades become necessary. There are
already several version control systems with appropriate back end systems
which aren't literally weekend hacks. But you currently seem to be
insisting that such an upgrade will never be necessary, even while
insisting that git will support functionality which it can't.

-Bram

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html