Re: VCS comparison table

[Linus Torvalds <torvalds@osdl.org>]

On Tue, 17 Oct 2006, Aaron Bentley wrote:
> 
> But tags have local meaning only, unless someone has access to your
> repository, right?

Ehh. Exactly like the bzr numbers? You have to have access to the original 
repo to name it.

So your point is?

If you do

	git log v2.6.17

in a kernel repository, you'll see exactly what I see - because you'll 
have gotten the tags, aka the "easy revision names".

Now, I'm obviously biased, but the thing is, git really does do this 
right. No meaningless numbers. You give _meaningful_ revision names, and 
they can be extremely powerful.

And no, it's not just tags or the raw SHA1 numbers. You can do 
relationships like

	git log HEAD~5..

which means "show the log for everything since five parents ago" (which is 
_not_ the same as "show the last five revisions", because one of them may 
have been a merge, and brought in a lot more of new commits).

Or, you can say

	git diff mybranch@{2.days.ago}..nextbranch

which says exactly what you'd read it as: show the diff between what 
"mybranch" looked like 2 days ago and what "nextbranch" looks like right 
now.

Or, since the namespace is the same for commit history _and_ for actual 
file contents, and since some commands don't need commits, you can decide 
to name not a revision, but a specific file or subdirectory in a revision, 
and do things like

	git -p grep -1 request_irq v2.6.17~2:drivers/char

where the "revision" is not a commit revision at all, it's a _tree_ 
revision, because we've looked up the revision for "v2.6.17~2" (which 
means "the grandparent of the tag 2.6.17"), and then within that commit we 
looked up the tree "drivers/char", and then we grepped (recursively) for 
the string "request_irq" within that subtree (with one line of context), 
and then we paginated the output through "less" (or whatever your pager is 
set to).

In other words, yes, the above does _exactly_ what you'd expect it to do.

The fact is, nobody ever uses the SHA1 names directly in their normal 
work. You'd use the branch names, tag-names, or some relationship operator 
like "this long ago" or "the parent of" or similar).

The only time you use actual SHA1 names is when you tell somebody _else_ 
something. Or when you use "gitk" to look something up, and select a 
commit, and then paste that commit name into "git show" (which is 
obviously telling "somebody else" - it's communicating between two 
programs).

There's simply no reason to ever use the SHA1 names directly normally. But 
they are there, and they are the _real_ revision numbers, and they 
actually have real meaning between different repositories.

So that "git grep" example above is actually 100% equivalent to

	git -p grep -1 request_irq 3ff4e205e1

but why would I ever write that? That's just insane. But in case you care, 
the way I got that "3ff4e205e1" number, it was just by doing

	git rev-parse v2.6.17~2:drivers/char

and cutting-and-pasting the first ten hex-digits to  make sure I had 
enough of a name to make it unique.

So the SHA1 names always exist, and they are what git _internally_ uses, 
but you'd normally not use them that much in your daily life. 

They are great for explaining things, though. For example, when somebody 
reports a bug, and has used "git bisect" to figure out where the bug 
started happening, that's when the "real name" matters - since we normally 
didn't tag that commit as being buggy when we created it ;)

So that's when you'd say: "I bisected the problem, and it started 
happening in commit 0123456789abcdef". And now everybody with a git 
repository of the kernel can just look it up locally by 
cutting-and-pasting that one number.

> The key thing about a checkout is that it's stored in a different
> location from its repository.  This provides a few benefits:

Actually, git does something even better.

Git allows the repository to be split up.

You can get a git repository on a CD or DVD, and do

	git clone -l -s /mount/cdrom myrepo

and that "-s" means that the new "myrepo" actually is linked to the 
original CDROM repository, and you can now _commit_ stuff and make changes 
in myrepo, even though all the old history is on that CD-ROM. It won't add 
any unnecessary stuff at all to the new repo.

Or, you could do the "totally naked" checkout, so that the whole 
repository is somewhere else (if that "somewhere else" is the CD-ROM, you 
obviously cannot change anything ;)

Or you can have <n> different repositories that are all related, and all 
contain just the part that _they_ care about.

		Linus