compatibility with GUI / stock git?

[benblo]

So git branchless looks interesting!

I came here because I'm in the middle of a complicated history rewrite (filter-repo etc), and found the stock rebase lacking (even with --rebase-merges), and git move looks like a promising replacement.

But, I'm not sure I'm ready to opt-in, the cargo installation and git-branchless wrap -- alias are a bit scary. Am I right to assume that this is not a one-way street: once all is pushed, this is still a standard git repo (right?), and I can abandon branchless if I want to.

Also, I primarily use git via GUI (SmartGit ftw): would branchless interferes with that? or would any GUI need to know about it? ie what of in-memory stacks etc.

[claytonrcarter]

the cargo installation and git-branchless wrap -- alias are a bit scary

Hi! Both of these are optional. You can use all of the branchless tools w/o wrapping git. You'll just have to refer to them explicitly: git branchless move ... instead of git move ... and so on.

Although cargo is the recommended installation technique, you can also check the package manager for you OS. At least for mac, I just checked and Homebrew will install the latest release (at this time 0.6.0, though it looks like 0.7.0 is coming soon).

this is not a one-way street

Correct. branchless is just a bunch of tools that interact with your existing git repo to augment your workflow. If you want to uninstall, git will be none the wiser afterwards.

would branchless interferes with that?

I suppose that it will depend on the tool, but I use GitX quite a bit and it works fine ... it's still just a git repo after all. The two slight friction points that I have personally encountered are:

1. branchless prevents garbage collection of "branchless" stacks by creating custom refs for each commit it encouters. I've not ever noticed these when working in the terminal, but any tools you use that indiscriminately render all refs may become a little obnoxious with all of the additional refs being drawn. For an example in GitX, see Hiding `ref/` labels? gitx/gitx#247.
2. branchless makes it very easy (and not scary) to work on a detached HEAD. Not all tools handle this well. For example, GitX will only render ancestor commits of the current HEAD, unless there is a branch pointer somewhere downstream. This just means that I can only see the parents of HEAD, not the children.
   • This isn't just GUI tools though. git-absorb won't run on a detached HEAD unless you pass the --force flag, and I still haven't found a way to get almighty magit to show the log for the current stack.
   • My experience so far is that these are all only minor annoyances.

[arxanas]

Thanks for a great answer, @claytonrcarter! I don't use Git GUI tools often so I'm not familiar with the problems in practice. To add some more detail:

would any GUI need to know about it?

For reading information from your repository, as long as you are using a primarily branch-based workflow, then everything should just work. In git-branchless, it's possible to work with commits that aren't reachable by any branch, which won't show up in most GUIs, but that probably won't happen if you keep your workflows otherwise the same.

For writing information, it's possible that the GUI implements its own versions of some operations like rebasing/amending but doesn't invoke the post-rewrite hook. In that case, git-branchless may show duplicate/old versions of certain commits, because it won't have been informed that the commits were rewritten. There's not much we can do about this; you should file a bug to the GUI client vendor in that case. I don't recall having seen this behavior in a specific GUI client.

ie what of in-memory stacks etc.

For in-memory rebases, git-branchless will also move the branches pointing into that stack as appropriate. Git GUIs will be able to view the new locations of the branches without any issues.