-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GitGraph - line routing and colour for adjacent merges #4912
Comments
Confirmed. If it renders exactly as on the screenshots provided, that means it is either not fixed yet, or GH has not updated it yet, which is to say it reproduces on GH gitGraph
commit
commit
branch feature-001
commit
commit
checkout main
branch feature-002
commit
checkout main
merge feature-001
merge feature-002
|
can you please elaborate the problem statement? I am new here and want to contribute to this issue. |
The line representing |
My workaround is: gitGraph
commit
commit
branch feature-001
commit
commit
checkout main
branch feature-002
commit
checkout main
merge feature-001
checkout feature-002
commit
checkout main
merge feature-002
Coded as:
So the additional commit has to be after the merge of |
Ah, I see! As the workaround screenshot is already there, it might be worth putting this code under in the issue description too, perhaps under the Code Sample so there's a reference for the workaround. |
Looks like this might be an issue even for simpler use cases, not just adjacent merges... Here's the example diagram bundled within Mermaid for dev purposes: The merge branch is coloured for This despite the fact that there are comments in the code saying "Arrows going up take the color from the source branch" (and likewise "arrows going down take the color from the destination branch"). So it looks like something generally is not working as it should here. |
@ijmitch Fair enough as a workaround but it is a compromise rather that an equal replacement because commits' order matters too. |
@nirname oh yes, I described it as a workaround since it's something acceptable for my current purpose which is purely illustrative for education about branching strategies. I'm going to take a stab at what @guypursey 's diagram might be... gitGraph
commit
branch newbranch
commit
commit
checkout main
commit
commit
merge newbranch
coded as
|
Pretty much 👍 It was the code below -- basically taken from https://github.com/mermaid-js/mermaid/blob/develop/demos/git.html, but I removed the line
|
Thank you all for detailed analysis. Could not have done it better |
I've carried out some more analysis and I think I've almost fixed this... Colour seems to be working in my local branch and I'm almost there with the routing 🤞 I'll raise a pull request for review when I think I've done it |
I think I've fixed this one now and have a PR (#4927) that is passing all tests, ready to be reviewed and approved/merged if all looks good |
PS. For completeness, here is the preview environment with the code from this issue's description, showing the bug is fixed. |
I just noticed that some of my examples where I want to demonstrate release branches by having them branch to lanes above %%{init: {'theme': 'base', 'gitGraph': {'mainBranchOrder': 2}} }%%
gitGraph
commit
commit
branch release-1
commit
checkout main
commit
branch release-2
commit
checkout release-1
commit
checkout main
commit
coded as:
I checked both the current and preview live editors and they behaved the same, so if this is a bug then it looks different in nature to this one and I'd be happy to create a new issue for it. |
@ijmitch Interesting... I think this might be separate bug personally. I'd not only like to see the arrows coloured appropriately but also the branch curve flipped out the other way. For example, when you do the original branch to Happy to work on it as a separate PR, given I've been digging around in that part of the code already. |
@nirname Not sure of etiquette re requesting approval but this one is ready for review now 🙂 |
@ijmitch Your coloring example is related to this issue for sure and seems that it is fixed in the upcoming request. |
Description
If two branches are merged 'back-to-back' without any other intervening action, the route drawn and colour chosen for the second merge seems wrong. Adding a commit to the branch which is merged second results in a much better outcome.
With adjacent merges:
With the extra commit as a workaround:
Steps to reproduce
See the sample below...
Screenshots
See the images above
Code Sample
My workaround is:
Coded as:
So the additional commit has to be after the merge of
feature-001
.Setup
Suggested Solutions
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: