1

I wonder if there is a way to detect if a commit was rebased with a manual conflict resolution or with Git's auto rebase (without conflict).

In details, lets say, in Gerrit a pending commit needs a rebase because some commits are merged within review period. In that case developers need to upload a new patch after rebasing. Reviewer wants to know it its an auto merged without conflicts (with #git pull --rebase) or a manual merge happened due to conflicts. If manual conflict happens admin may want to review with more consciously. Otherwise admin have trust on Git.

is there any way using Git/Gerrit API?

Improve this question
7
  • If the reviewer want to detect if a commit was rebase manually or autmocatically, he must provide at least two commits: the commit rebased to, the commit was based for rebase. Is it possible for the reviewer to find which commit was rebased and when it rebased (for the two commits)?
    – Marina Liu
    Commented Aug 4, 2017 at 7:51
  • didn't understand your point marina.
    – Sazzad Hissain Khan
    Commented Aug 4, 2017 at 8:40
  • Such as commit A was rebased on commit B, then in a branch there will contain the commits …---B---A'---…. So you need to know the commits both for B and A, or you should make sure if the commit A' is rebased. Is that possible for the reviewer to find commit A and B (or commit A')?
    – Marina Liu
    Commented Aug 4, 2017 at 8:53
  • There is a parent field in Gerrit which means commit B is parent of commit A. Even if the parent is known how could you be sure that manual or auto merge happened?
    – Sazzad Hissain Khan
    Commented Aug 4, 2017 at 8:57
  • When you rebased commit A, the rebased commit will be different (as A'). So you can only find A''s parent is B, but you can't find the commit A. Why it needs two commits A and B: we need to calculate the changes between them, and then find if there has conflicts. If there has confilcts, it's merged manually, else it's merged automatically.
    – Marina Liu
    Commented Aug 4, 2017 at 9:03

1 Answer 1

Reset to default
1

You can use git cherry <branch after rebase> <branch before rebase>. It searches for "equivalent" changes and lists those which do not have equivalent with "+". If there was a conflict while rebasing, then patch changes, so change is no longer equivalent.

It creates some amount of false positives, when concurrent changes are close enough to consider commit not equivalent, but distant enough to not trigger a conflict.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.