When more than one person is working on some project or library we stumble over an issue called MERGING!"???!##
I just wanted to make sure that you guys know that we started to work on that.
For now, the first baby steps are here: https://github.com/gregsn/MergeVLDocs
This is just a heads up to avoid ppl to work on the same issue twice…
Exciting times!
Great! Very important topic!
really nice!
here is an additional way to only execute MergeVLDocs for .vl files:
Hey!
I just wanted to inform you that some more work went into the tool.
It might very well be that this is not at all what you expected or would like to have in the end (a visually highly pleasing visual merge with super intuitive ways of navigating through the patches cherry-picking here and there).
Wait: that also sounds complicated…
No; what you can test here is a tool that merges always and without complaining. A magic bullet. It doesn’t free you from communicating with your coworkers about who is working on what. You shouldn’t try to work on the same patches anyway. It just can’t work.
Up to now, however, even merges of unrelated changes could result in conflicts. At least conflicts from the perspective of a line based merge tool.
This tool is the opposite. It currently just warns you but doesn’t go into detail (but will do so in the future) and always comes with a fallback strategy:
the other dev wins.
this merging strategy allows you to merge stuff into your branch that you don’t know much about. If any conflict arises the tool will favor the remote changes. After merging it’s a bit more likely that the remote stuff works while yours maybe not, which is much easier to tackle by yourself, then the other way around.
The tool now comes with a few buttons that make it more a commander for comparing the different snapshots of the file in text form and with VL. It is currently a very manual process that allows you to let the tool run and then compare the result with remote, which should have roughly the same changes as when comparing local with base (your changes).
In its current state, it allows you to monitor the merging process and even opt for a line based merge. In its current state, it is also a tool for debugging its own doing.
So give it a try if you are in the merging business.
Thank you! Have fun!
Ps: it is recommended to open the merged file with VL before committing. By that, the formatting gets fixed and the changes done by the tool become more readable.
Note that this is just a very first step and that more work will be invested to make the tool more user friendly…
@sebl Thanks for the link! But this also looks like a workaround. Much more lightweight. True that. As if git doesn’t come with the idea to call different tools for different extensions, which is a bit weird for a bit of software that is as popular as git. Or maybe i am blind.
For now though, I stick with calling our tool all the time as it evolved to a commander that allows you to call different diff tools in addition to the three-way merge. Regardless of the file type, this can be helpful as you can focus on certain changes. Less information to digest.
i will just drop this here since it proved useful for me recently and seems related: https://en.wikibooks.org/wiki/Git/Repository_on_a_USB_stick
Hello everyone,
it got a bit more likely that this tool may be able to help you, as it now not only magically merges whatever you throw at it, but also tries to tell you which parts were rather hard to merge and reports that in a visual way.
If the dot in the middle (the document) is green you shouldn’t have to worry.
If the dot is orange it has some warnings somewhere and tries to visualize the problematic parts of the XML tree in a sunburst(?) diagram, where the document is in the center and the pins of a node application within a node definition within a category (canvas) are further outside.
The tool still favors simplifications (deleted parts win over modified parts). And remote changes win over local changes. These sorts of conflicts and how they got resolved now get communicated.
It’s still not super easy to navigate to the patches and see the conflicting parts in terms of an actual patch, but you can open the different document versions and navigate to the problematic parts if you are unsure if you can live with the merge.
For now it’s still not possible to choose the one or other merging strategy per element or branch in that XML tree, but that is planned.
So, this is not yet what will solve all your merging troubles, but it can help.
Note however that I now highly recommend to save your merged documents before you commit the merge. Due to how git merge works internally (recursive, whatnot) it is very good when the line changes get reduced, which is by saving the merged document with VL afterwards. Skipping this step might result in future merge problems. Dropping the necessity of this step is planned, but it will always stay good practive to look at the merge as many things can go wrong that no merge tool can fix for you. So looking at the merged patches and saving is the recommended workflow.
Please report your findings in this thread or here: https://github.com/gregsn/MergeVLDocs/issues
Elbow and kick hugs corona style
Regarding the last paragraph: this happened to me me on my first merge, especially because the feedback was that only the document versions changed. Being so used to the auto-merge of other line based merge tools I simply saved, committed and pushed. Only a day later I recognized in the git history the many changes produced by the different XML serialization. So I guess this should be made much more clear in the tool itself as long as it doesn’t save the document with the same XML serializer as VL does itself.
Apart from that, it already saved my day! Bravo!
Because the most annoying part are the closing tags, maybe because of this?
If you ever run into real big merge troubles, e.g. VL Merge doesn’t run and P4Merge shows strange lines in your BASE file like this
<<<<<<< Temporary merge branch 1
then maybe abort the merge and run a different merge strategy. Here is what I tried and what helped.
I opened the Git bash via the button in GitExtensions and entered:
git merge --abort
git merge -s resolve origin/MyRemoteBranch
Back into GitExtensions, Refresh, Commit, Go over all merge conflicts again. Whenever you encounter a better workflow for these scenarios please let us know.
@Elias that helped. I also was able to fix the Document Header. Now the only thing left are the missing XComments
That’s why we should use YAML like most modern projects do. It’s a format that was specially developed for data serialization (with graph structures) and readability for humans. Which is exactly our case.
Seeing YAML in the git diff is quite understandable, while XML causes headache even if the merge is simple.
Line based diff tools can also auto-merge much more cases since it doesn’t need a closing tag.
And size on disk is smaller…
After using this internally all the time I’d say that using the automatic merge provided by the tool is
than manual merge strategies like
The boldness doesn’t end here.
Note that the tool is far from perfect, but should be better than no tool.
big up from here! i use this quite extensively and it works well.
but:
can we have more explanation on the visualizer thing?
e.g. what do the colors mean
It’s not that refined.
The main idea is to have a quick first impression of the merge result of the whole document with one glimpse. The more complicated it looks the more guessing has happened.
The document is a tree. So the root is in the center and grows outwards.
Blue is a message (typically can be ignored).
Warnings are orange.
Grey means that there is nothing to report, these are just there because some children come with messages. Those that only have an outline are elements in the model structure like “Patch” or “Canvas” that don’t say much. You normally only want to hover those that are filled.
Errors would be red. But I didn’t mark anything like that yet.