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

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

[Sergio]

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

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

[Junio C Hamano]

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".

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

[Johannes Sixt]

Junio C Hamano schrieb:
> 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".

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

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

[Junio C Hamano]

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

> Junio C Hamano schrieb:
>> 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".
>
> 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...

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.

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

[Sergio Callegari]

Johannes Sixt wrote:
> Junio C Hamano schrieb:
>   
>> 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".
>>     
>
> 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
>
>   
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

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

[Dmitry Potapov]

On Tue, Mar 09, 2010 at 07:58:11AM +0100, Sergio Callegari wrote:
> 
> I actually did not know about the
> 
> update-index --refresh

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").

> 
> 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.

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

> 
> 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.

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

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

[Jens Lehmann]

Am 08.03.2010 11:46, schrieb Sergio:
> I happen to work with a (possibly somehow unusual) configuration where 2 laptops
> are syncronized via unison (a widely used file syncronizer).

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).