Re: Make 'git fsck' complain about non-commit branches

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 16, 2008, 01:01 UTC
Message-ID: <alpine.LFD.1.00.0801151654050.2806@woody.linux-foundation.org>
In-Reply-To: <7v8x2qd2hu.fsf@gitster.siamese.dyndns.org>

On Tue, 15 Jan 2008, Junio C Hamano wrote:

Show 5 quoted lines

> 
> So far, the plumbing level did not care much about the Porcelain
> convention, such as refs/heads and refs/remotes (you seem to
> have forgot) are about "branches" and must point at commit
> objects.

Yeah. I'm not sure this is all a great idea, but I think they are correct (and no, "refs/remotes/" would *not* have been correct).

The "be more careful about parents" patch (builtin-commit.c) is unquestionably a good idea - those things really *have* to be commits from a plumbing standpoint.

The other ones follow the same rules: "HEAD" really does need to be a commit, since that will otherwise cause breakage (not just for "git commit", but for "git clone" too). The same is true of "git checkout" and "refs/heads/" - if a "refs/heads/" ref isn't a commit, switching branches will get confused!

So now git-fsck verifies things that would confuse git itself. But that's also why refs/remotes/* aren't checked for being commits, and really a remote branch is very *different* from a local branch - because those things would never be used for a commit chain by the native git commands, so git itself shouldn't care.

We've clearly moved a lot of the porcelain layer into git internals, and maybe this went too far, but I suspect not. You can still do whatever the heck you want from a porcelain angle, it just has to follow the (fairly lax) rules that core git itself does expect.

		Linus