{"thread":{"id":"464","subject":"commit-id fails after cg-init","startedAt":"2005-05-03T20:03:05Z","lastAt":"2005-05-06T03:06:03Z","messageCount":7,"participants":["Pavel Roskin","Petr Baudis","Joel Becker","David A. Wheeler","H. Peter Anvin","Alexey Nezhdanov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2516","messageId":"1115150585.28520.11.camel@dv","threadId":"464","inReplyTo":null,"subject":"commit-id fails after cg-init","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-05-03T20:03:05Z","receivedAt":"2005-05-03T20:03:05Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nI tried to start a new project using cogito (current snapshot) and I was\nimmediately greeted by a bug (or a buglet if you want).  Let's do this\nin a clean directory:\n\n$ cg-init \ndefaulting to local storage area\n$ cg-diff \ncat: .git/refs/tags/: Is a directory\ncat: .git/refs/heads/: Is a directory\nInvalid id: \nusage: git-cat-file [-t | tagname] <sha1>\nusage: git-cat-file [-t | tagname] <sha1>\nInvalid id: \nusage: diff-cache [-r] [-z] [-p] [--cached] <tree sha1>\nmkdir: cannot create directory `/tmp/gitdiff.k4FHLY/': File exists\n$\n\nNot nice.  Trivial debugging shows that it's commit-id that fails:\n\n$ sh -x commit-id \n+ SHA1='[A-Za-z0-9]{40}'\n+ SHA1ONLY='^[A-Za-z0-9]{40}$'\n+ id=\n+ '[' '!' '' ']'\n++ cat .git/HEAD\n+ id=\n+ echo\n+ egrep -vq '^[A-Za-z0-9]{40}$'\n+ '[' -r .git/refs/tags/ ']'\n++ cat .git/refs/tags/\ncat: .git/refs/tags/: Is a directory\n...\n\n$ ls -al .git/HEAD \nlrwxrwxrwx  1 proski proski 17 2005-05-03 15:50 .git/HEAD -> refs/heads/master\n$ cat .git/refs/heads/master\n$\n\nSo, cg-init created an empty .git/refs/heads/master and made .git/HEAD a\nsymlink to it.  Now, commit-id reads that file and gets confused.\n\nIf anybody has an idea what to put to .git/refs/heads/master please\nspeak up so that cg-init could be fixed.\n\n-- \nRegards,\nPavel Roskin\n\n"},{"id":"2522","messageId":"20050503211301.GA15995@pasky.ji.cz","threadId":"464","inReplyTo":"1115150585.28520.11.camel@dv","subject":"Re: commit-id fails after cg-init","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-03T21:13:01Z","receivedAt":"2005-05-03T21:13:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, May 03, 2005 at 10:03:05PM CEST, I got a letter\nwhere Pavel Roskin <proski@gnu.org> told me that...\n> Hello!\n\nHello,\n\n> So, cg-init created an empty .git/refs/heads/master and made .git/HEAD a\n> symlink to it.  Now, commit-id reads that file and gets confused.\n\nmy plan is to make cg-init:\n\n(i) automatically add to cache any existing content in the current directory,\n    if there is any\n(ii) call cg-commit right away\n\nThis will make us free of this annoying special case and if you are\nimporting an existing tree, you want to do this anyway. The only case\nwhen it is not 101% right is when starting a new project from fresh, but\nsome first \"dummy\" special commit shouldn't hurt there either (that will\nrequire to modify write-tree to be willing to write an empty tree).\n\nPatches welcome.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"2524","messageId":"20050503211458.GY4747@ca-server1.us.oracle.com","threadId":"464","inReplyTo":"1115150585.28520.11.camel@dv","subject":"Re: commit-id fails after cg-init","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-05-03T21:14:58Z","receivedAt":"2005-05-03T21:14:58Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Tue, May 03, 2005 at 04:03:05PM -0400, Pavel Roskin wrote:\n> So, cg-init created an empty .git/refs/heads/master and made .git/HEAD a\n> symlink to it.  Now, commit-id reads that file and gets confused.\n> \n> If anybody has an idea what to put to .git/refs/heads/master please\n> speak up so that cg-init could be fixed.\n\n\tWell, cg-init in this case creates no objects.  I'd say,\ninstead, it should create an empty tree object (representing a project\nwith no files) and commit that.  That would be your initial commit, and\nwould put something valid in heads/master.\n\nJoel\n\n-- \n\n\"The cynics are right nine times out of ten.\"  \n        - H. L. Mencken\n\nJoel Becker\nSenior Member of Technical Staff\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"2574","messageId":"4278E6D4.6060807@dwheeler.com","threadId":"464","inReplyTo":"20050503211301.GA15995@pasky.ji.cz","subject":"Re: commit-id fails after cg-init","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-05-04T15:14:28Z","receivedAt":"2005-05-04T15:14:28Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"Joel Becker said:\n\n> Well, cg-init in this case creates no objects.  I'd say,\n>instead, it should create an empty tree object (representing a project\n>with no files) and commit that.  That would be your initial commit, and\n>would put something valid in heads/master.\n\nThat would actually make sense; commits would go all the way\nback to the \"empty tree\" as the ultimate initial tree.\n\nThere's an interesting side-effect of this; I _think_ it's\nfine but it might be worth thinking through. If all\nnew projects start with an empty tree, that creates a\n\"common root\" that all projects can appeal to.\nThat means that in theory a merge between any two project root\ntrees can eventually find a common ancestor: the empty tree.\nI _think_ that's okay... is it?\n\nThat also means that empty directories will end up with the\n\"empty tree\" as well.  Is there a risk of multiple empty directories\ncausing problems later?  As far as I can tell, there aren't\nany problems with that, and does seem logically sound.\n\n--- David A. Wheeler\n\n\n\n"},{"id":"2576","messageId":"4278EE20.8080004@zytor.com","threadId":"464","inReplyTo":"4278E6D4.6060807@dwheeler.com","subject":"Re: commit-id fails after cg-init","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-05-04T15:45:36Z","receivedAt":"2005-05-04T15:45:36Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"David A. Wheeler wrote:\n> Joel Becker said:\n> \n>> Well, cg-init in this case creates no objects.  I'd say,\n>> instead, it should create an empty tree object (representing a project\n>> with no files) and commit that.  That would be your initial commit, and\n>> would put something valid in heads/master.\n> \n> That would actually make sense; commits would go all the way\n> back to the \"empty tree\" as the ultimate initial tree.\n> \n> There's an interesting side-effect of this; I _think_ it's\n> fine but it might be worth thinking through. If all\n> new projects start with an empty tree, that creates a\n> \"common root\" that all projects can appeal to.\n> That means that in theory a merge between any two project root\n> trees can eventually find a common ancestor: the empty tree.\n> I _think_ that's okay... is it?\n> \n\nIn fact, I think that's a Very Good Thing... it eliminates an \nunnecessary corner case.  Same reason linked lists want head nodes and \nall that jazz.\n\n\t-hpa\n"},{"id":"2612","messageId":"200505051122.03111.snake@penza-gsm.ru","threadId":"464","inReplyTo":"4278E6D4.6060807@dwheeler.com","subject":"Re: commit-id fails after cg-init","fromName":"Alexey Nezhdanov","fromEmail":"snake@penza-gsm.ru","sentAt":"2005-05-05T07:22:02Z","receivedAt":"2005-05-05T07:22:02Z","isPatch":false,"sender":{"key":"snake@penza-gsm.ru","avatar":null},"body":"Wensday, 04 May 2005 19:14 David A. Wheeler wrote:\n> Joel Becker said:\n> > Well, cg-init in this case creates no objects.  I'd say,\n> >instead, it should create an empty tree object (representing a project\n> >with no files) and commit that.  That would be your initial commit, and\n> >would put something valid in heads/master.\n>\n> That would actually make sense; commits would go all the way\n> back to the \"empty tree\" as the ultimate initial tree.\n>\n> There's an interesting side-effect of this; I _think_ it's\n> fine but it might be worth thinking through. If all\n> new projects start with an empty tree, that creates a\n> \"common root\" that all projects can appeal to.\n> That means that in theory a merge between any two project root\n> trees can eventually find a common ancestor: the empty tree.\n> I _think_ that's okay... is it?\n>\n> That also means that empty directories will end up with the\n> \"empty tree\" as well.  Is there a risk of multiple empty directories\n> causing problems later?  As far as I can tell, there aren't\n> any problems with that, and does seem logically sound.\nI think this problem can be easily solved with:\n1) Restricting to auto-select empty commit as the merge base\n2) Make an exception from rule (1) for first real commit\n\nBy (1) we will restrict accidental bad merges that can happen due to crasy \noperator - he will need to explicitly select empty commit as merge base.\n\nBy (2) we will allow to pull and merge projects that is just started \nenvolving.\n\n-- \nRespectfully\nAlexey Nezhdanov\n\n"},{"id":"2651","messageId":"427ADF1B.5000101@dwheeler.com","threadId":"464","inReplyTo":"200505051122.03111.snake@penza-gsm.ru","subject":"Re: commit-id fails after cg-init","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-05-06T03:06:03Z","receivedAt":"2005-05-06T03:06:03Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"I said:\n>>There's an interesting side-effect of this; I _think_ it's\n>>fine but it might be worth thinking through. If all\n>>new projects start with an empty tree, that creates a\n>>\"common root\" that all projects can appeal to.\n>>That means that in theory a merge between any two project root\n>>trees can eventually find a common ancestor: the empty tree.\n>>I _think_ that's okay... is it?\n\nAlexey Nezhdanov wrote:\n> I think this problem can be easily solved with:\n> 1) Restricting to auto-select empty commit as the merge base\n> 2) Make an exception from rule (1) for first real commit\n\nOkay, but that's only true if this is really a problem.\nI'm not sure it _is_, in fact I think the semantics make perfect sense.\nI just wanted to note that as the kind of change\nthat MIGHT have a surprising side-effect, so if anyone knew of one,\nplease speak up!\n\n> By (1) we will restrict accidental bad merges that can happen due to crasy \n> operator - he will need to explicitly select empty commit as merge base.\n\nIs that really a problem, though?  It seems to me that since a\nbad merge can be undone, it's not really a problem.\n\n--- David A. Wheeler\n"}]}