Re: Keep reflogs for deleted (remote tracking) branches?

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Mar 08 2022, Han-Wen Nienhuys wrote:

> On Tue, Mar 8, 2022 at 12:28 PM Tao Klerks <tao@klerks.biz> wrote:
>> As far as I can tell, even "core.logAllRefUpdates=always" does *not*
>> keep any reflog entries around, even temporarily (until reflog
>> expiry), once a ref  is deleted - do I understand that correctly? Is
>> this behavior intentional / reasoned, or just a consequence of the
>> fact that it's *hard* to keep "managing" per-branch reflogs for
>> branches that don't exist?
>>
>> I am planning a workaround using server hooks to "back up" refs that
>> are being deleted from specific namespaces, in my specific case, and I
>> imagine that a system like github keeps track of deleted stuff itself
>> for a while, but I find this "per-ref reflog disappearance" behavior
>> puzzling / out-of-character, so wanted to make sure I'm not missing
>> something.
>
> I think this behavior is motivated by directory/file conflicts. If you
> have a reflog file in refs/logs/foo, you can't create a reflog for
> refs/foo/bar, because that would live in refs/logs/foo/bar
>
> At Google, we keep reflogs in a completely different storage system
> altogether, which avoids this problem, and I wouldn't be surprised if
> other large hosting providers do something similar.

I once worked on a system where:

 * References would be "archived", i.e. just a backup system that would
   run "git fetch" without pruning.

 * You were only allowed to push to either existing branches like
   "master", or names with exactly one slash in them, e.g. "avar/topic",
   not "avar/topic/nested", for that you'd need "avar/topic-nested" or
   whatever.

The second item neatly avoids D/F conflicts, at the cost of some
grumbling from people who can't use their preferred branch name.

And you can easily implement backups without that constraint by fetching
refs/* to refs/YYYYMMDD-HHMMSS/* or whatever, and have some manual
pruning process in place for those "secondly refs".

More generally I have not really run into this as a practical
problem.

I.e. if a co-worker created a branch, AND nobody else used it, AND
nothing was based on it, AND someone (presumably they) thought it was OK
to delete it, it was probably something nobody cared all that much about
to begin with :)

Another way to solve a similar problem is to have
pre-receive/post-receive hooks log attempted/successful pushes, which
along with an appropriate "gc" policy will allow you to manually look up
these older branches (or even to fetch them, if you publish the log and
set uploadpack.allowAnySHA1InWant=true).