Re: more git updates..

Rutger Nijlunsing
2005-04-10T17:00:35Z

On Sun, Apr 10, 2005 at 08:44:56AM -0700, Linus Torvalds wrote:
>
>
> 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,
[snip]
> - annotate/blame. This is a valid concern, but the fact is, I never use
[snip]

- merging.
When the parent tree renames a file, it's easier for an out-of-tree
patch to get up-to-date.

- reviewing.
A huge patch with 2000 added lines and 1990 removed lines is more
difficult to review then a rename + 10 lines patch.

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

When you've got no out-of-tree patches since you've got the
parent-of-all-trees, then they don't matter, that's true :)

> 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.

--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------