{"thread":{"id":"9579","subject":"On writing builtin-reset.c, a question about git-reset.sh","startedAt":"2007-08-19T23:45:08Z","lastAt":"2007-08-20T00:24:52Z","messageCount":2,"participants":["Carlos Rica","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51029","messageId":"46C8D604.4090203@gmail.com","threadId":"9579","inReplyTo":null,"subject":"On writing builtin-reset.c, a question about git-reset.sh","fromName":"Carlos Rica","fromEmail":"jasampler@gmail.com","sentAt":"2007-08-19T23:45:08Z","receivedAt":"2007-08-19T23:45:08Z","isPatch":false,"sender":{"key":"jasampler@gmail.com","avatar":null},"body":"Hi, I'm writing builtin-reset.c and\nI'm really stuck with a little code in\ngit-reset.sh:\n\nif orig=$(git rev-parse --verify HEAD 2>/dev/null)\nthen\n\techo \"$orig\" >\"$GIT_DIR/ORIG_HEAD\"\nelse\n\trm -f \"$GIT_DIR/ORIG_HEAD\"\nfi\n\nMy question is about when this condition\ncould fail (and then the rm executed), and\nif you would be able to reproduce it in tests.\nI couldn't, and asking for this in the IRC\ndidn't help me at all.\n\nThis code was introduced in 45d197, when\ndifferent reset types were introduced,\nand it seems that there was a reason for\ndoing it that way, looking at the change.\n\nThanks in advance for your support.\n\n--\nCarlos\n"},{"id":"51030","messageId":"7vir7b9hnv.fsf@gitster.siamese.dyndns.org","threadId":"9579","inReplyTo":"46C8D604.4090203@gmail.com","subject":"Re: On writing builtin-reset.c, a question about git-reset.sh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-20T00:24:52Z","receivedAt":"2007-08-20T00:24:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Rica <jasampler@gmail.com> writes:\n\n> Hi, I'm writing builtin-reset.c and\n> I'm really stuck with a little code in\n> git-reset.sh:\n>\n> if orig=$(git rev-parse --verify HEAD 2>/dev/null)\n> then\n> \techo \"$orig\" >\"$GIT_DIR/ORIG_HEAD\"\n> else\n> \trm -f \"$GIT_DIR/ORIG_HEAD\"\n> fi\n>\n> My question is about when this condition\n> could fail (and then the rm executed),...\n\nWhen orig does not exist.  That is, when HEAD is a symref that\npoint at an unborn branch (e.g. between \"git init\" and your\nfirst \"git commit\").  After \"git reset\" of any kind, we would\nwant to make sure that GIT_DIR/ORIG_HEAD points at the commit\nyou were previously at, and if orig is not there we do not want\nanything in that file.\n\nAnother possibility would be if somebody wants to add an\nunrelated branch to the repository [*1*].  This is against\nrecommended practice, but you could make your HEAD point at an\nunborn branch using plumbing commands, or even by hand:\n\n\t$ echo 'ref: refs/heads/unrelated' >.git/HEAD\n\nYour next commit will make a root commit that is pointed by\n'refs/heads/unrelated' ref, but before that happens, we would\nnot want to have GIT_DIR/ORIG_HEAD if you did git-reset.\n\nNow, you might wonder if \"git reset\" makes any sense from such a\nstate, and actually it does ;-)\n\n\t$ git init\n        $ git remote add -f friend ../neighbour.git/\n        $ git reset --hard friend/master\n\n[Footnote]\n\n*1* People often seem to want to do something like the html, man, and\ntodo branches in my public repository that do not share any history\nwith the primary development branches.  Perhaps they think it is cool\nto do so, but it is not.  These independent branches originate from\ndifferent repositories, and are published in the same repository only\nfor easier distribution.  There is no reason for you (nor me) to\ncreate such unrelated branches in a single originating repository.\n\nA recommended procedure to publish independent branches in a single\nrepository is to push into one from separate, independent\nrepositories.  Starting an independent history in an existing\nrepository, like the main body of this message shows you how, is not\nrecommended.\n"}]}