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
18 matches
Mail list logo
