git reset --hard w/o touching every file

git reset --hard w/o touching every file

[Edward Z. Yang]

I was wondering if there was any way to run `git reset --hard $revlike`,
or a command with the same effect, without having Git touch every file?

Cheers,
Edward

Re: git reset --hard w/o touching every file

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

On Sat, Nov 01, 2008 at 04:48:38AM +0000, Edward Z. Yang wrote:
> I was wondering if there was any way to run `git reset --hard $revlike`,
> or a command with the same effect, without having Git touch every file?

git checkout HEAD -- <list of the files>

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git reset --hard w/o touching every file

[Edward Z. Yang]

Pierre Habouzit wrote:
> git checkout HEAD -- <list of the files>

What if I do not know a priori which files *do* need to be updated? Is
there a command that I can get this information from? Also, I may not
necessarily be checking out HEAD.

Re: git reset --hard w/o touching every file

[Jeff King]

On Sat, Nov 01, 2008 at 04:03:50PM -0400, Edward Z. Yang wrote:

> Pierre Habouzit wrote:
> > git checkout HEAD -- <list of the files>
> 
> What if I do not know a priori which files *do* need to be updated? Is
> there a command that I can get this information from? Also, I may not

Sorry, I don't quite understand. You want to check out some subset of
files, but you don't know which subset?

Try "git status" or "git diff" to look at which files have changes?

Or maybe we didn't understand your original question.

> necessarily be checking out HEAD.

Doing

  git checkout v1.5 -- <list of files>

or using any other ref will work just fine.

-Peff

Re: git reset --hard w/o touching every file

[Edward Z. Yang]

Jeff King wrote:
> Sorry, I don't quite understand. You want to check out some subset of
> files, but you don't know which subset?

Yeah, I should elaborate a little.

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.

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.

Cheers,
Edward

Re: git reset --hard w/o touching every file

[Jeff King]

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