0

The Issue:

When merging origin/branch_y into origin/master, after overwriting file_x on branch_y using git checkout origin/master file_x and pushing file_x to the origin/branch_y, file_x still differs from the version on origin/master and is listed under changes.

The Question:

Should not file_x at this point, at least content-wise, be precisely the same on both branches?

Full Story:

Comparing the branches sac_sb3 and master, while issuing a new merge request, I noticed I unwantedly pushed changes of the files env.py and utils.py to the branchsac_sb3 - both files should have stayed untouched.

The branch represents the work of multiple weeks, it comprises numerous commits, and the cleanliness of the graph is not of utmost importance in the given work setting. I deduced that the quickest solution would be to overwrite the files with the file states of the remote master. Therefore, following this StackOverflow post, I ran:


git checkout sac_sb3

git checkout origin/master rlmodel/sb3/utils.py

git checkout origin/master rlmodel/sb3/env.py

git add -u

git commit -m "restore env.py and utils.py with versions from origin/master"

git push

However, when I now reinitialize the merge request between origin/sac_sb3 and origin/master, env.py and utils.py get still listed under changes and even differ content-wise from the versions on origin/master.

L.Lauenburg
  • 462
  • 5
  • 19
  • Could it be `autoclrf`? Just a stab in the dark. [Relevant question](https://stackoverflow.com/questions/2016404/git-status-shows-modifications-git-checkout-file-doesnt-remove-them) – vakio Aug 06 '21 at 10:29
  • I am not sure that I understand `autoclrf ` correctly. But I did all my work on Linux - so no style conversion should have been applied. Also, the files actually differ context-wise and not only in formating. – L.Lauenburg Aug 06 '21 at 10:44
  • 1
    Did you run `git fetch` before the other six commands, so as to update your local `origin/master` based on `origin`'s `master`? If not, that's probably the issue. Your existing `git checkout` commands are correct but you'll get the files from whatever commit hash ID your `origin/master` translates to, at the time of the `git checkout` command, which isn't necessarily right. In fact, even after `git fetch`, it could be outdated, depending on how fast things change over at `origin`, but `fetch`ing is the best you can do. – torek Aug 06 '21 at 14:23
  • Good point! However, I initially ran: `git checkout master`-> `git fetch --all` -> `git pull` -> `git checkout sac_sb3` -> `git checkout master rlmodel/sb3/utils.py` -> `git checkout master rlmodel/sb3/env.py` -> `git add -u` -> `git commit -m "restore env.py and utils.py with versions from origin/master"` -> `git push`. I only used `origin/master` in my question to abbreviate the process. So, anyway, I did run `git fetch -all` beforehand. – L.Lauenburg Aug 06 '21 at 16:17

1 Answers1

1

When specifying paths, it's always better to separate them with -- to prevent ambiguity. Try:

git checkout origin/master -- rlmodel/sb3/{utils,env}.py

You can find all different ways of specifying options, commits, hashes, and pathspecs at the top of the man page.

suvayu
  • 4,271
  • 2
  • 29
  • 35
  • Thank you for the input. I will adopt your suggestion for a better style and to not exploit the relaxations of the git syntax. However, as I do not have any branches named `rlmodel/sb3/utils.py` or `rlmodel/sb3/env.py`, the command will work without `--` - I also test this. Reference: https://stackoverflow.com/a/41102120/11918697 – L.Lauenburg Aug 06 '21 at 10:38