Re: Proposed git mv behavioral change

From: Shawn O. Pearce <spearce@spearce.org>
Date: Oct 20, 2007, 06:30 UTC
Message-ID: <20071020063014.GU14735@spearce.org>
In-Reply-To: <1192859758.13347.148.camel@g4mdd.entnet>

Ari Entlich <lmage11@twcny.rr.com> wrote:

Show 8 quoted lines

> On Thu, 2007-10-18 at 21:54 -0400, Shawn O. Pearce wrote:
> > --index is used in Git for places were we update *both* the index
> > and the working directory (git-apply --index). So actually I should
> > have suggested "git-mv --index".  Whoops.
> 
> Alright then, I don't know about that particular convention. If this
> behavior can't be made default, git mv --index should activate it? I
> there anything else that might be more descriptive?

That's always the hard part. I actually think the current behavior should be called --index as it does not only the working tree update but also stages the whole file into the index, which is what git-apply --index does.

What about just -u for "keep unstaged"?

> Might it be possible to simply get the struct cache_entry for the file
> which we want to rename, change its name property (would this involve
> xreallocing it?), and change the ce_namelen field of ce_flags?

Yes.

> In any case, I think the ce_flags would need to be changed to reflect
> the new name length. Also, it seems that the old ce_mtime, ce_dev,
> ce_ino, ce_uid, ce_gid, and ce_size could be used too... ce_ctime would
> need to be updated...

Correct. The ce_size shouldn't change as a result of the rename but the other properties of a struct stat may. I'd like to think that ce_uid and ce_gid wouldn't change as a result of a rename but there's probably some bastard filesystem somewhere that that won't hold true.

Just call fill_stat_cache_info() on your xrealloc'd entry and pass it a stat buffer for the file after the rename and you should be covered here.

Show 7 quoted lines

> > I'm sure Junio could probably give you a better starting point
> > than I can, as he's more familiar with this sort of code, but that
> > should still get you looking in the right direction and maybe get
> > a working implementation together that you can share for discussion.
> 
> Yeah, I'd appreciate any help I can get. The people on #git were
> invoking the "the code is the documentation" ideology. :)

It really is in this case. You are talking about hacking on Git itself. For the most part we believe in "the code is the documentation" for the guts as otherwise the documentation gets out of sync with the code when the code changes. User level docs are different as the user interface needs to stay stable.

> So... Ping Junio...? I actually haven't seen any messages from him since
> I subscribed to this list (I've only gotten about 300 messages so far,
> but I'd expect to see a lot from him as he's the maintainer...). Is he
> away at the moment or something?

Yes. We run like 100 messages a day so I guess you've only joined in the past few days. Welcome to the list. :-)

Junio has been away for about 2 weeks now. He's basically off on leave as he needed some time to take care of some things. I'm filling in for him until he returns.

-- 
Shawn.