Re: Proposed git mv behavioral change

From: Jeff King <peff@peff.net>
Date: Oct 19, 2007, 03:47 UTC
Message-ID: <20071019034704.GB11095@coredump.intra.peff.net>
In-Reply-To: <93BF5798-F1C3-48EE-8233-A0F111BF8138@MIT.EDU>

On Thu, Oct 18, 2007 at 11:40:47PM -0400, Michael Witten wrote:

Show 15 quoted lines

> Anyway, succinctly:
>
>> What you want to happen is the following:
>> 	
>> 	git show HEAD:A.txt > path/B.txt
>> 	git add path/B.txt
>> 	mv A.txt B.txt
>> 	git rm A.txt
>
> Better:
>
>>  	mv A.txt path/B.txt
>> 	Point the index entry for A.txt to path/B.txt
>
> I hope that's right.

Hrm. So you _do_ want to do an index-only move of A to B, in which case the suggestion of a "git-mv --cached" seems sensible. Though I'm curious why you want that. The only workflow I can think of is:

  1. you modify a.c
  2. your boss comes in and tells you to make some unrelated change,
     which involves moving a.c to b.c
  3. You don't want to commit your changes, so you git-mv in the index
     only without involving your dirty working tree file.
  4. You commit the index (which doesn't have your changes from (1)

I think that is sort of a bogus workflow, though, since you will never have actually compiled or tested the changes in (2). You are much better to git-stash your current work, fulfill the boss's request, then unstash.

-Peff