From: "Dirk Süsserott" <newsletter@dirk.my1.cc>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Ramkumar Ramachandra <artagnon@gmail.com>
Subject: Re: Best way to check for a "dirty" working tree?
Date: Tue, 14 Jun 2011 15:28:07 +0200 [thread overview]
Message-ID: <4DF761E7.8040707@dirk.my1.cc> (raw)
In-Reply-To: <20110613222225.GA14446@elie>
Hi Jonathan,
Am 14.06.2011 00:22 schrieb Jonathan Nieder:
> Hi Dirk,
>
> Dirk Süsserott wrote:
>
>> I have a script which moves data from somewhere to my local repo and
>> then checks it in, like so:
>>
>> -----------
>> mv /tmp/foo.bar .
>> git commit -am "Updated foo.bar at $timestamp"
>> -----------
>>
>> However, before overwriting "foo.bar" in my working directory, I'd like
>> to check whether my working tree is dirty (at least "foo.bar").
>
> Interesting example. Sensible, as long as you limit the commit to
> foo.bar (i.e., "git commit -m ... --only foo.bar")!
Uhh, nice hint. I didn't know that git-commit accepts a path, too.
That's safer. However, in my particular case the working tree is either
clean or exactly the file in question has changed. If sth. else changes
(e.g. my commit-script) I do that in a separate "transaction".
> Now, a word of warning. One aspect of this "do not second-guess the
> caller" behavior is that low-level commands like "git diff-index"
> blindly trust stat() information in the index, rather than going to
> re-read a seemingly modified file and updating the index if the
> content is not changed. You can see this by running "touch foo.bar";
> "git diff-index" will report the file as changed, until you use "git
> update-index" to refresh the stat information:
>
> git update-index --refresh --unmerged -q >/dev/null || :
> if ! git diff-index --quiet HEAD -- foo.bar; then
> dirty=1
> fi
>
> Alas, this doesn't seem to be documented anywhere (except for the
> gitcore-tutorial(7))! It ought to be.
Hmm, it MUST be documented somewhere, because I have several scripts
that use "update-index --refresh" to get rid of what I call "phantom
changes": sometimes I transfer (scp) files from a remote machine to the
local tree. The set of files is already known to Git, so my first guess
was that Gitk would only show the "real" diff, but it actually showed
*all* transferred files as changed. After running "git status" Gitk does
it right and shows only content's diff. Surprisingly, "git status" seems
to be a read/write operation and does "update-index --refresh" in the
background. After some research I learned about "update-index --refresh"
and use it frequently for scp'ed files.
Unfortunately, I cannot remember *where* I learned about it.
> Hope that helps,
> Jonathan
That helped a lot. Thank you,
Dirk
prev parent reply other threads:[~2011-06-14 13:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-11 14:54 Best way to check for a "dirty" working tree? Dirk Süsserott
2011-06-12 12:23 ` Ramkumar Ramachandra
2011-06-13 22:22 ` Jonathan Nieder
2011-06-14 13:28 ` Dirk Süsserott [this message]
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=4DF761E7.8040707@dirk.my1.cc \
--to=newsletter@dirk.my1.cc \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
/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).