On 13/07/18 20:46, Jeff King wrote:
> On Fri, Jul 13, 2018 at 03:41:19PM -0400, Jeff King wrote:
>
>>> not ok 18 - push rejects corrupt .gitmodules (policy)
>>> #
>>> # rm -rf dst.git &&
>>> # git init --bare dst.git &&
>>> # git -C dst.git config transfer.fsc
On Fri, Jul 13, 2018 at 03:41:19PM -0400, Jeff King wrote:
> > not ok 18 - push rejects corrupt .gitmodules (policy)
> > #
> > # rm -rf dst.git &&
> > # git init --bare dst.git &&
> > # git -C dst.git config transfer.fsckObjects true &&
> > # git -C dst
On Fri, Jul 13, 2018 at 08:37:46PM +0100, Ramsay Jones wrote:
> OK, so I found some time to test this tonight. It is not good
> news (assuming that I haven't messed up the testing, of course). :(
I think you may have. :)
> not ok 18 - push rejects corrupt .gitmodules (policy)
> #
> #
On Wed, Jul 11, 2018 at 08:31:34PM +0100, Ramsay Jones wrote:
> >> Simply, I have found (for many different reasons) that, if there
> >> is no good reason to execute some code, it is _far_ better to not
> >> do so! ;-)
> >
> > Heh. I also agree with that as a guiding principle. But I _also_ like
On 11/07/18 20:31, Ramsay Jones wrote:
> On 07/07/18 02:32, Jeff King wrote:
[snip]
>> Hmm, we seem to have "info" these days, so maybe that would do what I
>> want. I.e., I wonder if the patch below does everything we'd want. It's
>> late here and I probably won't get back to this until Monday,
On 07/07/18 02:32, Jeff King wrote:
[snip]
>> I'm not interested in any savings - it would have to be a pretty
>> wacky repo for there to be much in the way of savings!
>>
>> Simply, I have found (for many different reasons) that, if there
>> is no good reason to execute some code, it is _far_ b
On Wed, Jul 04, 2018 at 01:12:40AM +0100, Ramsay Jones wrote:
> > True that we don't even bother doing the parsing with your patch. But I
> > think I talked myself out of that part being a significant savings
> > elsewhere.
>
> [Sorry for the late reply - watching football again!]
>
> I'm not in
On 03/07/18 15:34, Jeff King wrote:
> On Fri, Jun 29, 2018 at 02:10:59AM +0100, Ramsay Jones wrote:
>
>> On 28/06/18 23:03, Jeff King wrote:
>>> On Thu, Jun 28, 2018 at 07:53:27PM +0100, Ramsay Jones wrote:
>> [snip]
>>> Yes, it can go in quickly. But I'd prefer not to keep it in the long
>>> t
On Fri, Jun 29, 2018 at 02:10:59AM +0100, Ramsay Jones wrote:
> On 28/06/18 23:03, Jeff King wrote:
> > On Thu, Jun 28, 2018 at 07:53:27PM +0100, Ramsay Jones wrote:
> [snip]
> > Yes, it can go in quickly. But I'd prefer not to keep it in the long
> > term if it's literally doing nothing.
>
> Hmm
On 28/06/18 23:03, Jeff King wrote:
> On Thu, Jun 28, 2018 at 07:53:27PM +0100, Ramsay Jones wrote:
[snip]
> Yes, it can go in quickly. But I'd prefer not to keep it in the long
> term if it's literally doing nothing.
Hmm, I don't think you can say its doing nothing!
"Yeah, this solution s
On Thu, Jun 28, 2018 at 07:53:27PM +0100, Ramsay Jones wrote:
> > Yes, though I don't think it's too bad. We already have a "die_on_error"
> > flag in the config code. I think it just needs to become a tristate:
> > die/error/silent (and probably get passed in via config_options, since I
> > think
On 28/06/18 18:45, Jeff King wrote:
> On Thu, Jun 28, 2018 at 05:56:18PM +0100, Ramsay Jones wrote:
[snip]
>>> One thing we could do is turn the parse failure into a noop. The main
>>> point of the check is to protect people against the malicious
>>> .gitmodules bug. If the file can't be parsed,
On Thu, Jun 28, 2018 at 05:56:18PM +0100, Ramsay Jones wrote:
> > Yeah, this solution seems sensible. Given that we would never report any
> > error for that blob, there is no point in even looking at it. I wonder
> > if we ought to do the same for other types, too. Is there any point in
> > openi
On Thu, Jun 28, 2018 at 09:39:39AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yeah, this solution seems sensible. Given that we would never report any
> > error for that blob, there is no point in even looking at it. I wonder
> > if we ought to do the same for other types, too. Is th
Ramsay Jones writes:
> Junio, do you want me to address the above 'rejected push'
> issue in this patch, or with a follow-up patch? (It should
> be a pretty rare problem - famous last words!)
If you feel the need to say "famous last words", it is an indication
that it is better done as a follow-
On 28/06/18 12:49, Jeff King wrote:
> On Wed, Jun 27, 2018 at 07:39:53PM +0100, Ramsay Jones wrote:
>
>> Since commit ed8b10f631 ("fsck: check .gitmodules content", 2018-05-02),
>> fsck will issue an error message for '.gitmodules' content that cannot
>> be parsed correctly. This is the case, e
Jeff King writes:
> Yeah, this solution seems sensible. Given that we would never report any
> error for that blob, there is no point in even looking at it. I wonder
> if we ought to do the same for other types, too. Is there any point in
> opening a tree that is in the skiplist?
Suppose the tre
On Wed, Jun 27, 2018 at 07:39:53PM +0100, Ramsay Jones wrote:
> Since commit ed8b10f631 ("fsck: check .gitmodules content", 2018-05-02),
> fsck will issue an error message for '.gitmodules' content that cannot
> be parsed correctly. This is the case, even when the corresponding blob
> object has b
Since commit ed8b10f631 ("fsck: check .gitmodules content", 2018-05-02),
fsck will issue an error message for '.gitmodules' content that cannot
be parsed correctly. This is the case, even when the corresponding blob
object has been included on the skiplist. For example, using the cgit
repository,
19 matches
Mail list logo
