Jeff King <peff@xxxxxxxx> writes: > 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.