2

I've seen this on a few projects. I think that Github does the big picture / little picture with "commits with" when commits by another one are added to a branch cut by another author. In this case it would be done by merging the develop branch into the feature branch.

In pull request / feature branch: enter image description here

Already in develop branch: enter image description here

I looked and the diffs for d679668 and 8317e24 are identical, but there is no merge conflict, so the pull request can still be merged. I think this is possible because the PR also has merge commits that probably resolved the self-conflicting commits, but I'd really like to know what the pull request creator did to have this happen in the first place.

My suggestion for resolving this issue would just be to cut a new branch from develop and cherry pick the changes from the feature branch into the new branch (there are only a few). I'm more interested to know what could have caused these duplicate commits to appear in the pull request / other dev's feature branch.

Explosion Pills
  • 188,624
  • 52
  • 326
  • 405
  • `what could have caused these duplicate commits` they aren't duplicates, they are the same commit merged into the feature branch (which can be avoided by rebasing the feature branch onto develop, instead of merging it). – AD7six May 04 '16 at 13:37

1 Answers1

3

when commits by another one are added to a branch cut by another author

That's wrong. Commits are not "cut by" another author, there is no author associated with a branch. They are transient pointers to commits, nothing more.

Git is showing you that the author and committer are different people. Every commit has both an author and a committer. They are usually the same person, but when they're different, Github shows them picture-in-picture style.

If you're seeing this periodically, it's very likely because somebody is rebasing somebody else's commits.

looked and the diffs for d679668 and 8317e24 are identical, but there is no merge conflict, so the pull request can still be merged.

There is no conflict when the changes introduced are identical.

My suggestion for resolving this issue would just be to cut a new branch from develop and cherry pick the changes from the feature branch into the new branch

That's one solution. You could also ask the developer issuing the pull request to git fetch and then git rebase -i origin/<target branch>, and to manually pick only the commits that he authored and is interested in merging.

I'm more interested to know what could have caused these duplicate commits to appear in the pull request / other dev's feature branch.

At some point in time, the author wound up with those commits on his feature branch. Maybe he merged them in from a different branch, or based his branch off origin/develop while his local develop was behind. Whatever the case, he probably rebased his feature branch on develop before issuing the pull request, wasn't careful about looking at which commits he was dragging along, and wound up rebasing somebody else's commits in addition to his own.

Community
  • 1
  • 1
user229044
  • 232,980
  • 40
  • 330
  • 338
  • How does git know who the author of a patch was if it wasn't committed yet? – Explosion Pills May 04 '16 at 13:47
  • @ExplosionPills I haven't worked with merging via patch, but AFAIK the patch contains author data. I assume whoever accepts and merges the patch would become the author, I kind of assume that's why the distinction between author/committer exists int he first place. – user229044 May 04 '16 at 13:50
  • Seems like this could happen during a merge. I guess the real answer is the creator of the PR just did the wrong thing (tm). Would be interested to know exactly what happened and how to prevent / undo it, but I know this wouldn't have happened if he followed our normal flow. – Explosion Pills May 04 '16 at 13:54
  • @ExplosionPills I don't think it could happen during a merge, unless we're talking about merging textual patches. Merges don't alter the committers or authors of any existing commits on any of the branches being merged. They simply create a new merge commit, and that commit will have the author/committer of the person who performed the merge. – user229044 May 04 '16 at 13:56
  • Sorry I meant if there were a conflict, but I'm not sure. Rebase seems more likely but the guy who created the PR was also merging things in so maybe he tried to rebase, didn't know how, and then merged some things in – Explosion Pills May 04 '16 at 17:00