Re: can we prevent reflog deletion when branch is deleted?

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Nov 14, 2013, 13:48 UTC
Message-ID: <5284D4AA.2030204@gmail.com>
In-Reply-To: <66513F31-CF2E-4327-AEA3-20176C14EEE1@gmail.com>

On 11/14/2013 04:47 PM, Luca Milanesio wrote:

Show 5 quoted lines

> Would be really useful anyway to have the ability to create a
> server-side reference based on a SHA-1, using the Git protocol.
> Alternatively, just fetching a remote repo based on a SHA-1 (not
> referenced by any ref-spec but still existent) so that you can create
> a new reference locally and push.

That's a security issue.

Just to clarify, what I am asking for is the ability to recover on the server, where you have access to the actual files that comprise the repo.

sitaram

Show 43 quoted lines

> 
> Luca.
> 
> On 14 Nov 2013, at 11:09, Jeff King <peff@peff.net> wrote:
> 
>> On Thu, Nov 14, 2013 at 04:26:46PM +0530, Sitaram Chamarty wrote:
>>
>>>> I do not know about any particular debate in git circles, but I assume
>>>> Sitaram is referring to this incident:
>>>>
>>>>  https://groups.google.com/d/msg/jenkinsci-dev/-myjRIPcVwU/t4nkXONp8qgJ
>>>>
>>>> in which a Jenkins dev force-pushed and rewound history on 150 different
>>>> repos. In this case the reflog made rollback easy, but if he had pushed
>>>> a deletion, it would be harder.
>>>
>>> I don't know if they had a reflog on the server side; they used
>>> client-side reflogs if I understood correctly.
>>>
>>> I'm talking about server side (bare repo), assuming the site has
>>> core.logAllRefUpdates set.
>>
>> Yes, they did have server-side reflogs (the pushes were to GitHub, and
>> we reflog everything). Client-side reflogs would not be sufficient, as
>> the client who pushed does not record the history he just rewound (he
>> _might_ have it at refs/remotes/origin/master@{1}, but if somebody
>> pushed since his last fetch, then he doesn't).
>>
>> The "simplest" way to recover is to just have everyone push again
>> (without --force). The history will just silently fast-forward to
>> whoever has the most recent tip. The downside is that you have to wait
>> for that person to actually push. :)
>>
>> I think they started with that, and then eventually GitHub support got
>> wind of it and pulled the last value for each repo out of the
>> server-side reflog for them.
>>
>> -Peff
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>