Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 25, 2017, 18:16 UTC
Message-ID: <xmqq4m0nc8dz.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170125173958.pg546a6w33dirp5k@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

> On Wed, Jan 25, 2017 at 06:01:11PM +0100, Johannes Schindelin wrote:
>
>> > Looks like "mv" prompts and then fails to move the file (so we get the
>> > dangling blob for the source blob, and fsck doesn't report failure
>> > because we didn't actually corrupt the destination blob).
>> 
>> IIRC I had similar problems years ago, on a machine where the
>> administrator defined mandatory aliases, including mv="mv -i".
>
> Yeah, that was my first thought, too. But this should be a
> non-interactive shell, which would generally avoid loading rc files. I
> think there are some exceptions, though (e.g., setting ENV or BASH_ENV).
> Loading aliases like "mv -i" for non-interactive shells seems somewhat
> insane to me.

It does to me, too.

> But whatever the cause, I think the workaround I posted is
> easy enough to do.

Or spelling it explicitly as "/bin/mv" (forgetting systems that does not have it in /bin but as /usr/bin/mv) would also defeat alias if that were the cause.

One downside of working it around like your patch does, or spelling it out as "/bin/mv", is that we'd need to worry about all the uses of "mv" in our scripts. If this were _only_ happening in the Travis environment, I'd prefer to see why it happens only there and fix that instead.