Branches and all commits

> Should *all* commits be reachable via at least one branch? I ran into a 
> situation this weekend that has me a little confused. I had performed a 
> number of commits and such and I noticed that the author and committer 
> info had suboptimal values. A bit of searching led me to a comment made 
> by Linus that basically said "go hack git-convert-objects", which I did. 
> After performing git-convert-objects on every commit object in 
> .git/refs/heads and the requisite pruning, etc... just about everything 
> looked fine. However, I still had a long series of commits that 
> contained the wrong information. Further inspection makes it appear as 
> though these commits are not reachable via any branch, although they are 
> /all/ reachable via a series of tags. I worked around the problem by 
> further modifying git-convert-objects to also understand tags (at least 
> the basic ones I've got) and that's all taken care of, but the question 
> remains: should *all* commit objects be reachable by at least one 
> branch?
> 

> Jon Nelson wrote:
> > Should *all* commits be reachable via at least one branch? I ran into a
> > situation this weekend that has me a little confused. I had performed a
> > number of commits and such and I noticed that the author and committer info
> > had suboptimal values. A bit of searching led me to a comment made by Linus
> > that basically said "go hack git-convert-objects", which I did. After
> > performing git-convert-objects on every commit object in .git/refs/heads and
> > the requisite pruning, etc... just about everything looked fine. However, I
> > still had a long series of commits that contained the wrong information.
> > Further inspection makes it appear as though these commits are not reachable
> > via any branch, although they are /all/ reachable via a series of tags. I
> > worked around the problem by further modifying git-convert-objects to also
> > understand tags (at least the basic ones I've got) and that's all taken care
> > of, but the question remains: should *all* commit objects be reachable by at
> > least one branch?
> > 
> 
> AFAIU, yes.
> 
> For future reference, what you should have done is this;
> 
> $ git format-patch --mbox <first-unscrewed-commit-ish>
> # edit commit-messages in generated patches
> $ git reset --hard <first-unscrewed-commit-ish>
> $ for i in 00*.txt; do git apply < $i; done
> $ git prune;# to get rid of the unreachable objects AFTER you've checked
> everything's all right
> 
> If things fail, do
> 
> $ git reset --hard ORIG_HEAD
> 
> and ask again.
> 
> I'm afraid I can't help you fix up your repository from the state it's 
> in now. AFAIK, there's no tool to do it automagically.

> On Mon, 19 Dec 2005, Andreas Ericsson wrote:
> 
> 
>>Jon Nelson wrote:
>>
>>>Should *all* commits be reachable via at least one branch? I ran into a
>>>situation this weekend that has me a little confused. I had performed a
>>>number of commits and such and I noticed that the author and committer info
>>>had suboptimal values. A bit of searching led me to a comment made by Linus
>>>that basically said "go hack git-convert-objects", which I did. After
>>>performing git-convert-objects on every commit object in .git/refs/heads and
>>>the requisite pruning, etc... just about everything looked fine. However, I
>>>still had a long series of commits that contained the wrong information.
>>>Further inspection makes it appear as though these commits are not reachable
>>>via any branch, although they are /all/ reachable via a series of tags. I
>>>worked around the problem by further modifying git-convert-objects to also
>>>understand tags (at least the basic ones I've got) and that's all taken care
>>>of, but the question remains: should *all* commit objects be reachable by at
>>>least one branch?
>>>
>>
>>AFAIU, yes.
>>
>>For future reference, what you should have done is this;
>>
>>$ git format-patch --mbox <first-unscrewed-commit-ish>
>># edit commit-messages in generated patches
>>$ git reset --hard <first-unscrewed-commit-ish>
>>$ for i in 00*.txt; do git apply < $i; done
>>$ git prune;# to get rid of the unreachable objects AFTER you've checked
>>everything's all right
>>
>>If things fail, do
>>
>>$ git reset --hard ORIG_HEAD
>>
>>and ask again.
>>
>>I'm afraid I can't help you fix up your repository from the state it's 
>>in now. AFAIK, there's no tool to do it automagically.
> 
> 
> The repository seems just fine with this single exception - no branch 
> contains a reference to the commit that forms the chain of commits that 
> would otherwise be described as a branch. As I understand it, then, the 
> only thing that is missing is an entry in .git/refs/heads.
> 
> Experimentally, I added that entry by determining the first commit in 
> that chain and echoing that sha1 into .git/refs/heads/some_name and that 
> works as expected.
> 

> Jon Nelson wrote:
> > On Mon, 19 Dec 2005, Andreas Ericsson wrote:
> > 
> > 
> > >Jon Nelson wrote:
> > >
> > > >Should *all* commits be reachable via at least one branch? I ran into a
> > > >situation this weekend that has me a little confused. I had performed a
> > > >number of commits and such and I noticed that the author and committer
> > > >info
> > > >had suboptimal values. A bit of searching led me to a comment made by
> > > >Linus
> > > >that basically said "go hack git-convert-objects", which I did. After
> > > >performing git-convert-objects on every commit object in .git/refs/heads
> > > >and
> > > >the requisite pruning, etc... just about everything looked fine. However,
> > > >I
> > > >still had a long series of commits that contained the wrong information.
> > > >Further inspection makes it appear as though these commits are not
> > > >reachable
> > > >via any branch, although they are /all/ reachable via a series of tags. I
> > > >worked around the problem by further modifying git-convert-objects to
> > > >also
> > > >understand tags (at least the basic ones I've got) and that's all taken
> > > >care
> > > >of, but the question remains: should *all* commit objects be reachable by
> > > >at
> > > >least one branch?
> > > >
> > >
> > >AFAIU, yes.
> > >
> > >For future reference, what you should have done is this;
> > >
> > >$ git format-patch --mbox <first-unscrewed-commit-ish>
> > ># edit commit-messages in generated patches
> > >$ git reset --hard <first-unscrewed-commit-ish>
> > >$ for i in 00*.txt; do git apply < $i; done
> > >$ git prune;# to get rid of the unreachable objects AFTER you've checked
> > >everything's all right
> > >
> > >If things fail, do
> > >
> > >$ git reset --hard ORIG_HEAD
> > >
> > >and ask again.
> > >
> > >I'm afraid I can't help you fix up your repository from the state it's in
> > >now. AFAIK, there's no tool to do it automagically.
> > 
> > 
> > The repository seems just fine with this single exception - no branch
> > contains a reference to the commit that forms the chain of commits that
> > would otherwise be described as a branch. As I understand it, then, the only
> > thing that is missing is an entry in .git/refs/heads.
> > 
> > Experimentally, I added that entry by determining the first commit in that
> > chain and echoing that sha1 into .git/refs/heads/some_name and that works as
> > expected.
> > 
> 
> Lucky thing. I expect you still had all the objects required for the tree to
> do this. If you had run 'git prune' on the repo they would have been lost for
> good though.

> > I suspect that the root cause was a 'git branch -D' I issued a while back.
> > My question is this: if deleting a branch in that manner caused me to enter
> > this situation, is that a bug or no?
> 
> It's not a bug. You probably meant to do
> 
> 	$ git branch -d
> 
> -D forces removal even if there are objects reachable only through that
> branch. The man-page says so, but in git'ish, which isn't always intuitive
> until you've grown familiar with the glossary.txt doc.

> On Mon, 19 Dec 2005, Andreas Ericsson wrote:
> 
>>>I suspect that the root cause was a 'git branch -D' I issued a while back.
>>>My question is this: if deleting a branch in that manner caused me to enter
>>>this situation, is that a bug or no?
>>
>>It's not a bug. You probably meant to do
>>
>>	$ git branch -d
>>
>>-D forces removal even if there are objects reachable only through that
>>branch. The man-page says so, but in git'ish, which isn't always intuitive
>>until you've grown familiar with the glossary.txt doc.
> 
> 
> I tried 'git branch -d' initially and it refused to delete the branch.
> So I tried 'git branch -D'.
> 
> Re-reading your last paragraph makes it clear what happened, then.
> I'll note that I ran 'git branch -D' *days* ago and I've run git-prune 
> literally a couple dozen times since then. Is it possible the objects 
> weren't removed because they were still referenced by tags?
>