Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Perhaps something like this (not even compile tested as both of my
>> worktrees are doing something else)
>
> This time with a few additional tests.
>
> -- >8 --
> Subject: [PATCH] fsck: exit with non-zero when problems are found
Seems st
On Thu, Sep 24, 2015 at 12:44 AM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> Remove the error reporting variable to make the code easier to port
>> over to using ref-filter APIs.
>>
>> This also removes the error from being displayed. As branch.c will use
>> ref-filter APIs in the followi
On Thu, Sep 24, 2015 at 12:27 AM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> Remove the error reporting variable to make the code easier to port
>> over to using ref-filter APIs.
>>
>> This also removes the error from being displayed. As branch.c will use
>> ref-filter APIs in the following
Matthieu Moy writes:
> To be sure, I tried:
>
> echo ee0f5eeeae36cd1b5a346a1e2ae5c8cb841cd5da > .git/refs/heads/broken
>
> where the sha1 is the one of a blob.
> ...
After doing (something like) the above, running "git push --mirror"
to various Git repositories shows their slightly different
b
Junio C Hamano writes:
> Perhaps something like this (not even compile tested as both of my
> worktrees are doing something else)
This time with a few additional tests.
-- >8 --
Subject: [PATCH] fsck: exit with non-zero when problems are found
After finding some problems (e.g. a ref refs/h
Junio C Hamano writes:
>> BTW, this looks like an fsck bug:
>>
>> $ git fsck --strict
>> Checking object directories: 100% (256/256), done.
>> error: refs/heads/broken: not a commit
>> $ echo $?
>> 0
>
> Interesting. Perhaps leave it as a MicroProject for GSoC next year?
> ;-)
Perhaps something
Matthieu Moy writes:
> More precisely: if we find such a branch ref and we're used with an
> option that requires us to lookup the commit, then we report it as an
> error.
> ...
> So I agree with Junio that the commit message is not sufficient: there
> is a behavioral change. I'm OK with it, but
Junio C Hamano writes:
> Karthik Nayak writes:
>
>> Remove the error reporting variable to make the code easier to port
>> over to using ref-filter APIs.
>>
>> This also removes the error from being displayed. As branch.c will use
>> ref-filter APIs in the following patches, the error checking b
Karthik Nayak writes:
> Remove the error reporting variable to make the code easier to port
> over to using ref-filter APIs.
>
> This also removes the error from being displayed. As branch.c will use
> ref-filter APIs in the following patches, the error checking becomes
> redundant with the error
Karthik Nayak writes:
> Remove the error reporting variable to make the code easier to port
> over to using ref-filter APIs.
>
> This also removes the error from being displayed. As branch.c will use
> ref-filter APIs in the following patches, the error checking becomes
> redundant with the error
Remove the error reporting variable to make the code easier to port
over to using ref-filter APIs.
This also removes the error from being displayed. As branch.c will use
ref-filter APIs in the following patches, the error checking becomes
redundant with the error reporting system found in the ref-
11 matches
Mail list logo