Thought of the day (and daily prayer): May our devs bless us with a proper patch and version comparator — because I simply cannot take it anymore. Git, Claude, and the absolute impossibility of collaborating unless you have a Computer Science PhD and a deep romantic relationship with GitHub. 🙏😩
Seems it’s also possible to setup custom diff for vl files using . gitattributes, idk sounds like a good case for vibe codding, b
Git does not have a built-in “structural” XML diff algorithm. Because Git is designed for plain text, it treats XML files as standard text lines, meaning it doesn’t natively understand XML nodes, nested trees, or attribute order (e.g., it will flag <tag a="1" b="2"> and <tag b="2" a="1"> as a conflict, even though they are logically the same in XML).
However, you can use Git’s built-in features to make diffing .vl (XML) files significantly better without installing any external tools. Here are the best default options built into Git:
1. Use Git’s built-in html diff driver
While Git doesn’t have an xml driver out of the box, it does have a built-in html driver. Because HTML and XML share a similar tag structure, using the HTML driver will help Git understand where blocks begin and end, providing much better context headers (the @@ ... @@ lines) in your diffs.
Just add this to your .gitattributes file:
*.vl diff=html
Note: This works on GitHub’s web UI as well! GitHub supports the built-in HTML diff rules.
Might deserves a try
yes i know, but my brain cant no more, despite assistance of Claude.
its just a nightmare any time. thank you @antokhio !
You are not going to get anything with good with claude for a resolving a merge errors. The problem is that vl file is autogenerated and quite large, in positive scenario you are still likely going to end up with some broken xml but somewhere hidden.
The general rule here, if you have a conflict on vl file, you always want kepp incoming change (e.g. always use the code from file you are submitting). Otherwise it would break.
There are not so many commands for git you have to know, main are:
git status // Shows the current state of your working directory
git clone // Downloads a copy of a remote repository to your local machine
git checkout -b // Creates a new branch and switches to it
git checkout // Switches to a different branch or restores files
git stash // Temporarily shelves uncommitted changes
git add . // Stages all modified and new files for the next commit
git commit -m // Saves staged changes with a descriptive message
git reset HEAD~ // Undoes the last local commit while keeping the file changes
git fetch // Downloads latest changes from the remote without merging them
git pull origin nameOfBranch // Downloads and merges changes from a specific remote branch
git push origin head // Pushes your current local branch to the remote repository
I barely use any more then that, the key here not to create conflicts, not to fix them.
Here is a short summary on how to minimize and avoid merge conflicts:
- Pull Frequently: Regularly update your local branch with the latest changes from the main branch (
git pullorgit rebase) so your code doesn’t fall behind. - Keep Changes Small: Work in short iterations. Smaller, more frequent commits and Pull Requests are much less likely to clash than massive, weeks-long branches.
- Communicate with Your Team: Coordinate who is working on what. Avoid having multiple people editing the exact same files or functions at the same time.
- Use Feature Branches: Always do your work on isolated, specific branches rather than directly on
mainordevelop. - Standardize Code Formatting: Use automated formatters (like Prettier, Black, or ESLint) across your team. Many “conflicts” are just differences in spaces, tabs, or line breaks.
- Write Modular Code: Break large files into smaller, single-purpose components. If developers are working in separate files, conflicts are impossible.
^^^ This pretty close to what i have in mind…
Might be bit more cumbersome, but try to split your project into more separate vl files, kind of the subpatch way from beta. In best case should also result in more modularity.
And imho this of course is super important:
Thank you @antokhio but definitively its a game i will no more play.
Too much cryptic, too much not adapted to Visual Language Programming.
We add a lot of loose of time energy and money on my project because versioning and comparison tools are not for the moment operational in a visual manner. Git can work on little VL project or with a very fractionized files architecture. It becames a nightmare to inspect diffs that are not showing on whats changing.
That s where people like me, not being coders, began to loose feet in the adventure.
Im pretty sure that in VL we will have at one moment a simple comparison colored node function : opening the project, selecting a folder with a previous version, and comparing architectures of the patch and subpatches with a colored feedback of what is changed : nodes and connections (missing or added).
Only just this would help quickly to work efficiencly. A somewhat Comparison mode functon in Gamma UI.
That would simply ease our lives a lot. What do you think of it @joreg ? is it possible ?
absolutely. on our backlog since many years now. reasons it hasn’t made it up to a top priority yet:
- in large projects with many people involved, so far there’s always been more pressing issues to solve
- the moment you start thinking about it in more detail you notice it will be much more complex to realize than it sounds (like so often)
that said, yes we see the need absolutely have in mind to improve git workflows.
@joreg hum, relying on git sounds for me being dependant on a collaborativ tool far too complex, but yes i understand the need for big professionnal crew !
Would just ease things in my mind a non git based visual patch comparator. Lets say an individual tool that enables to analyse visually what changed between your patch and another folder for a specific version. Sounds for me something reachable, and enable a visual analyse, reading and comprehension, that git will never give. But i understand if this goal is not in your approach (helas).
@tgd yes, we tried a maximum to split in different files to avoid salata. But definitions on a complex model are more easy in an all in one document also. there is a question i have about includes, as little files needs sometimes declaration of a lot of data types. Are including datatypes a redondance in memory ? how is it treated in gamma ? a manager declared in separated files that access to the all model needs to include the all model thought. Is there a simple way ?
all the best
Just to add my 2cents here - we work mainly together using git on projects with multiple team members. For our current project for example we use one big library.vl file containing all resources used by multiple instances. We’ve split the library into multiple categories, each containing individual definitions/patches. With very little communication overhead - git manages to solve conflicts on its own most of the time without even needing any user input (p4merge and MergeVLDocs set as mergetools).
When there is a big conflict, MergeVLDocs handles it. Conflicts where that is needed only arise when multiple people changed the same definition, not the same file. We usually avoid branches except for different featuresets inside a project.
Actual broken files usually only come from wrong usage of the MergeVLDocs, since thats pretty easy to do. We almost all use GitExtensions to handle git for us.
Usually we spend some time when a new project starts figuring out how to best approach it and always keep in mind that multiple persons will work on the project.
So for us the flow of:
- Tell the others “Hey i’m gonna change that”
- Commit the changes
- Tell the others “Hey i commited and pushed”
mainly works.
1 Like
Honestly the key problem here is multiple ppl can’t work on same VL file. Kind off mutiplayer patching prolly one of my dream thingy for VL. But thing is it’s might be possible to have something like this of only if there would be some sort of VL api like one for a code agents. Where you could call VL.CreateProcessDefinition(). There might be other ways around tho…
1 Like
ah thats the main key. can you develop your idea @antokhio ?