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

Jeff King [off-list ref] writes:

On Wed, Jan 25, 2017 at 06:01:11PM +0100, Johannes Schindelin wrote:

quoted

quoted

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.

On Wed, Jan 25, 2017 at 10:16:40AM -0800, Junio C Hamano wrote:

quoted

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.

Yes, but I think it's less tricky and unportable to write "mv -f" than
"/bin/mv". So even if it _is_ a funny alias thing, I think my patch is
the right fix.

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.

I would be curious to know whether it is a funny thing in the Travis
environment, or if some version of macOS "mv" really is that braindead
(and it is just the case that Travis has that version and Lars's
computer doesn't). I just didn't want to waste anybody's time digging
into it if it won't affect our patch.

I guess the way to dig would be to add a test that looks at the output
of "type mv" or something, push it to a Travis-hooked branch, and then
wait for the output

-Peff