mailing list mirror (one of many)
 help / Atom feed
From: Linus Torvalds <>
To: David Woodhouse <>
Cc:, James Bottomley <>
Subject: Re: Handling renames.
Date: Thu, 14 Apr 2005 11:11:53 -0700 (PDT)
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 14 Apr 2005, David Woodhouse wrote:
> I've been looking at tracking file revisions. One proposed solution was
> to have a separate revision history for individual files, with a new
> kind of 'filecommit' object which parallels the existing 'commit',
> referencing a blob instead of a tree. Then trees would reference such
> objects instead of referencing blobs directly.

Please don't.  It's fundamentally the git notion of "content determines

It also has no relevance. A "rename" really doesn't exist in the git 
model. The git model really is about tracking data, not about tracking 
what happened to _create_ that data.

The one exception is the commit log. That's where you put the explanations 
of _why_ the data changed. And git itself doesn't care what the format is, 
apart from the git header.

So, you really need to think of git as a filesystem. You can then 
implement an SCM _on_top_of_it_, which means that your second suggestion 
is not only acceptable, it really is the _only_ way to handle this in git:

> So a commit involving a rename would look something like this...
> 	tree 82ba574c85e9a2e4652419c88244e9dd1bfa8baa
> 	parent bb95843a5a0f397270819462812735ee29796fb4
> 	rename foo.c bar.c
> 	author David Woodhouse <> 1113499881 +0100
> 	committer David Woodhouse <> 1113499881 +0100
> 	Rename foo.c to bar.c and s/foo_/bar_/g

Except I want that empty line in there, and I want it in the "free-form"  
section. The "rename" part really isn't part of the git header. It's not 
what git tracks, it was tracked by an SCM system on top of git.

So the git header is an "inode" in the git filesystem, and like an inode 
it has a ctime and an mtime, and pointers to the data. So as far as git is 
concerned, this part:

	tree 82ba574c85e9a2e4652419c88244e9dd1bfa8baa
	parent bb95843a5a0f397270819462812735ee29796fb4
	author David Woodhouse <> 1113499881 +0100
	committer David Woodhouse <> 1113499881 +0100

really is the filesystem "inode". The rest is whatever the filesystem user
puts into it, and git won't care.

> Opinions? Dissent? We'd probably need to escape the filenames in some
> way -- handwave over that for now.

The fact that git handles arbitrary filenames (stuff starting with "." 
excepted) doesn't mean that the SCM above it needs to. Quite frankly, I 
think an SCM that handles newlines in filenames is being silly. But a 
_filesystem_ needs to not care.

There are too many messy SCM's out there that do not hav ea "philosophy". 
Dammit, I'm not interested in creating another one. This thing has a 
mental model, and we keep to that model.

The reason UNIX is beautiful is that it has a mental model of processes 
and files. Git has a mental model of objects and certain very very limited 
relationships. The relationships git cares about are encoded in the C 
files, the "extra crap" (like rename info) is just that - stuff that 
random scripts wrote, and that is just informational and not central to 
the model.


  reply index

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-14 17:54 David Woodhouse
2005-04-14 18:11 ` Linus Torvalds [this message]
2005-04-14 19:09   ` David Woodhouse
2005-04-14 18:12 ` Ingo Molnar
2005-04-14 18:32   ` Linus Torvalds
2005-04-14 18:58     ` Ingo Molnar
2005-04-14 19:20       ` David Woodhouse
2005-04-14 19:21     ` David Mansfield
2005-04-14 18:21 ` H. Peter Anvin
2005-04-14 18:48   ` Linus Torvalds
2005-04-14 18:49     ` H. Peter Anvin
2005-04-14 19:22     ` Zach Welch
2005-04-14 19:40       ` Andrew Timberlake-Newell
2005-04-14 20:42         ` Naming the SCM (was Re: Handling renames.) Steven Cole
2005-04-14 20:53           ` Petr Baudis
2005-04-14 20:58             ` H. Peter Anvin
2005-04-14 21:01               ` Petr Baudis
2005-04-14 23:17           ` Peter Williams
2005-04-14 22:23 ` Handling renames Daniel Barkalow
2005-04-14 22:46   ` David Woodhouse
2005-04-15 13:37 linux
2005-04-15 13:53 ` David Woodhouse
2005-10-21 23:40 git-rev-list: add "--dense" flag Linus Torvalds
2005-10-22  0:37 ` Petr Baudis
2005-10-22  0:47   ` Handling renames Petr Baudis
2005-10-22  1:28     ` Linus Torvalds
2005-10-22  1:51       ` Petr Baudis
2005-10-22  2:10         ` Junio C Hamano
2005-10-22  2:49           ` Petr Baudis
2005-10-22  3:23         ` Linus Torvalds

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox