# commit-id fails after cg-init 7 messages from 2005-05-03 to 2005-05-06. Participants: Pavel Roskin, Petr Baudis, Joel Becker, David A. Wheeler, H. Peter Anvin, Alexey Nezhdanov. Thread: https://gitlist.dev/t/464 ## Pavel Roskin, 2005-05-03 20:03 Subject: commit-id fails after cg-init Message-ID: <1115150585.28520.11.camel@dv> URL: https://gitlist.dev/e/1115150585.28520.11.camel%40dv ``` 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] usage: git-cat-file [-t | tagname] Invalid id: usage: diff-cache [-r] [-z] [-p] [--cached] 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 ``` ## Petr Baudis, 2005-05-03 21:13 Subject: Re: commit-id fails after cg-init Message-ID: <20050503211301.GA15995@pasky.ji.cz> URL: https://gitlist.dev/e/20050503211301.GA15995%40pasky.ji.cz In-Reply-To: <1115150585.28520.11.camel@dv> ``` Dear diary, on Tue, May 03, 2005 at 10:03:05PM CEST, I got a letter where Pavel Roskin 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 ``` ## Joel Becker, 2005-05-03 21:14 Subject: Re: commit-id fails after cg-init Message-ID: <20050503211458.GY4747@ca-server1.us.oracle.com> URL: https://gitlist.dev/e/20050503211458.GY4747%40ca-server1.us.oracle.com In-Reply-To: <1115150585.28520.11.camel@dv> ``` 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 ``` ## David A. Wheeler, 2005-05-04 15:14 Subject: Re: commit-id fails after cg-init Message-ID: <4278E6D4.6060807@dwheeler.com> URL: https://gitlist.dev/e/4278E6D4.6060807%40dwheeler.com In-Reply-To: <20050503211301.GA15995@pasky.ji.cz> ``` 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 ``` ## H. Peter Anvin, 2005-05-04 15:45 Subject: Re: commit-id fails after cg-init Message-ID: <4278EE20.8080004@zytor.com> URL: https://gitlist.dev/e/4278EE20.8080004%40zytor.com In-Reply-To: <4278E6D4.6060807@dwheeler.com> ``` 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 ``` ## Alexey Nezhdanov, 2005-05-05 07:22 Subject: Re: commit-id fails after cg-init Message-ID: <200505051122.03111.snake@penza-gsm.ru> URL: https://gitlist.dev/e/200505051122.03111.snake%40penza-gsm.ru In-Reply-To: <4278E6D4.6060807@dwheeler.com> ``` 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 ``` ## David A. Wheeler, 2005-05-06 03:06 Subject: Re: commit-id fails after cg-init Message-ID: <427ADF1B.5000101@dwheeler.com> URL: https://gitlist.dev/e/427ADF1B.5000101%40dwheeler.com In-Reply-To: <200505051122.03111.snake@penza-gsm.ru> ``` 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 ```