"John Dlugosz" <JDlugosz@xxxxxxxxxxxxxxxx> writes:
> I'm working with a group, and using git for source code. I need to
> change a couple files temporarily and just for me. I thought, "that's
> easy", just don't stage them when I check in changes. But, what do I do
> when I pull changes from others? I think it will complain that I have
> unsaved changes. What's the best way to do this?
[jc: Overlong lines wrapped]
This typically happens when a configuration file of some sort that *must*
be different in each work tree is tracked.
"git pull" and "git merge" do not care when you have local changes to
paths *and* the merge does not involve them, and errors out without
touching any files in your tree when the merge needs to touch them. You
can safely deal with your local changes after seeing such an error. This,
and because such a file tend to be modified much less often than the real
contents, means that:
(1) you do not usually have to worry about this issue, and can keep your
small local changes you do not mind losing around, and
(2) when you have to recover, you can easily stash your changes away,
redo the pull and unstash them.
If you want an "I do not have to think" solution, an easiest recipe to
follow would be:
$ git stash
$ git pull
... potentially resolve conflicts and make a merge commit ...
$ git stash pop
But as described above, stash/stash pop are superfluous for most of the
time.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
