On Mon, Jun 5, 2017 at 4:02 AM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote:
>>> Ævar Arnfjörð Bjarmason writes:
>>>
> My feeling exactly. Diagnosing and failing upfront saying "well you
> made a copy but it is not suitable
Jeff King writes:
> I don't really mind addressing this one case that much. I'm not sure
> that we want to accrue a pile of band-aids here that causes a
> maintenance burden and doesn't really solve the problem completely. One
> way to do that is to say no to the first band-aid.
Yup, that was w
Christian Couder writes:
> On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
My feeling exactly. Diagnosing and failing upfront saying "well you
made a copy but it is not suitable for testing" sounds more sensible
at lesat to me.
>>>
>>>
On Sun, Jun 04, 2017 at 11:04:50AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > But I think a more compelling case is that there may be an ongoing
> > operation in the original repo (e.g., say you are in the middle of
> > writing a commit message) when we do a blind copy of the filesys
On Sun, Jun 04, 2017 at 09:00:28AM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> >> My feeling exactly. Diagnosing and failing upfront saying "well you
> >> made a copy but it is not suitable for testing" sounds more sensible
> >> at lesat to me.
> >
> > This change makes t
On Sun, Jun 04, 2017 at 09:55:15AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Is a local clone really much slower these days? Wouldn't it is use
> > hard links too?
> > By the way the many properties that are preserved might not be worth
> > preserving as they could make results depend a lot on the
On Sun, Jun 4, 2017 at 9:37 AM, Christian Couder
wrote:
> On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
My feeling exactly. Diagnosing and failing upfront saying "well you
made a copy but it is not suitable for testing" sounds more sensibl
On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>>> My feeling exactly. Diagnosing and failing upfront saying "well you
>>> made a copy but it is not suitable for testing" sounds more sensible
>>> at lesat to me.
>>
>> This change makes the repo suitable
Jeff King writes:
> But I think a more compelling case is that there may be an ongoing
> operation in the original repo (e.g., say you are in the middle of
> writing a commit message) when we do a blind copy of the filesystem
> contents. You might racily pick up a lockfile.
>
> Should we find and
Junio C Hamano writes:
> Perhaps run "fsck" and "status" immediately after copying to make
> sure they succeed, or something like that?
Hmph, this is me half-being silly, as this "copying an existing one"
is meant for testing Git with a large repository, and having to run
fsck may add meaningful
Ævar Arnfjörð Bjarmason writes:
>> My feeling exactly. Diagnosing and failing upfront saying "well you
>> made a copy but it is not suitable for testing" sounds more sensible
>> at lesat to me.
>
> This change makes the repo suitable for testing when it wasn't before.
Perhaps "not suitable" was
On Sat, Jun 3, 2017 at 1:52 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> But I think a more compelling case is that there may be an ongoing
>> operation in the original repo (e.g., say you are in the middle of
>> writing a commit message) when we do a blind copy of the filesystem
>> content
Jeff King writes:
> But I think a more compelling case is that there may be an ongoing
> operation in the original repo (e.g., say you are in the middle of
> writing a commit message) when we do a blind copy of the filesystem
> contents. You might racily pick up a lockfile.
>
> Should we find and
On Fri, Jun 2, 2017 at 8:45 PM, Jeff King wrote:
> On Fri, Jun 02, 2017 at 10:33:30AM +, Ævar Arnfjörð Bjarmason wrote:
>
>> When the tested repo has an index.lock file it should be removed. This
>> file may be present if e.g. git-status previously crashed in that
>> repo, and it will make a l
On Fri, Jun 02, 2017 at 10:33:30AM +, Ævar Arnfjörð Bjarmason wrote:
> When the tested repo has an index.lock file it should be removed. This
> file may be present if e.g. git-status previously crashed in that
> repo, and it will make a lot of git commands fail. Let's try harder
> and remove t
15 matches
Mail list logo
