Hi Pete, Pete Wyckoff wrote: > 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 .". [...] > 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html