Azure-devops-docs: misleading git diagram

[robianmcd]

The diagram for a squash commit is a bit misleading. Branches in git are just pointers to commits and the "my-feature" branch is shown as a pointer to the first purple commit. So I would assume the second purple commit is not part of the feature branch. But I don't think this is what the diagram is trying to convey as the example of doing a merge shows both purple commits being merged in.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 56dec464-f25a-5c46-52e7-2cbf17a2db1d
• Version Independent ID: bbe4d6d1-71a7-0c47-7bfb-1577760e003b
• Content: Squash merge your pull requests
• Content Source: docs/git/merging-with-squash.md
• Product: devops
• GitHub Login: @steved0x
• Microsoft Alias: sdanie

[anielsen]

I agree with robianmcd on this :-)

[SinZ163]

Can take a step out of github's book and consider something like

[anielsen]

Much better @SinZ163 :-)

[owinter]

Hello, why does Microsoft recommend to delete the feature branch when squash-merge it? I would lose the more precise information within D and E? So if I would find a "problem" in F, I could look at the archived feature branch to locate the problems source...

[blumk]

@owinter Do not use squash-merge if you care about the more detailed information from D + E, use a regular merge instead. If you squash-merge you'll lose the reference to D + E and in that case you should delete the branch.

[owinter]

@blumk Thanks for the reply. I tried some things about that and pointed out, that...

1. The team services (DevOps) saves the squashed commits within the pull requests. So even if I don't see the commits in the branch history, the infos are not lost. Very cool!
2. Why MS recommend to delete the source? F is a new commit that doesn't exist in the source. So if you'll try to merge it again you'll get a git triggered conflict.

[blumk]

So if you'll try to merge it again you'll get a git triggered conflict.

@owinter This is the reason why you should delete the source branch.
You have two options:
a) Keep the history -> use merge
b) No need for history -> use squash-merge and clean up the repo by deleting the old branch

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[devudu]

I don't see the diagram is confusing (except the confusing squash feature itself is)
When you squash, you lose all history which is desired in some cases where you want to hide all blunders you did :P

[darrincedwards]

The confusing part is how the "my-feature" branch is shown; the thing that is confusing is common to both diagrams, and so it is not related to the kind of merge being done.

What is confusing is that the "my-feature" label points to the older (left-most) of the two commits on that branch; the newer (right-most) commit is shown with a simple open circle. This could be misleading if someone thought it was an "orphan" commit not on any branch (in particular not on "my-feature".

As robianmcd suggests, the second commit should have the filled-in purple circle (with the little history symbol on it), and the older (left) commit should be the open purple circle.