Hi Michael & Junio,
On 2015-01-22 18:17, Johannes Schindelin wrote:
> [...] we need to avoid confusing settings such as
>
> ```
> [receive.fsck]
> warn = missing-tagger-entry
> error = missing-tagger-entry
> ```
I *think* I found a solution.
Please let me recapitulate quickly the probl
Hi Michael,
On 2015-01-22 16:49, Michael Haggerty wrote:
> On 12/23/2014 06:14 PM, Junio C Hamano wrote:
>> Johannes Schindelin writes:
>>> On Tue, 23 Dec 2014, Junio C Hamano wrote:
I suspect that it would be much better if the configuration variables
were organized the other way aroun
On 12/23/2014 06:14 PM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>> On Tue, 23 Dec 2014, Junio C Hamano wrote:
>>> I suspect that it would be much better if the configuration variables
>>> were organized the other way around, e.g.
>>>
>>> $ git config fsck.warn missingTagger,someOth
Johannes Schindelin writes:
> Unfortunately, I will not be able to submit v2 of this patch series this
> year, but I will do so in the second week of January (including the change
> to the global array with the default severity levels because I do want to
> see this feature integrated).
Heh, we
Hi Junio,
On Tue, 23 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Tue, 23 Dec 2014, Junio C Hamano wrote:
> >
> >> Having said that, I think "missingTags" etc. should not be
> >> configuration variable names (instead, they should be values).
> >>
> >> Because of that,
Johannes Schindelin writes:
> Hi Junio,
>
> On Tue, 23 Dec 2014, Junio C Hamano wrote:
>
>> Having said that, I think "missingTags" etc. should not be configuration
>> variable names (instead, they should be values).
>>
>> Because of that, I do not think we need consistency between the way
>> th
Hi Junio,
On Tue, 23 Dec 2014, Junio C Hamano wrote:
> Having said that, I think "missingTags" etc. should not be configuration
> variable names (instead, they should be values).
>
> Because of that, I do not think we need consistency between the way
> these "tokens that denote kinds of errors f
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> Okay, so just to clarify: you want me to
>>
>> - split the parser into
>>
>> - a parser that accepts only camelCased variable names when they
>>come from the config (for use in fsck and receive-pack), and
>
> OK.
>
>> -
Hi Junio,
On Tue, 23 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Okay, so just to clarify: you want me to
> >
> > - split the parser into
> >
> > - a parser that accepts only camelCased variable names when they
> > come from the config (for use in fsck and receiv
Johannes Schindelin writes:
> Okay, so just to clarify: you want me to
>
> - split the parser into
>
> - a parser that accepts only camelCased variable names when they
> come from the config (for use in fsck and receive-pack), and
OK.
> - another parser that rejects camelCas
Hi Junio,
On Tue, 23 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > The parser I wrote actually accepts both versions, allowing me to skip
> > the tedious step to convert the camelCased config setting into a
> > lower-case-dashed version to pass to `index-pack` or `unpack-o
Johannes Schindelin writes:
> The parser I wrote actually accepts both versions, allowing me to skip the
> tedious step to convert the camelCased config setting into a
> lower-case-dashed version to pass to `index-pack` or `unpack-objects`,
> only to be parsed by the same parser as `fsck` would u
Junio C Hamano writes:
> I suspect that it would be much better if the configuration
> variables were organized the other way around, e.g.
>
> $ git config fsck.warn missingTagger,someOtherKindOfError
By the way, I think I like this organization is much better than the
other way around, i.
Hi Junio,
On Tue, 23 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> >> > Of course you can say that! ;-) The problem these ugly messages
> >> >> > try to solve is to give the user a hint which setting to change
> >> >> > if they want to override the default behavior, thoug
Johannes Schindelin writes:
>> >> > Of course you can say that! ;-) The problem these ugly messages try to
>> >> > solve is to give the user a hint which setting to change if they want to
>> >> > override the default behavior, though...
>> >>
>> >> Ahh, OK, then dashed form would not work as a c
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Mon, 22 Dec 2014, Junio C Hamano wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> > Of course you can say that! ;-) The problem these ugly messages try to
> >> > solve is to give the user a hint w
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 22 Dec 2014, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > Of course you can say that! ;-) The problem these ugly messages try to
>> > solve is to give the user a hint which setting to change if they want to
>> > override the
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Of course you can say that! ;-) The problem these ugly messages try to
> > solve is to give the user a hint which setting to change if they want to
> > override the default behavior, though...
>
> Ahh, OK,
Johannes Schindelin writes:
> Of course you can say that! ;-) The problem these ugly messages try to
> solve is to give the user a hint which setting to change if they want to
> override the default behavior, though...
Ahh, OK, then dashed form would not work as a configuration variable
names, s
Hi Junio,
On Mon, 22 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Or do you want the error messages to also use camelCased IDs, i.e.
> >
> > warning in tag $tag: missingTaggerEntry: invalid format ...
> >
> > instead of
> >
> > warning in tag $tag: missing-tagger-
Johannes Schindelin writes:
> Or do you want the error messages to also use camelCased IDs, i.e.
>
> warning in tag $tag: missingTaggerEntry: invalid format ...
>
> instead of
>
> warning in tag $tag: missing-tagger-entry: invalid format ...
>
> ? It is easy to do, but looks slightly
Hi Junio,
On Wed, 10 Dec 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > We already have support in `git receive-pack` to deal with some legacy
> > repositories which have non-fatal issues.
> >
> > Let's make `git fsck` itself useful with such repositories, too, by
> > allowing
Johannes Schindelin writes:
> We already have support in `git receive-pack` to deal with some legacy
> repositories which have non-fatal issues.
>
> Let's make `git fsck` itself useful with such repositories, too, by
> allowing users to ignore known issues, or at least demote those issues
> to me
We already have support in `git receive-pack` to deal with some legacy
repositories which have non-fatal issues.
Let's make `git fsck` itself useful with such repositories, too, by
allowing users to ignore known issues, or at least demote those issues
to mere warnings.
Example: `git -c fsck.missi
24 matches
Mail list logo
