From: Linus Torvalds Date: Wed, 16 Jan 2008 01:01:57 GMT Subject: Re: Make 'git fsck' complain about non-commit branches Message-ID: In-Reply-To: <7v8x2qd2hu.fsf@gitster.siamese.dyndns.org> On Tue, 15 Jan 2008, Junio C Hamano wrote: > > 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