Git how to force server changes (overwrite local changes) and vice versa...

[Jim Hargrave]

Sometimes when I pull I get merge conflicts with my own code - very irritating. Normally what I want to do is not merge, but to accept the server version of the files.

If anyone knows of a better way let me know - here's what I did:

http://stackoverflow.com/questions/1125968/force-git-to-overwrite-local-files-on-pull

git fetch --all

git reset --hard origin/master

Now if you have uncommitted changes on your local machine I guess you are stuck doing a merge since the above will overwrite your changes :-(

Is there a way to do the opposite? Tell git to prefer your local changes - like an svn update? 

Jim

[Chase Tingley]

The git merge algorithm is pretty smart about automatically merging as much as possible -- unless you have local changes to the same lines as something that's changed on the server, git can usually sort everything out automatically during a merge/pull.

But it does demand the files be committed in order to perform the merge.  If you don't want to commit your local changes, one possibility is to use "git stash save", which takes all your uncommitted changes and hides them, restoring your tree to the original HEAD state.  Then later (after you pull), you can use "git stash pop" to restore everything you had previously stashed.

Does any of that help?

[Jim Hargrave]

These are actually merge conflicts caused by me working on multiple computers. I need an easy way to do like an svn update that will preserver local changes. Or like the solution below to reset to head on the server.

Jim

[Chase Tingley]

Ah, I see.  When I'm working across multiple machines, I usually do one of two things:

1) Commit frequently and push the commits back, and try not to leave uncommitted work on one or the other if I'm gong to switch machines.  (Or work on separate branches.)  There are ways to clean up the commit history later (for example, when you merge a branch you can "squash" it to a single commit; there are also more involved techniques) if that's a concern.

2) Put the working repo in dropbox, and then share the dropbox.  Then just go back and forth between machines freely, and you'll always have the latest work. 

[Jimbo]

The dropbox idea is brilliant! I hope I have enough storage

Jim

[Jim Hargrave]

DropBox method works great on 3 machines. The only hard part is that on each machine you have to manually de-synchronize the target, bin, classes, deployment directories (all the binary stuff) - otherwise the number of files tends to bog down DropBox. 

Too bad DropBox doesn't have global settings for de-synchronized folders and wildcards - would have made checking hundreds of checkboxes easier.

If you develop on more than one machine this is the only way to go IMHO.

Jim

[Chase Tingley]

Ah, interesting.  I haven't tried it with a project as big as Okapi before, so that's good info about the bin/classes stuff.

Would another possibility (if you're working on non-Windows) be to just symlink those directories to point to somewhere local?  (Although, I don't know how dropbox deals with symlinks...)

[Jim Hargrave]

yep one guy set this up using symlinks - but I was too lazy to try it :-)

Jim

[David Mason]

I sometimes work with a bare repository in dropbox, and work on local clones of it - only commits are shared though so it may not be ideal for this. A bare repository is basically one with no working directory (just has the .git directory), which means you can push to it without having to worry about conflicts. I have some notes at http://dl.dropbox.com/u/1838149/web/git/git.html (work in progress, look under "To make and use a local git repository").

Also note that git stash save can take a quoted string parameter to describe your stash (e.g. git stash save "half way through updating tests for Foo"), and if you don't want a description you can use "git stash" (without "save").

Also for looking at your stashes (you can have lots of them)

• git stash list will show you a list of all your stashes. Note that they can be referred to by their index (e.g. stash@{0} for the top stash)
• git stash drop stash@{X} to discard a stash (they can tend to pile up). If you want to get rid of some changes, stash then drop is a fairly concise way to do so.
• git stash show stash@{X} to view which files are changed in a stash
• git diff stash@{X}~1 stash@{X} to see the actual changes. Whenever you make a stash, the parent state is stored as the stash's parent (which gives stashes a distinctive triangular look in the source tree), and the ~1 means go back one commit to the parent.
• git stash apply stash@{X} to apply the changes for a specific stash (without removing the stash from the list). Note that git stash pop is the equivalent of git stash apply stash@{0} followed by git stash drop stash@{0}
• also try hitting tab, git seems to be pretty good at filling in "stash@{" for me, which can save a lot of key strokes.

-- 

David