commit-id fails after cg-init

Hello!

I tried to start a new project using cogito (current snapshot) and I was immediately greeted by a bug (or a buglet if you want). Let's do this in a clean directory:

$ cg-init defaulting to local storage area $ cg-diff cat: .git/refs/tags/: Is a directory cat: .git/refs/heads/: Is a directory Invalid id: usage: git-cat-file [-t | tagname] <sha1> usage: git-cat-file [-t | tagname] <sha1> Invalid id: usage: diff-cache [-r] [-z] [-p] [--cached] <tree sha1> mkdir: cannot create directory `/tmp/gitdiff.k4FHLY/': File exists $

Not nice.  Trivial debugging shows that it's commit-id that fails:

$ sh -x commit-id 
+ SHA1='[A-Za-z0-9]{40}'
+ SHA1ONLY='^[A-Za-z0-9]{40}$'
+ id=
+ '[' '!' '' ']'
++ cat .git/HEAD
+ id=
+ echo
+ egrep -vq '^[A-Za-z0-9]{40}$'
+ '[' -r .git/refs/tags/ ']'
++ cat .git/refs/tags/
cat: .git/refs/tags/: Is a directory
...

$ ls -al .git/HEAD lrwxrwxrwx 1 proski proski 17 2005-05-03 15:50 .git/HEAD -> refs/heads/master $ cat .git/refs/heads/master $

So, cg-init created an empty .git/refs/heads/master and made .git/HEAD a symlink to it. Now, commit-id reads that file and gets confused.

If anybody has an idea what to put to .git/refs/heads/master please speak up so that cg-init could be fixed.

Dear diary, on Tue, May 03, 2005 at 10:03:05PM CEST, I got a letter where Pavel Roskin <proski@gnu.org> told me that...

Hello,

my plan is to make cg-init:

(i) automatically add to cache any existing content in the current directory,
    if there is any
(ii) call cg-commit right away

This will make us free of this annoying special case and if you are importing an existing tree, you want to do this anyway. The only case when it is not 101% right is when starting a new project from fresh, but some first "dummy" special commit shouldn't hurt there either (that will require to modify write-tree to be willing to write an empty tree).

Patches welcome.

Joel Becker said:

That would actually make sense; commits would go all the way back to the "empty tree" as the ultimate initial tree.

There's an interesting side-effect of this; I _think_ it's fine but it might be worth thinking through. If all new projects start with an empty tree, that creates a "common root" that all projects can appeal to. That means that in theory a merge between any two project root trees can eventually find a common ancestor: the empty tree. I _think_ that's okay... is it?

That also means that empty directories will end up with the "empty tree" as well. Is there a risk of multiple empty directories causing problems later? As far as I can tell, there aren't any problems with that, and does seem logically sound.

--- David A. Wheeler

David A. Wheeler wrote:

In fact, I think that's a Very Good Thing... it eliminates an unnecessary corner case. Same reason linked lists want head nodes and all that jazz.

	-hpa

Wensday, 04 May 2005 19:14 David A. Wheeler wrote:

I think this problem can be easily solved with:
1) Restricting to auto-select empty commit as the merge base
2) Make an exception from rule (1) for first real commit

By (1) we will restrict accidental bad merges that can happen due to crasy operator - he will need to explicitly select empty commit as merge base.

By (2) we will allow to pull and merge projects that is just started envolving.

I said:

Alexey Nezhdanov wrote:

Okay, but that's only true if this is really a problem. I'm not sure it _is_, in fact I think the semantics make perfect sense. I just wanted to note that as the kind of change that MIGHT have a surprising side-effect, so if anyone knew of one, please speak up!

Is that really a problem, though? It seems to me that since a bad merge can be undone, it's not really a problem.

--- David A. Wheeler

On Tue, May 03, 2005 at 04:03:05PM -0400, Pavel Roskin wrote:

	Well, cg-init in this case creates no objects.  I'd say,
instead, it should create an empty tree object (representing a project
with no files) and commit that.  That would be your initial commit, and
would put something valid in heads/master.

Joel