git-imerge
gumtree
git-imerge | gumtree | |
---|---|---|
12 | 6 | |
2,665 | 861 | |
- | 1.3% | |
0.0 | 8.2 | |
12 months ago | 8 days ago | |
Python | Java | |
GNU General Public License v3.0 only | GNU Lesser General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
git-imerge
- Dealing with Diverged Git Branches
- Pijul: Version-Control Post-Git • Goto 2023
-
Save rebase progress and attempt to cherry-pick?
Afaik, there's currently no official way to pause/stash a rebase/merge-in-progress. (There is git-imerge which supports incremental merges/rebases (basically split a big merge into smaller ones), but I never used it and think you'll need to use it from the start of a merge/rebase.)
-
I have a feature branch that is now way behind it's remote parent. How do I make this work?
Try git imerge.
-
What is the best way to undertake a heavyweight merge (dozens of files)?
If the merge is large in the number of commits involved git imerge may be useful to you. It breaks down one big merge into many smaller merges, essentially merging one new commit from each branch, one at a time. The advantage being that you only ever need to consider the conflict between two individual commits at a time.
- Git-imerge: Incremental merge for Git
-
strategy to update 2yo feature branch off of develop
The repo for it is https://github.com/mhagger/git-imerge and the blog post / instructions is at https://wilsonmar.github.io/git-imerge/
- interactive merge in git
-
Jujutsu – A Git-compatible DVCS that is both simple and powerful
Similar ideas have been discussed before in Git, but I don't think anyone has acted on them much. Michael Haggerty's git-imerge tries to make conflicts shareable, but I think it was more of a side-effect of the original goal of optimizing rebase/merge and auto-reducing conflicts to their minimal representation. I'm very curious how conflicts are represented in Jujutsu so I can better understand this power. I'm curious about how conflicts in conflict-resolution commits are handled and other such magic.
That gist seems like a simplified version of https://github.com/mhagger/git-imerge, so check that out if you haven't. (I haven't looked at git-imerge in a long time, so I should read about it again myself.)
gumtree
-
Pijul: Version-Control Post-Git • Goto 2023
I'm not familiar with Pijul, and haven't finished watching this presentation, but IME the problems with modern version control tools is that they still rely on comparing lines of plain text, something we've been doing for decades. Merge conflicts are an issue because our tools are agnostic about the actual content they're tracking.
Instead, the tools should be smarter and work on the level of functions, classes, packages, sentences, paragraphs, or whatever primitive makes sense for the project and file that is being changed. In the case of code bases, they need to be aware of the language and the AST of the program. For binary files, they need to be aware of the file format and its binary structure. This would allow them to show actually meaningful diffs, and minimize the chances of conflicts, and of producing a corrupt file after an automatic merge.
There has been some research in this area, and there are a few semantic diffing tools[1,2,3], but I'm not aware of this being widely used in any VCS.
Nowadays, with all the machine learning advances, the ideal VCS should also use ML to understand the change at a deeper level, and maybe even suggest improvements. If AI can write code for me, it could surely understand what I'm trying to do, and help me so that version control is entirely hands-free, instead of having to fight with it, and be constantly aware of it, as I have to do now.
I just finished watching the presentation, and Pijul seems like an iterative improvement over Git. Nothing jumped out at me like a killer feature that would make me want to give it a try. It might be because the author focuses too much on technical details, instead of taking a step back and rethinking what a modern VCS tool should look like today.
[1]: https://semanticdiff.com/
[2]: https://github.com/trailofbits/graphtage
[3]: https://github.com/GumTreeDiff/gumtree
-
We should format code on demand
There’s also gumtree: https://github.com/GumTreeDiff/gumtree/wiki/Languages
- Difftastic: Syntax-aware structured diff tool
-
A New Era for Mechanical CAD
GumTree does AST level diffing, hypothetically one could build VCS on top of that. That would work for binary files as long as they are parseable to some sort of sensible AST.
https://github.com/GumTreeDiff/gumtree
- Gumtree: A neat code differencing tool
-
What comes after Git? It's been 15 years since it was created. SVN was created 5 years before Git. CVS was 15 years before SVN
There are a few AST-based diffing programs e.g. GumTreeDiff. I haven't tried any of them though.
What are some alternatives?
jj - A Git-compatible VCS that is both simple and powerful
difftastic - a structural diff that understands syntax 🟥🟩
elasticsearch-py - Official Python client for Elasticsearch
locust - "git diff" over abstract syntax trees
git-mergify-rebase - Merge git changes one commit at a time.
git-bug - Distributed, offline-first bug tracker embedded in git, with bridges
pg_similarity - set of functions and operators for executing similarity queries
diffr - Yet another diff highlighting tool
mergify - Merge git changes on commit at a time.
apheleia - 🌷 Run code formatter on buffer contents without moving point, using RCS patches and dynamic programming.
pre-commit - A framework for managing and maintaining multi-language pre-commit hooks.