Re: dangling blob which is not dangling at all

Domenico Andreoli [off-list ref] writes:

This fixed things and also warned about two heads referring to pruned
commits, which may be those two commits I removed by hand (I hope).

Exactly.

All refs under .git/refs (the special case of this includes the
branch heads in .git/refs/heads) are your _promise_ to git that
everything that is reachable from them are supposed to be
available in your repository.  If you remove specific commits by
hand without adjusting the branch ref, you are breaking that
promise and git-fsck will notice it as a repository breakage.

If you do not need a branch and everything reachable only from
that branch, you can remove that branch (with "git branch -D"),
and run git-gc, which internally does the same reachability
analysis as git-fsck does and gets rid of objects that are no
longer necessary.

On Wed, Aug 01, 2007 at 12:27:10AM -0700, Junio C Hamano wrote:

Domenico Andreoli [off-list ref] writes:

quoted

This fixed things and also warned about two heads referring to pruned
commits, which may be those two commits I removed by hand (I hope).

Exactly.

All refs under .git/refs (the special case of this includes the
branch heads in .git/refs/heads) are your _promise_ to git that
everything that is reachable from them are supposed to be
available in your repository.  If you remove specific commits by
hand without adjusting the branch ref, you are breaking that
promise and git-fsck will notice it as a repository breakage.

If I move any ref by hand (not that I pass the day doing this..), I
understand that some commits may suddenly result as unreachable. But
those commits I removed by hand were already unreachable so no refs
should have been referring them.

What is this reflog thing and why is required?

Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Domenico Andreoli wrote:

What is this reflog thing and why is required?
  

It is a log of where each ref pointed at any given time. Or rather, a 
log of changes to refs, with timestamps. It is not *required* per se 
(you can turn it off and almost all of git will continue to work as 
before) but it's handy in that you can say stuff like

git checkout -b newbranch master@"{4 days ago}"

and git will give you a new branch pointing at the rev that master 
pointed to 4 days ago, even if it's a rev that is no longer reachable 
from any of the existing heads (e.g., because you did a "git rebase" and 
the rev in question was replaced by a new one.) Obviously as soon as you 
do a "git gc" you will lose the ability to go back to unreachable revs 
using the reflog.

I primarily use the reflog to undo rebase operations. Not that I need to 
do that very often, but it's occasionally handy, e.g., if there was a 
conflict and I made a mistake while resolving it.

-Steve

Steven Grimm wrote:

Domenico Andreoli wrote:

quoted

What is this reflog thing and why is required?
  

It is a log of where each ref pointed at any given time. Or rather, a 
log of changes to refs, with timestamps. It is not *required* per se 
(you can turn it off and almost all of git will continue to work as 
before) but it's handy in that you can say stuff like

git checkout -b newbranch master@"{4 days ago}"

and git will give you a new branch pointing at the rev that master 
pointed to 4 days ago, even if it's a rev that is no longer reachable 
from any of the existing heads (e.g., because you did a "git rebase" and 
the rev in question was replaced by a new one.) Obviously as soon as you 
do a "git gc" you will lose the ability to go back to unreachable revs 
using the reflog.

Not strictly true. "git gc" does take the reflogs into account when 
determining reachability, but it also prunes the reflogs periodically to 
prevent them from growing without bound (and preventing pruning of 
otherwise unreachable objects).

 From the git-gc manpage:

CONFIGURATION
  The optional configuration variable gc.reflogExpire can be set to
  indicate how long historical entries within each branch's reflog should
  remain available in this repository. The setting is expressed as a
  length of time, for example 90 days or 3 months. It defaults to 90
  days.

Regards,

Rogan

On Wed, Aug 01, 2007 at 11:13:27AM +0200, Rogan Dawes wrote:

Steven Grimm wrote:

quoted

Domenico Andreoli wrote:

quoted

What is this reflog thing and why is required?
  

It is a log of where each ref pointed at any given time. Or rather, a log 
of changes to refs, with timestamps. It is not *required* per se (you can 
turn it off and almost all of git will continue to work as before) but 
it's handy in that you can say stuff like
git checkout -b newbranch master@"{4 days ago}"
and git will give you a new branch pointing at the rev that master pointed 
to 4 days ago, even if it's a rev that is no longer reachable from any of 
the existing heads (e.g., because you did a "git rebase" and the rev in 
question was replaced by a new one.) Obviously as soon as you do a "git 
gc" you will lose the ability to go back to unreachable revs using the 
reflog.

Not strictly true. "git gc" does take the reflogs into account when 
determining reachability, but it also prunes the reflogs periodically to 
prevent them from growing without bound (and preventing pruning of 
otherwise unreachable objects).

so, besides playing with head refs by hand and forcing pushing to
"not strict subset" heads, having dangling commits may be physiologic?

and the only way to leak commits is from heads? on the countary, has
one a severely broken repository?

many thanks,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50