Some information that git diff saves and that git status does not

Hi,

I happen to work with a (possibly somehow unusual) configuration where 2 laptops are syncronized via unison (a widely used file syncronizer).

This means that git worktrees and repos are copied around as they are, rather than transferred through git protocols. The thing may appear weird, but it makes sense, since the two laptops need to carry completely identical stuff all the time (one, say "A", is a lightweight one good for travel, the other one, say "B" is a desktop replacement).

If I work on "A" in worktree "WT", when I then sync the two machines, WT and the associated object store and git data remains unchanged in A and gets updated in B in such a way that git cannot know about it.

As a matter of fact, git copes with all this amazingly well, with the following quirk:

1) The tree appears dirty on B, even if it was not on A before starting the
sync. I guess this is because the index may contain data that does not make
complete sense on B. As a consequence, gitk shows the tree as containing local
changes even if it does not.

2) By running git status, you make git realize that in fact there are no local
changes in the tree.  After a git status, also gitk is happy.

3) When you run git status, to find out that the local tree is in fact clean,
git status needs to do a significant amount of work.  If filters are defined,
git status runs all the filters on all the files that need to be filtered
(revealed by GIT_TRACE). This can take a significant amount of time.

4) Once git has done that, you would expect git status not to need doing the
filter job any longer.  However, if you run git status again and again, git
again and again spends a significant amount of time re-running all the filters.

5) If rather than running git status, you run git diff, git runs the filters as
for git status, however some info now gets saved about this activity.  After a
git diff, git status becomes almost istantaneous, no filters are run any longer.

It would be nice if:

a) git status could save the same info that git diff saves, so after the first git status which needs to take a long time, all the subsequent git status are fast. If I remember properly, this was indeed the behavior before the rewrite of git status; and

b) before saying that you have local changes, gitk could run git status to be truly sure about that.

Would a) and b) be easy and sensible changes? Or conversely, would they have nasty implications and side effects?

Sergio

I didn't fully read what you wrote but after you copy a repository from one to another outside git (be it done with unison or rsync), you should run "update-index --refresh".

Junio C Hamano schrieb:

And the reason for this is that git also looks at the inode numbers, and I guess that unison does not go as far as to preserve them between machines...

-- Hannes

Johannes Sixt <j.sixt@viscovery.net> writes:

True; we used to (and you can still configure git to) check st_dev too but we stopped to doing that by default as it is unstable even in a normal use case (read: no "cp" involved) on some networked file systems.

I wonder how stable inum is on inode-less filesystems (say FAT). I guess it is not usually a problem because carrying repositories on USB keychains is typically done as a sneakernet and with bare repositories.

Johannes Sixt wrote:

Thanks for all the info... and sorry for the too verbose post at the beginning.

I actually did not know about the

update-index --refresh

but now I have the relevant information its name sounds obvious. And I suspected something like inode data entering the game.

As a matter of fact, I was obtaining the same effect with git diff.

What was appearing to me as a quirk is that:

1) If you do not refresh the index, git works perfectly all the same.  
For instance, git status shows the right info. Only it is not that fast 
anymore, since everytime it needs to runs the filters on all the files.
2) git status does not refresh the index, while other commands like git 
diff do.

I was wandering whether git status could refresh the index automatically, at least about those files on which expensive actions, such as running filters had already been performed anyway.

Sergio

Sergio

On Tue, Mar 09, 2010 at 07:58:11AM +0100, Sergio Callegari wrote:

This is a plumbing commmand, which normally users should not use directly, but when you copy your repo by hands or do something like that, you may need it (or use "git diff").

Because "git diff" refreshes the cached stat information internally, in the same way as "update-index --refresh". Junio wrote about this recently: http://article.gmane.org/gmane.comp.version-control.git/141708

Historically, "git status" was just the dry-run mode of "git commit". I do not think that "git commit" should refresh the index. But in Git 1.7, "git status" is no longer the dry-run mode of "git commit", so I see no reason why it does not refresh the cached stat info internally...

Dmitry

Am 08.03.2010 11:46, schrieb Sergio:

Doing the same here between my desktop and my laptop, but i did enable "times=true" in the unsion config file. The reason for that was that i wanted to keep the creation time of my pictures (instead of replacing them with the synchronization time) but it helps syncing git repos quite nicely too (But keep in mind that when you enable "times=true", you'll have to sync all files once again next time because their time stamps seem to have changed).