commit-id fails after cg-init

commit-id fails after cg-init

[Pavel Roskin]

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.

-- 
Regards,
Pavel Roskin

Re: commit-id fails after cg-init

[Petr Baudis]

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!

Hello,

> 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.

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: commit-id fails after cg-init

[David A. Wheeler]

Joel Becker said:

> 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.

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

Re: commit-id fails after cg-init

[H. Peter Anvin]

David A. Wheeler wrote:
> Joel Becker said:
> 
>> 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.
> 
> 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?
> 

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

Re: commit-id fails after cg-init

[Alexey Nezhdanov]

Wensday, 04 May 2005 19:14 David A. Wheeler wrote:
> Joel Becker said:
> > 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.
>
> 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.
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.

-- 
Respectfully
Alexey Nezhdanov

Re: commit-id fails after cg-init

[David A. Wheeler]

I said:
>>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?

Alexey Nezhdanov 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

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!

> 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.

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

Re: commit-id fails after cg-init

[Joel Becker]

On Tue, May 03, 2005 at 04:03:05PM -0400, Pavel Roskin wrote:
> 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.

	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

-- 

"The cynics are right nine times out of ten."  
        - H. L. Mencken

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127