From: Jon Nelson <hidden> Date: 2016-06-15 22:42:15
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 [off-list ref]
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:15
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Jon Nelson <hidden> Date: 2016-06-15 22:42:15
On Mon, 19 Dec 2005, Andreas Ericsson wrote:
Jon Nelson wrote:
quoted
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.
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? The commits in question
*are* referenced by various tags, but not by any branch that exists any
more. The echo command effectively re-created the branch and all seems
well.
--
Jon Nelson [off-list ref]
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:15
Jon Nelson wrote:
On Mon, 19 Dec 2005, Andreas Ericsson wrote:
quoted
Jon Nelson wrote:
quoted
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Jon Nelson <hidden> Date: 2016-06-15 22:42:15
On Mon, 19 Dec 2005, Andreas Ericsson wrote:
Jon Nelson wrote:
quoted
On Mon, 19 Dec 2005, Andreas Ericsson wrote:
quoted
Jon Nelson wrote:
quoted
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.
That's the thing. I *had* run 'git prune' numerous times.
quoted
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?
--
Jon Nelson [off-list ref]
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:15
Jon Nelson wrote:
On Mon, 19 Dec 2005, Andreas Ericsson wrote:
quoted
quoted
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?
I suppose it must have been, which sort of contradicts how I thought
tags worked. Lucky thing though, eh? :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231