3 ms·

On the contrary: I myself have implemented these better operations, and they work great. They also exist in some other VCSes, such as Mercurial and Jujutsu. You

On the contrary: I myself have implemented these better operations, and they work great. They also exist in some other VCSes, such as Mercurial and Jujutsu. You can see the `git-branchless` column in the table for comparison with the other clients. - git reword: https://github.com/arxanas/git-branchless/wiki/Command:-git-reword https://github.com/arxanas/git-branchless/wiki/Command:-git-... - git move will perform the magic "see all downstream conflicts", but unfortunately will only show you the number of conflicting files, at present: https://github.com/arxanas/git-branchless/wiki/Command:-git-move https://github.com/arxanas/git-branchless/wiki/Command:-git-... - You cannot undo arbitrary operations with the reflog (nor with `git reset`). See https://github.com/arxanas/git-branchless/wiki/Architecture#comparison-with-the-reflog https://github.com/arxanas/git-branchless/wiki/Architecture#.... Besides those points, my `git undo` can even undo some working copy changes: https://github.com/arxanas/git-branchless/wiki/Command:-git-undo https://github.com/arxanas/git-branchless/wiki/Command:-git-...

arxanas 4y ago
Apologies, but I misunderstood what you meant by the "downstream" conflict situation. That's not possible in git-branchless, but it is possible in Jujutsu, since it stores conflicts as first-class objects, so it can actually proceed with the application of subsequent patches even if a previous patch conflicted. `git rebase` can be started and aborted, but to start it safely, you have to first set aside all of your existing work in the working copy. You can't really run it on the background or in parallel, which makes it annoying to do operations like rebase all branches, and can ruin build caches, which ends up being a significant problem on larger repositories. It's possible for the UI to show an icon next to each of my branches indicating whether they would rebase onto the main branch successfully, but no interfaces at present do (including my own). Or, for example, I should be able to start dragging a branch to indicate a rebase, and the UI should speculatively check which target branches can be rebased onto successfully and indicate that.

arxanas 4y ago

Apologies, but I misunderstood what you meant by the "downstream" conflict situation. That's not possible in git-branchless, but it is possible in Jujutsu, since it stores conflicts as first-class objects, so it can actually proceed with the application of subsequent patches even if a previous patch conflicted. `git rebase` can be started and aborted, but to start it safely, you have to first set aside all of your existing work in the working copy. You can't really run it on the background or in parallel, which makes it annoying to do operations like rebase all branches, and can ruin build caches, which ends up being a significant problem on larger repositories. It's possible for the UI to show an icon next to each of my branches indicating whether they would rebase onto the main branch successfully, but no interfaces at present do (including my own). Or, for example, I should be able to start dragging a branch to indicate a rebase, and the UI should speculatively check which target branches can be rebased onto successfully and indicate that.