git-stack VS jj

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).

This is huge. I've wasted so much time on this, I wrote my own tool. No idea how thoroughly they've implemented this though (what all corner cases does it update or not)

> Probably some arcane git magic to (interactively) rebase branch

There is not really a command for that yet, short of adding a bunch of `exec` steps to your interactive rebase manually. See https://news.ycombinator.com/item?id=32217204 for an upcoming command.

You might enjoy using https://github.com/gitext-rs/git-stack, which specifically tries to let you manage stacked branches locally while not exposing tons of PRs to your coworkers.

git-branchless itself also lets you manage stacked branches in various ways. For example, you can do `git checkout `, `git commit --amend`, and then `git restack` to rebase all the descendant branches sensibly. You can use it on the local side of things only and then use Github PRs as normal.

I've been using termtree in my applications but I'm needing something more like git log --graph for git stack but haven't found a general purpose one (there is an implementation inside of git branchless) and haven't had a chance to make one myself.

Got a comparison of tools in this space at https://github.com/gitext-rs/git-stack/blob/main/docs/comparison.md

I try to keep the number of branches down but git-stack provides something like git log --graph that collapses branches from other users and old branches, keeping the main view clean.

Checkout https://github.com/gitext-rs/git-stack/blob/main/docs/compar... (note, the tool hosting this page is not included but as the author).

As the author of git stack, with all relevant biases, I recommend

- git stack for automating what you are already doing

- git branchless for more power at the risk of incombatibilities because its only as good as the data fed to git hooks

- jj if your open to something very different

Jujutsu is along the lines of what you describe: https://github.com/martinvonz/jj

You can drop it in and work seamlessly from git repos

Pull Requests (or Merge Requests) are merged only when (1) all of the automated tests pass; and (2) enough necessary reviewers have indicated approval.

Git doesn't tell you when it's necessary to have full test coverage and manual infosec review in development cycles that produce releases, and neither do Pull Requests.

https://westurner.github.io/hnlog/#comment-19552164 ctrl-f hubflow

It looks like datasift's gitflow/hubflow docs are 404'ing, but the original nvie blog post [1] has the Git branching workflow diagrams; which the wpsharks/hubflow fork [3] of datasift/gitflow fork [2] of gitflow [1]has a copy of in the README:

[1] https://github.com/nvie/gitflow

[2] https://github.com/datasift/gitflow

[3] https://github.com/wpsharks/hubflow?tab=readme-ov-file

https://learngitbranching.js.org/ is still a great resource, and it could work on mobile devices.

The math of VCS deltas and mutable and immutable content-addressed DAG nodes identified by 2^n bits describing repo/$((2*inf)) bits ;

>> "ugit – Learn Git Internals by Building Git in Python" https://www.leshenko.net/p/ugit/

SLSA.dev is a social construct atop e.g. git, which is really a low-level purpose-built tool and Perl and now Python porcelain.

jj (jujutsu) is a git-compatible VCS CLI: https://github.com/martinvonz/jj

"Ask HN: Best Git workflow for small teams" (2016)

You will probably like Jujutsu, which takes much inspiration from Mercurial: https://github.com/martinvonz/jj

It isn't a 1-to-1 clone, either. But tools like revsets are there, cset evolution is "built in" to the design, etc. There is no concept of phases, we might think about adding that, but there is a concept of immutable commits (so you don't overwrite public ones.)

It also has many novel features that make it stand out. We care a lot about performance and usability. Give it a shot. I think you might be pleasantly surprised.

Disclosure: I am a developer of Jujutsu. I do it in my spare time.

I have created a discussion. Thank you both

https://github.com/martinvonz/jj/discussions/2691

> why don't version control systems (especially ones that can change history) have undo/redo functionality out of the box?

It's true. And Jujutsu has undo functionality out of the box, too. It's not just Sapling. :) https://github.com/martinvonz/jj

Git made the only choice a popular VCS can make. History rewrites will exist, period. If you're opposed to history rewrites, then git gives you the tools to ensure the repos you control are not rewritten, and that's all it can do in a world where people have control of their own computers.

If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil, and that's fine. People will do what they want on their own computer, and I think it's morally wrong to try and stop that.

Another user in this thread linked to jj [0], an alternative git client that does some pretty weird things. For example, it replaces the working tree with a working commit and commits quite often. I like git and that seems weird to me, but I'm not offended, people can do what they want on their own computer and I have the tools to ensure repos under my control are not effected. That's all I can hope for.

[0]: https://github.com/martinvonz/jj

I recently found out about another project called jj: https://github.com/martinvonz/jj. It takes inspiration from Pijul and others but is git-compatible.

https://github.com/martinvonz/jj

I think maybe both fossil and bitkeeper are more intuitive too.

Did you try any of those?