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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Mar 8, 2022, 12:59 UTC
Message-ID: <220308.868rtky4q8.gmgdl@evledraar.gmail.com>
In-Reply-To: <CAFQ2z_Oht=-QrzoH8FW_Jm-B7u9O0wXUaY-ifwZah6gkcgVVSA@mail.gmail.com>

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

Show 22 quoted lines

> 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).