I’m an Azure DevOps support engineer for Microsoft. Prior to composing
this communication to the Git team I had a conversation with the
Product Group from Azure DevOps stating this could be expected
behavior, truth is they didn’t take the time to analyze this with me
stating our PR system does nothing extra to the regular Git tool.
However I’m still suspicions about it since I consider myself advanced
in Git workflows.
Customer completed a PR from release/Pl4S1R4 into master. PR's id 5238.
Several commits made up this PR: 15 approximately were added to the
source branch release/Pl4S1R4 while the PR was active.
2 out of 15 commits made the exact same change to the exact same file
on the exact same lines. One of these two commits was committed to
source branch directly and the other one is a squash merge commit that
resulted from another PR completion to source branch coming from a 3rd
branch while the original PR 5238 was active.
Specifically commits [descending order]:
13ade36d - squash commit of a third branch coming into source branch
42940662 - commit made directly to the source branch
Specifically, both commits include along many changes the following
change to file /src/components/Layout/Menu.vue on line 80 and line 91
Original version of file line 80 and 91:
80 {{menuOptions.NETWORK}} {{'v'}}
91 {{network.name}} {{'v'}}
Resulting version of the file in line 80 and 91 for both commits:
80 {{menuOptions.NETWORK}}
91 {{network.name}}
The weird thing which raises a flag for me is that making the same
change to the exact same file 2 times wouldn't even be possible at all
since first change would make its current status the desired one and
therefore the next commit with the same change wouldn't even highlight
the lines as change. I believe this could be due to the nature of the
second commit coming from a PR completion [squash] where maybe the
file was kept unchanged.
What I would expect here is that the PR would read the file and would
ignore the second change made by squash commit since this exact change
had already taken place previously.
Above all this despite the PR having 2 commits highlighting the exact
same change on a file, the resulting squash commit ignored them both
and showed the lines 80 and 91 in the affected file as untouched.
I carefully verified with cx that no other commit would 'revert' this
two changes or even edit the file /src/components/Layout/Menu.vue
again so it seems like the system indeed ignored them both on its own.
Note that other changes to different lines of the affected file were
recorded correctly in the resulting squash commit once PR was
completed.
Due to the complexity of cx's environment, I haven't been able to
reproduce the issue myself, but the proof is inside the PR stored in
cx's Project.
--
