Merging branches re-executes commits

Describe the feature or problem you’d like to solve

Previously, when a branch is merged into another branch with GitHub Desktop, the merged commits would remember when they were made. If the source branch modified code, that the destination branch didn’t touch, the same piece of code would be modified in the destination branch without any problems once the branches were merged for a second time.

Since a couple of weeks, a second merge from source branch to destination branch is resulting in merge conflicts between the old and new versions of the source branch. It looks like Git or GitHub Desktop thinks the changes from the merge are applied by the destination branch. Merging into the default branch using the website works just fine, but merging 2 other branches using the software creates the mess of conflicts.

Maybe I can clarify it with a step-by-step reconstruction: (Previously)

1. Create line A on source
2. Merge source into destination
3. Destination now has line A
4. Change line A to B on source
5. Merge source into destination
6. Destination now has line B

(Now)

1. Create line A on source
2. Merge source into destination
3. Destination now has line A
4. Change line A to B on source
5. Merge source into destination
6. Destination now has conflict: >>>>>> HEAD A ====== B >>>>> source

Again, I assume this happens because for some reason git or GitHub Desktop thinks A has been committed on destination, even though destination didn’t touch it.

Proposed solution

For the commits to not be re-applied on merge. Those unnecessary conflicts are tiring.

[Bertie2011]

I just tested it and indeed GitHub Desktop (or git internally I guess) uses the merge behavior specified in Settings > Options, if only 1 option is ticked. The owner of the repo in question for some reason decided to only allow rebase merges, resulting in old commits to be added as brand-new. I don’t know his reasoning, but I know that picking squash merging or merge commit options solve it.

Thanks for your time anyways 😃

[Bertie2011]

Well, we found one culprit. Someone was rebasing the default branch into their own branche every time they wanted to update. Since everything else is most likely usage error, I’ll close this issue.

Good to know that rebasing recreates old commits as new and if you don’t fully know what you’re doing, it should be avoided to prevent unnecessary conflicts. (Obvious for many, but I wanted to put it here as conclusion for anyone finding this issue).