On 08/20/2014 11:47 PM, Ronnie Sahlberg wrote:
> [...]
> Since we already display broken/unresolvable refs, I think the most
> consistent path is to also allow showing the refs broken/illegal-names
> too in the list. (when DO_FOR_EACH_INCLUDE_BROKEN is specified)
> Of course, an end user could fix
On Wed, Aug 20, 2014 at 11:34 AM, Michael Haggerty wrote:
> On 08/20/2014 06:28 PM, Ronnie Sahlberg wrote:
>> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty
>> wrote:
>>> I'm a little worried that abandoning *all* refname checks could open us
>>> up to somehow trying to delete a "reference" w
On Wed, Aug 20, 2014 at 1:11 PM, Michael Haggerty wrote:
> On 08/20/2014 09:45 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> I think we can get away with not including broken refnames when
>>> iterating. After all, the main goal of tolerating them is to let them
>>> be deleted, ri
Michael Haggerty writes:
> On 08/20/2014 09:45 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> I think we can get away with not including broken refnames when
>>> iterating. After all, the main goal of tolerating them is to let them
>>> be deleted, right?
>>
>> Or read from a ref
On 08/20/2014 09:45 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I think we can get away with not including broken refnames when
>> iterating. After all, the main goal of tolerating them is to let them
>> be deleted, right?
>
> Or read from a ref whose name has retroactively made i
Michael Haggerty writes:
> I think we can get away with not including broken refnames when
> iterating. After all, the main goal of tolerating them is to let them
> be deleted, right?
Or read from a ref whose name has retroactively made invalid, in
order to create a similar but validly named re
On 08/20/2014 06:28 PM, Ronnie Sahlberg wrote:
> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty
> wrote:
>> I'm a little worried that abandoning *all* refname checks could open us
>> up to somehow trying to delete a "reference" with a name like
>> "../../../../etc/passwd". Either such names h
On Wed, Aug 20, 2014 at 10:49 AM, Jonathan Nieder wrote:
> Hi,
>
> Ronnie Sahlberg wrote:
>> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty
>> wrote:
>
>>> I'm a little worried that abandoning *all* refname checks could open us
>>> up to somehow trying to delete a "reference" with a name like
Hi,
Ronnie Sahlberg wrote:
> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty
> wrote:
>> I'm a little worried that abandoning *all* refname checks could open us
>> up to somehow trying to delete a "reference" with a name like
>> "../../../../etc/passwd". Either such names have to be prohibit
On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty wrote:
> On 07/15/2014 10:58 PM, Ronnie Sahlberg wrote:
>> On Tue, Jul 15, 2014 at 12:34 PM, Ronnie Sahlberg
>> wrote:
>>> On Tue, Jul 15, 2014 at 11:04 AM, Jonathan Nieder
>>> wrote:
Michael Haggerty wrote:
> So...I like the idea
On 07/15/2014 10:58 PM, Ronnie Sahlberg wrote:
> On Tue, Jul 15, 2014 at 12:34 PM, Ronnie Sahlberg wrote:
>> On Tue, Jul 15, 2014 at 11:04 AM, Jonathan Nieder wrote:
>>> Michael Haggerty wrote:
>>>
So...I like the idea of enforcing refname checks at the lowest level
possible, but I thin
On Tue, Jul 15, 2014 at 12:34 PM, Ronnie Sahlberg wrote:
> On Tue, Jul 15, 2014 at 11:04 AM, Jonathan Nieder wrote:
>> Michael Haggerty wrote:
>>
>>> So...I like the idea of enforcing refname checks at the lowest level
>>> possible, but I think that the change you propose is too abrupt. I
>>> th
On Tue, Jul 15, 2014 at 11:34 AM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> How to take care of the recovery use case is another question. FWIW I
>> also would prefer if "git update-ref -d" or "git branch -D" could be
>> used to delete corrupt refs instead of having to use fsck (since
On Tue, Jul 15, 2014 at 11:04 AM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>
>> So...I like the idea of enforcing refname checks at the lowest level
>> possible, but I think that the change you propose is too abrupt. I
>> think it needs either more careful analysis showing that it won't h
Jonathan Nieder writes:
> How to take care of the recovery use case is another question. FWIW I
> also would prefer if "git update-ref -d" or "git branch -D" could be
> used to delete corrupt refs instead of having to use fsck (since a
> fsck run can take a while), but that's a question for a la
Ronnie Sahlberg wrote:
> What I suggest doing here is to create a new patch towards the end of
> the series that will :
> * change the resolve_ref_unsafe(... , int reading, ...) argument to be
> a bitmask of flags with
> #define RESOLVE_REF_READING 0x01 (== current flag)
> #define RESOLVE
Michael Haggerty wrote:
> So...I like the idea of enforcing refname checks at the lowest level
> possible, but I think that the change you propose is too abrupt. I
> think it needs either more careful analysis showing that it won't hurt
> anybody, or some kind of tooling or non-strict mode that p
On Tue, Jul 8, 2014 at 8:02 AM, Michael Haggerty wrote:
> On 06/20/2014 04:43 PM, Ronnie Sahlberg wrote:
>> Move the check for check_refname_format from lock_any_ref_for_update
>> to lock_ref_sha1_basic. At some later stage we will get rid of
>> lock_any_ref_for_update completely.
>>
>> If lock_re
On 06/20/2014 04:43 PM, Ronnie Sahlberg wrote:
> Move the check for check_refname_format from lock_any_ref_for_update
> to lock_ref_sha1_basic. At some later stage we will get rid of
> lock_any_ref_for_update completely.
>
> If lock_ref_sha1_basic fails the check_refname_format test, set errno to
Move the check for check_refname_format from lock_any_ref_for_update
to lock_ref_sha1_basic. At some later stage we will get rid of
lock_any_ref_for_update completely.
If lock_ref_sha1_basic fails the check_refname_format test, set errno to
EINVAL before returning NULL. This to guarantee that we w
20 matches
Mail list logo
