{"thread":{"id":"2880","subject":"Branches and all commits","startedAt":"2005-12-19T15:15:31Z","lastAt":"2005-12-19T19:32:13Z","messageCount":6,"participants":["Jon Nelson","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13812","messageId":"Pine.LNX.4.63.0512190908140.6812@gheavc.wnzcbav.cig","threadId":"2880","inReplyTo":null,"subject":"Branches and all commits","fromName":"Jon Nelson","fromEmail":"jnelson-git@jamponi.net","sentAt":"2005-12-19T15:15:31Z","receivedAt":"2005-12-19T15:15:31Z","isPatch":false,"sender":{"key":"jnelson-git@jamponi.net","avatar":null},"body":"\nShould *all* commits be reachable via at least one branch? I ran into a \nsituation this weekend that has me a little confused. I had performed a \nnumber of commits and such and I noticed that the author and committer \ninfo had suboptimal values. A bit of searching led me to a comment made \nby Linus that basically said \"go hack git-convert-objects\", which I did. \nAfter performing git-convert-objects on every commit object in \n.git/refs/heads and the requisite pruning, etc... just about everything \nlooked fine. However, I still had a long series of commits that \ncontained the wrong information. Further inspection makes it appear as \nthough these commits are not reachable via any branch, although they are \n/all/ reachable via a series of tags. I worked around the problem by \nfurther modifying git-convert-objects to also understand tags (at least \nthe basic ones I've got) and that's all taken care of, but the question \nremains: should *all* commit objects be reachable by at least one \nbranch?\n\n--\nJon Nelson <jnelson-git@jamponi.net>\n"},{"id":"13814","messageId":"43A6DC90.3040403@op5.se","threadId":"2880","inReplyTo":"Pine.LNX.4.63.0512190908140.6812@gheavc.wnzcbav.cig","subject":"Re: Branches and all commits","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-12-19T16:15:12Z","receivedAt":"2005-12-19T16:15:12Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jon Nelson wrote:\n> Should *all* commits be reachable via at least one branch? I ran into a \n> situation this weekend that has me a little confused. I had performed a \n> number of commits and such and I noticed that the author and committer \n> info had suboptimal values. A bit of searching led me to a comment made \n> by Linus that basically said \"go hack git-convert-objects\", which I did. \n> After performing git-convert-objects on every commit object in \n> .git/refs/heads and the requisite pruning, etc... just about everything \n> looked fine. However, I still had a long series of commits that \n> contained the wrong information. Further inspection makes it appear as \n> though these commits are not reachable via any branch, although they are \n> /all/ reachable via a series of tags. I worked around the problem by \n> further modifying git-convert-objects to also understand tags (at least \n> the basic ones I've got) and that's all taken care of, but the question \n> remains: should *all* commit objects be reachable by at least one \n> branch?\n> \n\nAFAIU, yes.\n\nFor future reference, what you should have done is this;\n\n$ git format-patch --mbox <first-unscrewed-commit-ish>\n# edit commit-messages in generated patches\n$ git reset --hard <first-unscrewed-commit-ish>\n$ for i in 00*.txt; do git apply < $i; done\n$ git prune;# to get rid of the unreachable objects AFTER you've checked \neverything's all right\n\nIf things fail, do\n\n$ git reset --hard ORIG_HEAD\n\nand ask again.\n\nI'm afraid I can't help you fix up your repository from the state it's \nin now. AFAIK, there's no tool to do it automagically.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"13818","messageId":"Pine.LNX.4.63.0512191104080.6812@gheavc.wnzcbav.cig","threadId":"2880","inReplyTo":"43A6DC90.3040403@op5.se","subject":"Re: Branches and all commits","fromName":"Jon Nelson","fromEmail":"jnelson-git@jamponi.net","sentAt":"2005-12-19T17:39:06Z","receivedAt":"2005-12-19T17:39:06Z","isPatch":false,"sender":{"key":"jnelson-git@jamponi.net","avatar":null},"body":"On Mon, 19 Dec 2005, Andreas Ericsson wrote:\n\n> Jon Nelson wrote:\n> > Should *all* commits be reachable via at least one branch? I ran into a\n> > situation this weekend that has me a little confused. I had performed a\n> > number of commits and such and I noticed that the author and committer info\n> > had suboptimal values. A bit of searching led me to a comment made by Linus\n> > that basically said \"go hack git-convert-objects\", which I did. After\n> > performing git-convert-objects on every commit object in .git/refs/heads and\n> > the requisite pruning, etc... just about everything looked fine. However, I\n> > still had a long series of commits that contained the wrong information.\n> > Further inspection makes it appear as though these commits are not reachable\n> > via any branch, although they are /all/ reachable via a series of tags. I\n> > worked around the problem by further modifying git-convert-objects to also\n> > understand tags (at least the basic ones I've got) and that's all taken care\n> > of, but the question remains: should *all* commit objects be reachable by at\n> > least one branch?\n> > \n> \n> AFAIU, yes.\n> \n> For future reference, what you should have done is this;\n> \n> $ git format-patch --mbox <first-unscrewed-commit-ish>\n> # edit commit-messages in generated patches\n> $ git reset --hard <first-unscrewed-commit-ish>\n> $ for i in 00*.txt; do git apply < $i; done\n> $ git prune;# to get rid of the unreachable objects AFTER you've checked\n> everything's all right\n> \n> If things fail, do\n> \n> $ git reset --hard ORIG_HEAD\n> \n> and ask again.\n> \n> I'm afraid I can't help you fix up your repository from the state it's \n> in now. AFAIK, there's no tool to do it automagically.\n\nThe repository seems just fine with this single exception - no branch \ncontains a reference to the commit that forms the chain of commits that \nwould otherwise be described as a branch. As I understand it, then, the \nonly thing that is missing is an entry in .git/refs/heads.\n\nExperimentally, I added that entry by determining the first commit in \nthat chain and echoing that sha1 into .git/refs/heads/some_name and that \nworks as expected.\n\nI suspect that the root cause was a 'git branch -D' I issued a while \nback. My question is this: if deleting a branch in that manner caused me \nto enter this situation, is that a bug or no? The commits in question \n*are* referenced by various tags, but not by any branch that exists any \nmore.  The echo command effectively re-created the branch and all seems \nwell.\n\n--\nJon Nelson <jnelson-git@jamponi.net>\n"},{"id":"13819","messageId":"43A6F378.6010503@op5.se","threadId":"2880","inReplyTo":"Pine.LNX.4.63.0512191104080.6812@gheavc.wnzcbav.cig","subject":"Re: Branches and all commits","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-12-19T17:52:56Z","receivedAt":"2005-12-19T17:52:56Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jon Nelson wrote:\n> On Mon, 19 Dec 2005, Andreas Ericsson wrote:\n> \n> \n>>Jon Nelson wrote:\n>>\n>>>Should *all* commits be reachable via at least one branch? I ran into a\n>>>situation this weekend that has me a little confused. I had performed a\n>>>number of commits and such and I noticed that the author and committer info\n>>>had suboptimal values. A bit of searching led me to a comment made by Linus\n>>>that basically said \"go hack git-convert-objects\", which I did. After\n>>>performing git-convert-objects on every commit object in .git/refs/heads and\n>>>the requisite pruning, etc... just about everything looked fine. However, I\n>>>still had a long series of commits that contained the wrong information.\n>>>Further inspection makes it appear as though these commits are not reachable\n>>>via any branch, although they are /all/ reachable via a series of tags. I\n>>>worked around the problem by further modifying git-convert-objects to also\n>>>understand tags (at least the basic ones I've got) and that's all taken care\n>>>of, but the question remains: should *all* commit objects be reachable by at\n>>>least one branch?\n>>>\n>>\n>>AFAIU, yes.\n>>\n>>For future reference, what you should have done is this;\n>>\n>>$ git format-patch --mbox <first-unscrewed-commit-ish>\n>># edit commit-messages in generated patches\n>>$ git reset --hard <first-unscrewed-commit-ish>\n>>$ for i in 00*.txt; do git apply < $i; done\n>>$ git prune;# to get rid of the unreachable objects AFTER you've checked\n>>everything's all right\n>>\n>>If things fail, do\n>>\n>>$ git reset --hard ORIG_HEAD\n>>\n>>and ask again.\n>>\n>>I'm afraid I can't help you fix up your repository from the state it's \n>>in now. AFAIK, there's no tool to do it automagically.\n> \n> \n> The repository seems just fine with this single exception - no branch \n> contains a reference to the commit that forms the chain of commits that \n> would otherwise be described as a branch. As I understand it, then, the \n> only thing that is missing is an entry in .git/refs/heads.\n> \n> Experimentally, I added that entry by determining the first commit in \n> that chain and echoing that sha1 into .git/refs/heads/some_name and that \n> works as expected.\n> \n\nLucky thing. I expect you still had all the objects required for the \ntree to do this. If you had run 'git prune' on the repo they would have \nbeen lost for good though.\n\n\n> I suspect that the root cause was a 'git branch -D' I issued a while \n> back. My question is this: if deleting a branch in that manner caused me \n> to enter this situation, is that a bug or no?\n\n\nIt's not a bug. You probably meant to do\n\n\t$ git branch -d\n\n-D forces removal even if there are objects reachable only through that \nbranch. The man-page says so, but in git'ish, which isn't always \nintuitive until you've grown familiar with the glossary.txt doc.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"13821","messageId":"Pine.LNX.4.63.0512191257240.6812@gheavc.wnzcbav.cig","threadId":"2880","inReplyTo":"43A6F378.6010503@op5.se","subject":"Re: Branches and all commits","fromName":"Jon Nelson","fromEmail":"jnelson-git@jamponi.net","sentAt":"2005-12-19T18:59:55Z","receivedAt":"2005-12-19T18:59:55Z","isPatch":false,"sender":{"key":"jnelson-git@jamponi.net","avatar":null},"body":"On Mon, 19 Dec 2005, Andreas Ericsson wrote:\n\n> Jon Nelson wrote:\n> > On Mon, 19 Dec 2005, Andreas Ericsson wrote:\n> > \n> > \n> > >Jon Nelson wrote:\n> > >\n> > > >Should *all* commits be reachable via at least one branch? I ran into a\n> > > >situation this weekend that has me a little confused. I had performed a\n> > > >number of commits and such and I noticed that the author and committer\n> > > >info\n> > > >had suboptimal values. A bit of searching led me to a comment made by\n> > > >Linus\n> > > >that basically said \"go hack git-convert-objects\", which I did. After\n> > > >performing git-convert-objects on every commit object in .git/refs/heads\n> > > >and\n> > > >the requisite pruning, etc... just about everything looked fine. However,\n> > > >I\n> > > >still had a long series of commits that contained the wrong information.\n> > > >Further inspection makes it appear as though these commits are not\n> > > >reachable\n> > > >via any branch, although they are /all/ reachable via a series of tags. I\n> > > >worked around the problem by further modifying git-convert-objects to\n> > > >also\n> > > >understand tags (at least the basic ones I've got) and that's all taken\n> > > >care\n> > > >of, but the question remains: should *all* commit objects be reachable by\n> > > >at\n> > > >least one branch?\n> > > >\n> > >\n> > >AFAIU, yes.\n> > >\n> > >For future reference, what you should have done is this;\n> > >\n> > >$ git format-patch --mbox <first-unscrewed-commit-ish>\n> > ># edit commit-messages in generated patches\n> > >$ git reset --hard <first-unscrewed-commit-ish>\n> > >$ for i in 00*.txt; do git apply < $i; done\n> > >$ git prune;# to get rid of the unreachable objects AFTER you've checked\n> > >everything's all right\n> > >\n> > >If things fail, do\n> > >\n> > >$ git reset --hard ORIG_HEAD\n> > >\n> > >and ask again.\n> > >\n> > >I'm afraid I can't help you fix up your repository from the state it's in\n> > >now. AFAIK, there's no tool to do it automagically.\n> > \n> > \n> > The repository seems just fine with this single exception - no branch\n> > contains a reference to the commit that forms the chain of commits that\n> > would otherwise be described as a branch. As I understand it, then, the only\n> > thing that is missing is an entry in .git/refs/heads.\n> > \n> > Experimentally, I added that entry by determining the first commit in that\n> > chain and echoing that sha1 into .git/refs/heads/some_name and that works as\n> > expected.\n> > \n> \n> Lucky thing. I expect you still had all the objects required for the tree to\n> do this. If you had run 'git prune' on the repo they would have been lost for\n> good though.\n\nThat's the thing. I *had* run 'git prune' numerous times.\n\n> > I suspect that the root cause was a 'git branch -D' I issued a while back.\n> > My question is this: if deleting a branch in that manner caused me to enter\n> > this situation, is that a bug or no?\n> \n> It's not a bug. You probably meant to do\n> \n> \t$ git branch -d\n> \n> -D forces removal even if there are objects reachable only through that\n> branch. The man-page says so, but in git'ish, which isn't always intuitive\n> until you've grown familiar with the glossary.txt doc.\n\nI tried 'git branch -d' initially and it refused to delete the branch.\nSo I tried 'git branch -D'.\n\nRe-reading your last paragraph makes it clear what happened, then.\nI'll note that I ran 'git branch -D' *days* ago and I've run git-prune \nliterally a couple dozen times since then. Is it possible the objects \nweren't removed because they were still referenced by tags?\n\n--\nJon Nelson <jnelson-git@jamponi.net>\n"},{"id":"13822","messageId":"43A70ABD.4090003@op5.se","threadId":"2880","inReplyTo":"Pine.LNX.4.63.0512191257240.6812@gheavc.wnzcbav.cig","subject":"Re: Branches and all commits","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-12-19T19:32:13Z","receivedAt":"2005-12-19T19:32:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jon Nelson wrote:\n> On Mon, 19 Dec 2005, Andreas Ericsson wrote:\n> \n>>>I suspect that the root cause was a 'git branch -D' I issued a while back.\n>>>My question is this: if deleting a branch in that manner caused me to enter\n>>>this situation, is that a bug or no?\n>>\n>>It's not a bug. You probably meant to do\n>>\n>>\t$ git branch -d\n>>\n>>-D forces removal even if there are objects reachable only through that\n>>branch. The man-page says so, but in git'ish, which isn't always intuitive\n>>until you've grown familiar with the glossary.txt doc.\n> \n> \n> I tried 'git branch -d' initially and it refused to delete the branch.\n> So I tried 'git branch -D'.\n> \n> Re-reading your last paragraph makes it clear what happened, then.\n> I'll note that I ran 'git branch -D' *days* ago and I've run git-prune \n> literally a couple dozen times since then. Is it possible the objects \n> weren't removed because they were still referenced by tags?\n> \n\nI suppose it must have been, which sort of contradicts how I thought \ntags worked. Lucky thing though, eh? :)\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"}]}