Is it safe to "git pull" when my working tree and/or index is dirty?

Question

Say I have a git repo whose working tree and/or index is "dirty" (i.e. I have local modifications that have not yet been committed or stashed) and I'm tempted to do a "git pull" without first committing or stashing. (Alternatively, say I'm introducing a new team member to git and they are tempted to run "git pull" when their local repo is "dirty".) I'm wondering how safe it is to do a "git pull" in this case. If it's unsafe, what's the worst thing that can happen? Does it matter if I'm pulling from a trusted vs untrusted source?

My investigation so far suggests a confusing range of ideas on what I'd assumed would be a fairly straightforward question.

To start with, the git-stash manpage makes it sound like git pull is pretty safe, and will abort if you're in a situation where something might go wrong:

   Pulling into a dirty tree
       When you are in the middle of something, you learn that there are
       upstream changes that are possibly relevant to what you are doing.
       When your local changes do not conflict with the changes in the
       upstream, a simple git pull will let you move forward.

       However, there are cases in which your local changes do conflict
       with the upstream changes, and git pull refuses to overwrite your
       changes. In such a case, you can stash your changes away, perform a
       pull, and then unstash, like this...

This actually seems to be what happens too, in my simple tests so far.

Also perhaps implying that "git pull" is pretty safe, the Git Extensions toolbar for Visual Studio has a prominent pull button that does not do a check for dirtiness before shelling out to "git pull". (If I were designing a Visual Studio toolbar, I would try to avoid making it particularly easy to shoot yourself in the foot.)

The git-pull manpage doesn't make my "git pull" sound dangerous, though it suggests it's not a best practice:

   If any of the remote changes overlap with local uncommitted changes,
   the merge will be automatically cancelled and the work tree untouched.
   It is generally best to get any local changes in working order before
   pulling or stash them away with git-stash(1).

But then you can also find advice that pulling into a dirty is very bad, e.g.:

Avoid git-pull!
git-pull should never get invoked if you have dirty files lying around or if your branch is ahead of master.
This will always lead to some dirty artifacts in the commit history

Is there an easy answer to which perspective is best, or is this somehow a case-by-case thing?

Followup: Would using "git pull --rebase" rather than just "git pull" change the answer at all? Rebasing may have its own pitfalls in some cases, but so far my guess is that having a dirty working tree/index wouldn't make a rebase more problematic than it otherwise would be.

Answer 1

No offense to the people maintaining the Apache DeltaSpike project, but I'd trust what the Git man pages say about Git over the contents of the Delta Spike wiki.

Also note that in the quoted text (emphasis mine):

git-pull should never get invoked if you have dirty files lying around or if your branch is ahead of master. This will always lead to some dirty artifacts in the commit history.

The "dirty artifacts in the commit history" are Git merge commits. This happens any time you merge branches instead of rebasing the contents of one branch on the other. Whether or not these merge commits are "dirty" depends on your project, your organization and its opinion and policies.

In any case, git-pull is never a dangerous operation. As documented, it will not destroy any of your history or work in progress.

Answer 2

Scenario A:

If the pulled commits would conflict with the uncommitted changes in your working tree, then Git would abort and save you from making a mess of your repo.

Scenario B:

If the pulled commits would conflict with committed changes in your repo and you also have uncommitted changes in your working tree that would not conflict, then you'd end up with a mess on your hands. You would have to resolve the conflicts and commit without losing track of the changes that were in your working tree prior to pulling.

Scenario B comes up for me sometimes after introducing new team members to Git. A common mistake of new members to my team is accidentally/negligently changing files in our network drive repos, rather than on their local clones like they're supposed to, and they also forget to commit those changes!

As an aside, one way to protect yourself from mistakes made by your team is to always pull to a clean local repo first, deal with any conflicts locally, and then pull from your local repo to the repo you share with your team. This extra step prevents Scenario B and either makes the dirty tree transparent to you or, worst case, presents you with Scenario A. Thankfully, Scenario A can be dealt with as a normal conflict, without the headaches of Scenario B.