What does HackerNews think of git-branchless?
High-velocity, monorepo-scale workflow for Git
Meta's Sapling (1) is definitely one of them. But there is also `jj` (2) and `git-branchless` (3). These tools target a smaller set of workflow where there is 1 main branch inside a big repo and everything else are short-lived branch/topic that could be treated as ephemeral stack of patches, constantly being uproot / rebase on top of the main branch to derive final result.
If that's the workflow you use daily, then you should give these tools a try.
(1): https://github.com/facebook/sapling (2): https://github.com/martinvonz/jj/ (3): https://github.com/arxanas/git-branchless
The author is apparently behind[1] a sucessful alternative UI to Git. It seems safe to assume that they are way beyond merely getting a feel for the Git model.
The Bad-UX denialism has really gone too far when authors like that are dismissed over the old You Just Have To Understand The Model talking point.
Its design is inspired by Sapling, and, in fact, it uses some of the same code, such as the segmented changelog implementation. Possibly some of its ideas made their way back to Meta, such as interactive undo?
Jujutsu also supports colocated Git repositories: https://github.com/martinvonz/jj. It also has the working-copy-as-a-commit idea and conflicts are stored in commits (so rebases always succeed). I think it's a step forward compared to git/hg/sl.
Sometimes this doesn’t happen in which case you end up need to split your commit at the end. This is where git utterly fails. You end up needing git split and git absorb to make this productive.
Git split let’s you select which chunks in a commit should belong to it and then splits that into a commit and then you do it again and again until you have lots of commits. You’ll still need to probably test each one but the majority of the work is done
Git absorb takes changes on the top of your stack and magically finds which commit in your stack the each chunk should belong to and amends it to the right commit
You also need git branchless https://github.com/arxanas/git-branchless as it lets you move up and down the stack without needing to remember so much git arcana.
It's currently a few lines, looks for the branches and commits based on some strings, and prepares a bash script to run the gh cli to open PRs that are chained/stacked together. Was looking at these for reference.
- https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/ - https://github.com/arxanas/git-branchless - https://cli.github.com/manual/gh_pr - https://github.com/arxanas/git-branchless/discussions/45 - https://github.com/stacked-git/stgit/ - https://stackoverflow.com/questions/26619478/are-dependent-p... - https://gist.github.com/Jlevyd15/66743bab4982838932dda4f13f2...
And was hoping for something simple-ish.
To rebase your commit stack on top of the main branch, use `git sync` instead of `git merge`. Merge commits often make it so that you have to resolve conflicts multiple times.
It's worth noting that, in principle, there are cases where the reflog will have never observed a branch move. The reflog we usually look at is that of HEAD; if HEAD did not have the branch checked out when it moved, then that information will be lost. (For example, if you run `git branch -f my-branch abc123`, the branch will be forcibly reassigned without having been checked out.) See https://github.com/arxanas/git-branchless/wiki/Architecture#... for more details.
(arxanas shared a link to my project elsewhere in this thread :))
It primarily supports a patch-stack workflow, but largely using your existing Git workflows. (There is no difference between a patch and a commit, for example; patch identity is implicitly tracked using Git's `post-rewrite` hook.)
To modify the order of patches, you use `git rebase -i`. To modify a patch's content, you can check it out directly and amend it (which will update the descendant patches). To rebase onto another ref, you use `git move`; if it doesn't apply cleanly, then it aborts the operation without ever touching your working copy, unless you pass `--merge` to force conflict resolution.
https://github.com/arxanas/git-branchless
based off of the branchless Mercurial workflows at large companies such as Google and Facebook
I'm intrigued by this but the readme could maybe use some work to describe how you envision it being used day-to-day? All the examples seem to be about using it to fix things but I'm not at all clear how it helps enable a new workflow.
Even if it was just a link to a similar tool?