Git-branchless: efficiently manage topic branches without switching branches

https://git.sr.ht/~krobelus/git-branchless

1 Like

Very interesting! This looks like it captures the essence of how I want to use git.

I’m trying it out on a throwaway git repo I initialized somewhere in /tmp and I’m a little surprised that @{upstream}.. is hard-coded, not only as a default but as the only reference point. If it was possible to change this as an argument the tool would be more flexible.

When using parents the commit message from the parent includes the [topic]. Also the topic branch is not based on its parent but a copy of it (necessarily so because the commits are different due to the different commit messages) but I would expect it to be from that commit.

Yeah, I’ve been meaning to add a parameter for this, I just never needed it.
I think I’ll add a -r/--range parameter, then it can even be used on branches that are not checked out. EDIT: done

1 Like

Those are good points. I used to have an option to drop the [topic] tags also from parents.

Usually though, I want the tags, to show that the parent commits are from somewhere else (and should not be reviewed here). It might be right to re-add the option, but I’d like to find a more flexible solution. Currently git revise --ref branch-name -i can be used to rewrite messages in that branch, but that’s not ideal either.

With trimmed commit messages, it should branch off the parent, but not when there are multiple unrelated parents. I don’t know what would be the benefit of that, less visual clutter, I guess.

There is also Stacked Git, I haven’t tried it yet tho.

1 Like

@krobelus – is most of your workflow single developer?

No, not anymore. I wrote this because I want to create a branch for every change, but still be able to work on all changes simultaneously.
I also merge others’ branches into it, because that makes it easier for me to review and test.

Ah multiple parents, I suppose in that case the right thing to do is what happens now with single parent.

I realised one interesting thing that could be done with this setup is to suggest parents for topics based on merge conflicts. For a topic that cannot solely be branched of from the reference point the program reports which topics it can be branched from and suggests those as parents. This way you don’t need to figure it out yourself :stuck_out_tongue: Complexity to check this for every topic is just quadratic and given how fast git-revise seems this could be viable.

Yeah, automatically detecting dependencies can be nice, so that’s definitely on the roadmap. Merges are done with git merge-file on temporary files, so when that fails, the tool can figure out missing dependencies. Checking which other commits modified that file could already go a long way. The next step is to run git blame on the lines around the conflict, that can usually detect at least one missing commit.

I’ve re-added the option to always trim the topic tags, I guess it can be useful. Though I use branches with unmerged dependencies only as WIP, so the topic tags are a feature.

I took the opportunity to try this out on a project at work and it was really pleasant to separate commits to different branches, one for a backend PR and one for a frontend PR. I will continue using this, very pleased with the workflow. I’m happy that you added trimming the topic flags. I’m not sure which option I will use more often but I think both can come in handy. Thank you for sharing!

I’ve added naive dependency hints: when a commit fails to apply, it lists all commits that touched the conflicting file and that are not among the dependencies.
This comes at the cost of depending on an unreleased version of git-revise, see the updated installation instructions.
The output format is fairly ad-hoc but usually it’s good enough.