Hi, On Thu, 11 Feb 2021, Jeff King wrote: > On Wed, Feb 10, 2021 at 12:30:27PM -0800, Junio C Hamano wrote: > > > I appreciate an effort of making it looser and less likely to get in > > trouble when running in a corrupt repository, but --stale-fix is a > > bit special and should probably be removed. > > > > The only reason the option was added was because we needed to have > > an easy way to recover from a specific kind of reflog corruption > > that would have resulted by a (then known) bug in "git reflog" in > > the released version of Git that came immediately before the version > > of Git that added the "fix" option, while the root cause of the > > corruption got fixed. > > > > Back when 1389d9dd (reflog expire --fix-stale, 2007-01-06) was > > written, it was very useful to have a way to recover from the > > corruption likely to have happened with the version of Git that came > > before it. But it no longer is relevant after this many years. > > There may be other ways to break the reflog entries, but --stale-fix > > was never designed to deal with anything but a specific way the > > reflog gets corrupted (namely, by the old version of Git that > > corrupted reflog in a specific way), so keeping it would not be very > > useful. Thank you for the original historical context. > FWIW, I have used --stale-fix for cases where a repo's reflog was > "corrupted" by its alternate pruning objects. > > E.g., if you do something like this: > > git clone -s orig.git new.git > > you're now at risk of "git gc" in orig.git corrupting new.git, because > its reachability check doesn't know anything about those refs. You can > mitigate that by keeping a copy of new.git's refs in orig.git. Something > like: > > git -C orig.git fetch ../new.git refs/*:refs/preserve/* > git -C orig.git gc > > But that doesn't know about reflogs at all! It will still corrupt them > (but only sometimes; depending how often you do that fetch, you might > catch the same values in orig.git's reflog). > > Possibly the correct answer here is "turn off reflogs in new.git", but > they are sometimes useful, and things _mostly_ work (for history that > doesn't rewind, or where the rewound bits are specific to new.git). So > it's useful to be able to run something like "reflog expire --stale-fix" > to clear out the occasional problem. > > (A careful reader will note that objects mentioned only in the index > have a similar problem; but again, those tend to be local to new.git, > and don't exist at all in a server context). I want to add the experience with that half year during which `git gc` with worktrees was broken, as it would happily ignore the reflogs of the worktree-specific `HEAD`s, all except the one from the worktree from which `git gc` was run. That was some fun time, and `--stale-fix` was a life saver. With this _additional_ historical context, I would deem it wise to keep `--stale-fix` around. Ciao, Dscho
