1

I have the same repo cloned on two machines, with both machines having exactly the same git version (2.34.1).

On machine 1:

git pull
echo '# comment' >> Makefile
git pull

As expected, in the above commands, the first pull succeeds, and the second pull fails with:

error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.'

On machine 2 (an aws/ec2 instance, and using a readonly SSH key, in case these are relevant), I repeat exactly the same set of commands (and confirm with git status that Makefile is modified, yet rather than getting an error I get Already up to date.

  1. What might be the cause of the difference in behavior?
  2. How to fix it (make it fail when files are modified)?
Virtually Real
  • 1,572
  • 4
  • 16
  • 20
  • 1
    Is the commit log history the same too? – Mattia Righetti Mar 09 '23 at 22:12
  • @MattiaRighetti `git log` returns exactly the same thing on both machines – Virtually Real Mar 10 '23 at 00:53
  • 1
    Different configuration? One machine/repository with `pull.rebase = true` (or `merges`/`interactive`), the other without. Check with `git config -l` and `git config pull.rebase` – knittl Mar 10 '23 at 13:02
  • @knittl This was a good lead, and now I have the same behavior. On machine1, branch.master.rebase was set to true. Doing the same (`git config branch.master.rebase true`) on machine2 got me the same behavior. I would like to have this as the answer, if you write it as answer. Thanks. – Virtually Real Mar 10 '23 at 18:16
  • @VirtuallyReal Again, I mentioned a different config in [my answer](https://stackoverflow.com/a/75696315/6309) – VonC Mar 10 '23 at 18:23

3 Answers3

1

Check first if on the second machine git config pull.rebase is set to true.

If not, a pull would use git merge, which can work if Makefile is not part of the modification being pulled (and merged).

Already up to date should mean there is nothing to pull from the second machine: check the git log --decorate --oneline --graph on both machines to confirm the local repository reference the same history or not.

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

The difference is that on the second pull there are no new commits to be brought in.

git pull is the combination of two commands, git fetch and git rebase (in your case, otherwise git merge).

So what is happening is git does a fetch to see what the last commit is on the remote and then checks to see if the commits is the same as what it has on the local. If they aren't the same, git tries to do a rebase which then throws an error if there are unstaged changes.

Using this answer https://stackoverflow.com/a/3879077/498699

You could use git diff-index --quiet HEAD -- to see if there are modifications. And then stash before doing the pull or whatever you want to do.

Schleis
  • 41,516
  • 7
  • 68
  • 87
  • Both copies of the repo start exactly in the same state. I.e., neither one has anything to be brought in. One refuses to try talking to remote before I either commit or stash the changes, and the other one declares unjustified success. – Virtually Real Mar 10 '23 at 00:59
  • 1
    Do both have the same config for a `git pull` ie is one set to do a merge and the other a rebase? check `git config --global` – Schleis Mar 10 '23 at 02:50
0

Different configuration? One machine/repository with pull.rebase = true (or =merges/=interactive), the other without. Check with git config -l and git config pull.rebase

Without pull.rebase, a merge will be performed by default, which will succeed if the unstaged file is not changed by any of the two sides of the merge. For rebasing, this cannot be known before actually executing the rebase, so that's why it succeeds on one machine, but not the other.

knittl
  • 246,190
  • 53
  • 318
  • 364
  • But the different config is the first thing I mention in my answer, no? What is going on? – VonC Mar 10 '23 at 18:22
  • @VonC thank you. It is true. Though, I found @knittl's answer more helpful because it told me exactly what to look for and how (use `git config -l`) – Virtually Real Mar 10 '23 at 18:24
  • @VirtuallyReal You had the exact command to run? `git config pull.rebase` – VonC Mar 10 '23 at 18:28