git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergio <sergio.callegari@gmail.com>
To: git@vger.kernel.org
Subject: Some information that git diff saves and that git status does not
Date: Mon, 8 Mar 2010 10:46:51 +0000 (UTC)	[thread overview]
Message-ID: <loom.20100308T111146-322@post.gmane.org> (raw)

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

             reply	other threads:[~2010-03-08 10:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-08 10:46 Sergio [this message]
2010-03-08 21:38 ` Some information that git diff saves and that git status does not Junio C Hamano
2010-03-09  6:35   ` Johannes Sixt
2010-03-09  6:56     ` Junio C Hamano
2010-03-09  6:58     ` Sergio Callegari
2010-03-09  8:20       ` Dmitry Potapov
2010-03-08 21:52 ` Jens Lehmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20100308T111146-322@post.gmane.org \
    --to=sergio.callegari@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).