Re: index rebuild for cloned repo

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 31, 2010, 18:07 UTC
Message-ID: <20101031180758.GC5683@burratino>
In-Reply-To: <20101031174430.GA30236@arf.padd.com>

Hi Pete,

Pete Wyckoff wrote:

Show 8 quoted lines

>                                                          While
> the data is identical, much of the inode information changes:
> uid, gid, ino, dev, mtime, ctime.
> 
> What is the best way to rewrite .git/index in the clone?  Options
> that work but are slow:
> 
>     git reset --hard HEAD

Not very good for this use case, as you noticed.

>     git update-index --refresh
> 	stat and read all files, 5 min 55 sec

That's better (better yet with -q). The user-facing version is "git add --refresh .".

[...]

Show 9 quoted lines

>     HACKED git update-index --refresh
> 	Just the stat, 13 sec
> 
> The lstat() is required to look up the new inode number.
> 
> The rest of the clone operation takes around 3 min, so
> I'd like to avoid this additional 5+ min of read()s if
> possible.  Is there a way to do so using existing commands?
> Should I add a new option to update-index

Yes, a new option sounds sane.

Show 6 quoted lines

> P.S.  The user-observable problem that occurs if I do not
> rebuild the index is, e.g.:
> 
>     $ git cherry-pick build/top
>     error: Your local changes to 'file.h' would be overwritten by merge.  Aborting.
>     Please, commit your changes or stash them before you can merge.

That's a bug. In general, the "high-level commands (porcelain)" listed in the git manpage (other than gitk) are supposed to hide an un-refreshed index from the user, generally by transparently refreshing the index.

Thanks for reporting.

Hope that helps, Jonathan