git-imerge
git-machete
| git-imerge | git-machete | |
|---|---|---|
| 12 | 2 | |
| 2,665 | 837 | |
| - | 2.2% | |
| 0.0 | 9.2 | |
| 12 months ago | 4 days ago | |
| Python | Python | |
| GNU General Public License v3.0 only | MIT License |
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.)
git-machete
- Git Machete
-
Pijul: Version-Control Post-Git • Goto 2023
I'm not seeing a git compatibility layer? So I think it's a neat project, but I probably won't try it because nearly all code is rooted squarely in git. Even if Pijul is perfect, you'd need to convince everyone else to use it.
Nevertheless, the increased interest in moving to patch based workflows from branch based ones is great. There's a lot of similar tools here (https://github.com/gitext-rs/git-stack/blob/main/docs/compar...) which I refer to infrequently.
Personally my favorite tool for living-with-the-reality-that-is-branches is git-machete (https://github.com/VirtusLab/git-machete).
What are some alternatives?
jj - A Git-compatible VCS that is both simple and powerful
SemanticDiff - Community support for SemanticDiff, the programming language aware diff for Visual Studio Code.
elasticsearch-py - Official Python client for Elasticsearch
gumtree - An awesome code differencing tool
git-mergify-rebase - Merge git changes one commit at a time.
git-stack - Stacked branch management for Git
pg_similarity - set of functions and operators for executing similarity queries
mergify - Merge git changes on commit at a time.
awesome-structure-editors - A list of projectional and structural editors