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

From: Jeff King <peff@peff.net>
Date: Jan 25, 2017, 18:39 UTC
Message-ID: <20170125183924.6yclcjl4ggcu42yp@sigill.intra.peff.net>
In-Reply-To: <xmqq4m0nc8dz.fsf@gitster.mtv.corp.google.com>

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

Show 6 quoted lines

> > 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.

Show 5 quoted lines

> 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