2

Update: I think this is related to an issue with the windows git client msysgit. Sorry to trouble you guys. http://code.google.com/p/msysgit/issues/detail?id=379&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary

I'm looking for a way to keep several client boxes in synch with a remote git repo. Forcing updates from the remote repo and abandoning anything that may have changed on the client boxes.

The problem I'm running into is that the client boxes will modify some of the files (installation logs etc.) and gives me a merge nightmare when I need to update them from the remote repo. I've tried several commands to try and reset their local changes (the local changes should just be abandoned), but none seem to be working as advertised (git reset --hard).

I don't want to do a clone and then delete the .git dir on these boxes as I'd prefer them to only update with changes rather than pulling down the entire repo every time.

Any ideas?

CharlesB
  • 86,532
  • 28
  • 194
  • 218
Dave Rapin
  • 1,471
  • 14
  • 18
  • You're saying `git reset --hard` doesn't revert your local tree back to the latest revision (`HEAD`)? – ezod Feb 18 '10 at 17:49
  • Is the client modifying the permission of the files, as well as their content? If so, 'git reset' may not overwrite them, depending on which platform you are running on. – Gareth Stockwell Feb 18 '10 at 17:54
  • yeah I still see a bunch of modified files (via git status) after running git reset --hard. These client machines are windows boxes and I'm using msysgit (latest). – Dave Rapin Feb 18 '10 at 18:00
  • @Dave: I see you've (probably) found the problem, which is a msysgit bug. My I suggest you use Git under Cygwin instead? It actually runs quite fast for most operations these days, and is the "official" way to run Git on Windows. It should also go without saying that this bug doesn't exist in Cygwin's Git. – Dan Moulding Feb 18 '10 at 18:14
  • @Dan: I'm rarely on a windows machine, it's just a requirement for this specific project so I went with what should have been a quick solution to keep our test clients up to date with our changes. I'm not sure it's a msysgit issue though, seems to be more of a git + windows timestamp issue. I'll either give a cygwin or rsync solution a go instead. Ahh windows, everytime I run into it, it reminds me why I avoided it in the first place. – Dave Rapin Feb 18 '10 at 18:27
  • I'm using msysgit 1.6.5.1 without any problems. In addition to using git to store the source code for the project I'm working on, we also keep our build environments in a separate repo of ~1.2MB. (We're x-compiling for an embedded platform). When we want to clean the environment, we do 'git reset' and 'git clean', which works fine. So, at least the version of msysgit that we are using seems bug-free in this regard. – Gareth Stockwell Feb 18 '10 at 23:38

5 Answers5

5

I'm assuming you have a good reason for using Git for this, rather than rsync.

This is how I'd do it (on the Clients):

git fetch origin
git reset --hard origin/master
git clean -dfx

Note that you need to reset to origin/master rather than HEAD because the local HEAD doesn't include the origin's newest commits (yet).

Dan Moulding
  • 211,373
  • 23
  • 97
  • 98
1

It sounds like you are looking for rsync, not git. Can you explain a bit more why you would want to use a full revision control system to "merely" keep some files in sync?

Gerco Dries
  • 6,682
  • 1
  • 26
  • 35
  • Maybe I didn't explain it well. It's not that I want to synch only certain files, it's that I want the synch to be 1-way only. Master and slaves. – Dave Rapin Feb 18 '10 at 17:50
  • @Dave: Gerco's suggestion sounds like a good one - rsync can be used for 1-way syncing. However it will not, AFAIK, remove files which are newly created on the client but do not exist in the master copy. For this, git gives you 'git clean -fdx'. – Gareth Stockwell Feb 18 '10 at 17:52
  • @gareth: rsync has the `--delete` option to delete files that exist in the destination, but not the source. I think, unless he *needs* Git for some reason not specified, rsync would work just fine. – Dan Moulding Feb 18 '10 at 18:01
1

The following two commands should reset the client's working tree to a clean state, i.e. identical to how it was following the preceding git clone:

git reset --hard HEAD

This will undo any modifications made to files which are tracked (i.e. which exist in the repo).

git clean -fdx

This will remove any files which have been newly created by the client, i.e. which are not tracked by git.

Gareth Stockwell
  • 3,112
  • 18
  • 23
  • unfortunately after running both these commands then a git status I'm still seeing several *modified* not yet committed files... My client machines are windows boxes so maybe it's an issue with the msysgit client. – Dave Rapin Feb 18 '10 at 17:57
1

It's strange, git reset --hard should remove any change made in the local repositories.

you can try git stash && git pull, it just move the changes in some kind of temporay branch (git stash clear to remove any trace of the changes)

if that does not work, you can try this (assuming you are on the master branch and that the tmp branch does not exists)

git checkout origin/master -b tmp
git branch -D master
git branch -m master
Mathieu
  • 5,495
  • 2
  • 31
  • 48
  • I've tried the stash already and no worky. I know it sounds wierd, but I've been using git for a while now and have only just run into this issue now. Branching it sounds like it should work, I'll give that a whirl. – Dave Rapin Feb 18 '10 at 18:02
0

For the record, this original issue seems to be limited to msysgit 1.6.5.1 (issue 379), as mentioned by the OP.

However, that same issue mentions in 2012 a similar problem with other causes:

For the record, I have this issue with autocrlf = false.

Performing a git reset --hard still leaves uncommitted changes relating to file permissions:

$ git reset --hard
HEAD is now at 088c702 BranchA

$ git diff

diff --git a/path/to/file b/path/to/file
old mode 100755
new mode 100644
...

This is in relation with "Removing files saying “old mode 100755 new mode 100644” from unstaged changes in git"

I've discovered that for some reason, core.filemode was set to true on repository level (I didn't set it myself):

$ cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true

So: git config core.filemode false is recommended.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250