Re: Proposed git mv behavioral change

[Jeff King <peff@peff.net>]

On Sat, Oct 20, 2007 at 01:55:48AM -0400, Ari Entlich wrote:

> Well, I also want to move the working directory file so that the index
> and the working directory still match up and so that their differences
> are preserved. Therefore, --cached isn't quite right (see Shawn's
> messages and my response to them).

Ah, OK. I understand now. So what you would want could be accomplished
with something like:

  mv A B
  (git-ls-files -s | sed s/A$/B/;
   echo 0 0000000000000000000000000000000000000000	A) \
  | git-update-index --index-info

IOW:
  1. move working tree A to B
  2. create staged entry B, same as staged entry A
  3. remove staged entry A

> Hmm, that's an interesting point. Are you talking about situations in
> which your changes after (1) leave the program in an uncompilable state?

No, I meant more that the state you have staged will never have actually
existed in your working tree, so you could not possibly have tested it.
However, it may be that the changes you are trying to avoid staging are
trivial, and you're willing to accept that. And git shouldn't stand in
your way.

And it sounds like you don't necessarily want to make a _commit_ out of
this, you just want to keep working and not have git-mv munge your
staged state.

> I don't really see why you're analyzing the situations in which this
> would be used. I think it should be obvious from my descriptions of my

Because I was having trouble understanding what Michael was trying to
accomplish with his "here are two methods, and one is better" since they
seemed to do different things. But that is perhaps my fault for joining
the thread in the middle. I may have simply caused more confusion by
getting involved. :)

Now I think I understand exactly what you're trying to accomplish,
and I agree that it makes sense.  Shawn is right that "git-mv --cached"
doesn't do what you want, since to be consistent with other tools it
wouldn't touch the working tree (though I wonder if you would be
satisfied with "git-mv --cached A B; mv A B"). I think at this point the
best way forward is to produce a patch and try to solicit comments (in
particular, which behaviors should be supported (current, --cached, or
what you are proposing) and which should be the default).

> But... that's not even the point I was going to make. I think the
> questions you should be asking are things like "Does this fit with the
> overall architecture?", "Does this or doesn't this provide power and
> flexibility to the user?", etc. Is git being made for "the 80%" that use

There seems to be a strong sentiment among the various gits that you
shouldn't build in flexibility for the sake of flexibility if there's no
good use for it. I tend to be less of that sentiment than some others
here, but I think when proposing a feature it is still worth saying "and
here's why it's useful."

> Sorry if anything I've said here sounded confrontational; that was not
> not my intent at all. I'm just raising some points I think are
> important. I don't want any flame wars...

I think you stated your position fine. And we've had enough flame wars
around here lately to last us a while.

-Peff