0

I am working on a project with a coworker, and we are both making changes to separate tools on the app. We typically do not have problems, but something strange is happening now.

Every day we pull from master, periodically add ., commit, and push changes throughout the day. At the end of the day, we merge branches using...

git merge origin/otherPersonsBranch

... we then both add ., commit, and push again before we leave.

Yesterday, we noticed that there is at least one file where some changes aren't merging. We are not yet aware of any others.

We are not receiving merge conflicts, and usually :quit the vmeditor when that pops up.

When merging or pulling, we are both getting 'Already up-to-date'.

Maybe we set up the branches incorrectly at the start? I don't know. What am I 'git'ing wrong? Any ideas?

Ticdoc
  • 248
  • 3
  • 15
  • May I advice something like [git extensions](http://gitextensions.github.io/)? – Ron van der Heijden Mar 02 '18 at 15:41
  • Maybe the file was never committed in the first place. When you make changes to the file and then type `git diff` do you see any changes? – Alex028502 Mar 02 '18 at 15:45
  • If I make a change to the file in question on my branch, save, and do git diff, yes I do see the changes displayed to me in the terminal. – Ticdoc Mar 02 '18 at 15:49
  • @RonvanderHeijden I will consider git extensions in the future, but I just prefer using the Terminal right now, because I am new-ish to the dev world and I feel like I can learn better using the Terminal. Thank you for the suggestion! – Ticdoc Mar 02 '18 at 15:51
  • @Alex028502 Same thing on coworkers branch, despite the two files being 'different' between each others branch – Ticdoc Mar 02 '18 at 15:55
  • `gitk --all` is a great tool. it only does the stuff that would be extremely painlful from the terminal. It gives you a really good picture of how all the branches fit together, and comes packages with git – Alex028502 Mar 02 '18 at 15:57
  • also have you tried `git fetch`? I'm not sure if `git pull` will update your copy of your coworker's branch. It might just update your branch. – Alex028502 Mar 02 '18 at 16:00
  • When I git fetch --all, my list of branches does not change. Afterwards, I tried to merge with the branch with desired changes, again in vain. – Ticdoc Mar 02 '18 at 16:06
  • I just noticed, when I git checkout to the otherPersonsBranch, the file in question I get 'error: Your local changes to the following files would be overwritten by checkout: xx/xx/fileInQuestion.js Please commit your changes or stash them before you switch branches' So I committed, and did git checkout to that branch. The file I see now after checkout is the file I had, without the desired changes. – Ticdoc Mar 02 '18 at 16:18
  • I switched branches to otherPersonsBranch, and observed that the desired changes are present. Then I added, committed, and pushed. I switched back to myBranch and did git merge on that branch again, still the change is not coming in. – Ticdoc Mar 02 '18 at 16:46

1 Answers1

0

This:

I just noticed, when I git checkout to the otherPersonsBranch, the file in question I get:

error: Your local changes to the following files would be
overwritten by checkout:
   xx/xx/fileInQuestion.js
 Please commit your changes or stash them before you switch branches

is definitely important. It is possible to run git merge with uncommitted changes in the work-tree, but I strongly recommend against that. (The main problem is that if the merge goes wrong, it can be very difficult to back out of it. If you have committed everything, it is easy to back out of it.)

In any case, once you do have everything committed, to see what a merge will do, first find the merge base. See, e.g., Find the most recent common ancestor of two Git branches or many of my recent answers. The merge will compare the merge base to each of the two branch tip commits. You can do this same thing yourself, using git diff—see the special syntax in that same answer, or:

Yesterday, we noticed that there is at least one file where some changes aren't merging.

Git doesn't compare the two branch tips to each other. Running git merge $other compares the base to your branch tip:

git diff --find-renames $base HEAD   # see what we did

and again to their branch tip:

git diff --find-renames $base $other # see what they did

and then combines those two sets of changes. So the chosen merge base is critical to this process, as are the contents of the two tips. (Any commits in between are quite literally irrelevant, except in terms of their role in locating the merge base commit.)

(When you have uncommitted changes, the first git diff is in effect against your index, rather than your HEAD commit. Actually, this is always true, it's just that if everything is committed, HEAD and your index match, by definition. Meanwhile, the low level merge process, which runs after the two diffs have done the appropriate file-matching, attempts to preserve un-indexed work-tree changes as well; this is where things get really messy.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • This is great, I did not know I could do that. I can see the differences between mine and her branch right now. and it seems just that one js file. How can I prevent this from happening in the future? I am not even sure what I did wrong. Could I have missed a step by mistake while trying to push my changes? – Ticdoc Mar 02 '18 at 20:18
  • It's hard to tell from here. Note that you can run `git log --all --decorate --oneline --graph` (mnemonic: help from A DOG, All Decorate Oneline Graph) to have Git show you, graphically, the branch-y structure of the commits, from which you can *see* the merge base. (Well, sometimes it's clear, and sometimes it's very unclear; the one place where GUIs can help a lot is here, showing the graph. Mostly I stick with the command line when I can, though.) – torek Mar 02 '18 at 22:08
  • Okay. I will go ahead and do what you and Ron said above, install the gui, and see how that goes. Maybe I will learn something. To work around the problem I had, I simply copied the missing code from my coworkers branch. It wasn't much. I just wish I knew what I did to cause it to happen. In the future I will be more consciencious about what git commands I am running in the Terminal. In the meantime I will just accept this answer (and then go take a GitHub course...) Thanks guys! – Ticdoc Mar 02 '18 at 23:07
  • Note that if you can use `gitk` you don't need a full GUI (well, `gitk` is sort of gui-ish, but I mostly just use it for faster browsing when dealing with particularly messy repositories). – torek Mar 02 '18 at 23:09