lkml.org 
[lkml]   [2005]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: more git updates..


On Sun, 10 Apr 2005, Junio C Hamano wrote:
>
> But I am wondering what your plans are to handle renames---or
> does git already represent them?

You can represent renames on top of git - git itself really doesn't care.
In many ways you can just see git as a filesystem - it's content-
addressable, and it has a notion of versioning, but I really really
designed it coming at the problem from the viewpoint of a _filesystem_
person (hey, kernels is what I do), and I actually have absolutely _zero_
interest in creating a traditional SCM system.

So to take renaming a file as an example - why do you actually want to
track renames? In traditional SCM's, you do it for two reasons:

- space efficiency. Most SCM's are based on describing changes to a file,
and compress the data by doing revisions on the same file. In order to
continue that process past a rename, such an SCM _has_ to track
renames, or lose the delta-based approach.

The most trivial example of this is "diff", ie a rename ends up
generating a _huge_ diff unless you track the rename explicitly.

GIT doesn't care. There is _zero_ space efficiency in trying to track
renames. In fact, it would add overhead to the system, not lessen it.
That's because GIT fundamentally doesn't do the "delta-within-a-file"
model.

- annotate/blame. This is a valid concern, but the fact is, I never use
it. It may be a deficiency of mine, but I simply don't do the per-line
thing when I debug or try to find who was responsible. I do "blame" on
a much bigger-picture level, and I personally believe (pretty strongly)
that per-line annotations are not actually a good thing - they come not
because people _want_ to do things at that low level, but because
historically, you didn't _have_ the bigger-picture thing.

In other words, pretty much every SCM out there is based on SCCS
"mentally", even if not in any other model. That's why people think
per-line blame is important - you have that mental model.

So consider me deficient, or consider me radical. It boils down to the
same thing. Renames don't matter.

That said, if somebody wants to create a _real_ SCM (rather than my notion
of a pure content tracker) on top of GIT, you probably could fairly easily
do so by imposing a few limitations on a higher level. For example, most
SCM's that track renames require that the user _tell_ them about the
renames: you do a "bk mv" or a "svn rename" or something.

If you want to do the same on top of GIT, then you should think of GIT as
what it is: GIT just tracks contents. It's a filesystem - although a
fairly strange one. How would you track renames on top of that? Easy: add
your own fields to the GIT revision messages: GIT enforces the header, but
you can add anything you want to the "free-form" part that follows it.

Same goes for any other information where you care about what happens
"within" a file. GIT simply doesn't track it. You can build things on top
of GIT if you want to, though. They may not be as efficient as they would
be if they were built _into_ GIT, but on the other hand GIT does a lot of
other things a hell of a lot faster thanks to it's design.

So whether you agree with the things that _I_ consider important probably
depends on how you work. The real downside of GIT may be that _my_ way of
doing things is quite possibly very rare.

But it clearly is the only right way. The fact that everybody else does it
some other way only means that they are wrong.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.660 / U:1.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site