From: Jeff King <peff@peff.net>
To: "Edward Z. Yang" <edwardzyang@thewritingpot.com>
Cc: git@vger.kernel.org
Subject: Re: git reset --hard w/o touching every file
Date: Sun, 2 Nov 2008 01:52:12 -0400 [thread overview]
Message-ID: <20081102055212.GG5261@coredump.intra.peff.net> (raw)
In-Reply-To: <gejanr$os$1@ger.gmane.org>
On Sun, Nov 02, 2008 at 12:36:09AM -0400, Edward Z. Yang wrote:
> I'm using a script to automatically update a website with the contents
> of a Git repository at a specified interval. While I could use git pull,
> I've been told that it's safer to do a git fetch, and then a git reset
> --hard remotes/master, because the former could trigger a merge and on a
> live website that is NOT desirable.
Well, there will never be a merge if you aren't making local changes
(and your upstream is not doing silly things like rewinding the history of
what it gives you). But if you aren't making local changes, then doing a
reset is "safe" in the sense that you will have nothing to throw away.
> Unfortunately, since Git touches all files on a reset --hard, it's
> causing problems with the smart cache system, which checks whether or
> not the cache file is older than the source file, and regenerating if
> it is.
Ah, OK. I see what you want.
Git usually tries very hard not to touch files that don't need to be
touched. So that sounds like a bug. However, I can't reproduce it with
this test case:
mkdir repo && cd repo && git init &&
touch a b && git add a b && git commit -m added &&
echo changes >a && git commit -a -m 'changed a' &&
touch -d 1979-10-12 a b && echo before reset && ls -l a b &&
git update-index --refresh &&
git reset --hard HEAD^ && echo after reset && ls -l a b
I end up with:
before reset
-rw-r--r-- 1 peff peff 8 1979-10-12 00:00 a
-rw-r--r-- 1 peff peff 0 1979-10-12 00:00 b
HEAD is now at d7fd84e added
after reset
-rw-r--r-- 1 peff peff 0 2008-11-02 01:46 a
-rw-r--r-- 1 peff peff 0 1979-10-12 00:00 b
which makes sense. The only tricky thing is the "update-index --refresh"
call, which basically tells git "update your cache with the new mtime
value", which is necessary because of the contrived use of "touch". But
if you are manipulating these files only through "git reset", it should
Just Work.
-Peff
prev parent reply other threads:[~2008-11-02 5:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-01 4:48 git reset --hard w/o touching every file Edward Z. Yang
2008-11-01 11:05 ` Pierre Habouzit
2008-11-01 20:03 ` Edward Z. Yang
2008-11-02 3:33 ` Jeff King
2008-11-02 4:36 ` Edward Z. Yang
2008-11-02 5:52 ` Jeff King [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=20081102055212.GG5261@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=edwardzyang@thewritingpot.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