-1

I have a release branch in git that I would like to merge to the development branch. However, when I create the pull request and look at the differences, I'm seeing odd behavior.

People have checked in several bug fixes to the release branch and then cherry-picked them into the development branch. However, the pull request is still showing those fixes as differences, even though both files are identical when I checkout each branch and directly compare them.

I'm thinking I have a fundamental misunderstanding about how git handles cherry-picking and/or merging. What's going on here?

Edit: Per torek's request, here is a complete example.

1)I have a branch called "Develop" and create a new branch off of "Develop" called "Release" on the remote server.

2)I then create a new local branch off of "Release" and make a change to a file.

3)I push that local branch to remote and then do a pull request from that new branch onto the remote "Release".

4)Then I cherry-pick the change from "Release" to "Develop", and create a new pull request to complete that merge.

5)Finally, I'm ready to do a final merge from "Release" to "Develop" on the remote server, so I create a new pull request, and...

It's still showing the change I made as a difference even though the file is identical in both branches.

mrplainswalker
  • 701
  • 4
  • 8
  • 26
  • This *may* be more about GitHub ("pull request") than about Git (which doesn't have "pull requests", it just has commits that you can choose to merge, or not). There's not really enough information in your question to be sure, though. While this is more about code, see [mcve] for how to provide enough background in a question... – torek Mar 01 '19 at 18:30
  • Still, for (much) more about cherry-pick and merge, see my answer to [What it means “changes introduced by a commit” in git](https://stackoverflow.com/q/54850630/1256452) – torek Mar 01 '19 at 18:32
  • I read through your response there, and I still don't understand why git thinks there is a difference. You highlighted the 5 possibilities during a merge. This is possibility #4. Both files have the same change and are identical, so it shouldn't be showing as a difference. – mrplainswalker Mar 01 '19 at 19:22
  • I see you've added a setup to your example (good) - but are you viewing the pull request on GitHub? Or are you using `git diff` locally, in your own Git repository, to compare the merge base commit to the tip commit of your branch? Or are you doing something else entirely? (If you *are* using the GitHub web site, I can't explain why they show what they show—some of it, sometimes, seems to be utter nonsense.) – torek Mar 01 '19 at 19:33
  • When I use git diff on the command line, I only see the actual differences. I guess I just assumed that github would use git itself to determine the differences. – mrplainswalker Mar 01 '19 at 21:44
  • Perhaps a better question is...does git provide a way to preview what actual changes it will make during a merge? There are a lot of differences between the release branch and the develop branch because people continued adding features and changes to the develop branch. I want to make sure that all bug fixes from the release branch are merged into the develop branch. If I just do a diff, I see everything different between branches. What I want is to see what lines and files git will CHANGE during the merge. – mrplainswalker Mar 01 '19 at 21:55
  • The way to tell, locally, what would happen if you merged something is just to merge it. You can then compare the resulting merge commit against the previous branch tip (`git diff HEAD^ HEAD`, for instance) to see what changed. Why GitHub doesn't offer you an easy way to show that—they have actually done the merge; it's hidden under a special ref name, rather than the normal branch names and `HEAD` and the like—I don't know. – torek Mar 01 '19 at 22:01
  • The way to understand all this, by the way, is to realize that most Git operations just add *new commits* (new snapshots). No existing commit changes in this process! So all your existing stuff is still good. You can inspect the new commit(s) and then either start using them, or just drop them on the floor and let them get (eventually) swept out with other garbage (in roughly 14 to 30 days in normal repositories; GitHub's internal setup is much more aggressive with discarded pull requests). See also [Think Like (a) Git](http://think-like-a-git.net/). – torek Mar 01 '19 at 22:04

1 Answers1

0

It appears that github is just showing all the commits in the branch since the last merge, without any regard for identical commits in the branch that I'm merging into.

I took torek's advice and just made a local branch to merge into. I did the merge, resolved conflicts, then compared that branch to the remote, and there were no differences. Kind of an annoying solution, but whatever works.

mrplainswalker
  • 701
  • 4
  • 8
  • 26