11

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.

Community
  • 1
  • 1
Chris
  • 9,986
  • 8
  • 48
  • 56

6 Answers6

7

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.

André Caron
  • 44,541
  • 12
  • 67
  • 125
  • 1
    That statement from the wiki is bizarre: local modifications will **never** lead to "artifacts" in the commit history. – Cascabel Mar 25 '12 at 06:06
  • @Jefromi: indeed. That's why I put the emphasis on the latter part (which does automatically create commits if necessary). – André Caron Mar 25 '12 at 16:19
  • I can't see such a comment in the Wiki of DeltaSpike. – Dar Whi Apr 13 '12 at 20:35
  • @DarWhi: The [link in the question](https://cwiki.apache.org/DeltaSpike/suggested-git-workflows.html) contains the comment in the first section, titled "Avoid git-pull!". The link title text is only "e.g." so its rather subtle. – André Caron Apr 13 '12 at 21:16
  • Yes and below there is the suggestion: git pull --rebase And that's perfectly fine. – Dar Whi Apr 16 '12 at 10:38
  • @DarWhi: Yes, and my answer both says 1) that `git-pull` is never dangerous; and 2) that rebasing does not produce those "artefacts". The question was about whether or not using `git-pull` can cause you to lose history? What's your point? – André Caron Apr 16 '12 at 16:42
  • No it doesn't drop history. You just get ugly merge-commits (with un-pushed local commits), which can be reduced easily with the --rebase option of git-pull. You just get in the remote commits as they are and your unpushed commits will be applied on top of them. Only if you have _real_ merge conflicts, you will get a merge commit. In the other cases you don't get the ugly merge commits. – Dar Whi Apr 17 '12 at 08:17
  • 1
    @DarWhi: You're just re-wording what I said in my post and my comments. – André Caron Apr 17 '12 at 19:17
  • That also means you agree with the content of the Wiki. – Dar Whi Apr 20 '12 at 20:09
  • @DarWhi: I never said I didn't agree with the contents of the wiki. In fact, the wiki recommends rebasing instead of merging, which I also recommend in most scenarios. The thing is the poster contrasted the Git manpage with the Apache DeltaSpike wiki, to which I responded that when in doubt, I trust the Git manpage over any other source. – André Caron Apr 21 '12 at 04:37
3

In my experience, it's absolutely safe (I am using git for about 4 years). If you have uncommited changes, it usually just fails telling you that you have a dirty working copy.

Konstantin Solomatov
  • 10,252
  • 8
  • 58
  • 88
1

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.

Zach Bennett
  • 11
  • 1
1

git pull is simply git fetch + either rebase/merge, the automated merge can create noise or unintended results. (Example of noise: You don't need 10 merge commits when all you did was to add a single line to the same file 10 times.) If the uninitiated simply does a git pull and push back without checking, the noise will be checked in.

I would just say that the new team member is more likely to be disoriented after a git pull on a dirty working tree, whether it is safe or not, it will depend on the response (checking the results after every pull will be a good start).

prusswan
  • 6,853
  • 4
  • 40
  • 61
1

So far I'm not sure this actually bears on git pull (which sounds like it pre-detects whether there could be merge conflicts and aborts if there could), but note at least tangentially that merging (i.e. doing git merge) into a dirty working tree can apparently limit your ability to "undo" your merge in the case that the merge goes bad. In particular, from the git-merge manpage:

   [merge] --abort
       Abort the current conflict resolution process, and try to
       reconstruct the pre-merge state.

       If there were uncommitted worktree changes present when the merge
       started, git merge --abort will in some cases be unable to
       reconstruct these changes. It is therefore recommended to always
       commit or stash your changes before running git merge.
Chris
  • 9,986
  • 8
  • 48
  • 56
0
git fetch

And then merge, rebase or reset depending on what was fetched from the server. You can use pull and it will not destroy work in progress. However the former method is preferred.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141