Restack current branch, and follow.

[kevincox]

I'm new to git-branchless so maybe I missed an option. But in general I only want to restack the current commit/branch. I don't want to worry about other branches because solving conflicts may be a waste of time as more conflicts might appear as the parent gets modified. For the workflow I want I want to check out a commit or branch, then restack it, and be on the same branch with the new restacked commit.

Something like this seems reasonable:

git checkout my-branch
git restack HEAD

But at this point I am left on the old commit, separated from the branch. Would it be reasonable that if a commit that gets restacked is checked out the checkout follows to the new commit (and branch)?

This problem isn't fundamental. It can be solved just by checking out the branch again. But it is annoying so I thought I would open a discussion about the UX. I see no real reason why someone would want to be left on the old branch.

[arxanas]

Welcome @kevincox!

What version of git-branchless are you using? In recent versions, git restack should decline to restack any stacks which don't merge cleanly, which can work around a lot of the friction. (You have to pass -m/--merge to force merge conflict resolution.)

That being said, I think there's room to improve the interface for git restack, like maybe adding a -a/--all option to restack everything, and only restacking the current commit stack by default. I think the problem with that was that some commands leave you with abandoned commits that aren't descendants of the current commit, such as if you run git rebase and modify an ancestor commit to another sub-branch of the same stack.

In general, for git restack/git move, the checkout should follow the commit. If you have a specific repro case where it doesn't do that, then file an issue and I can look into it. The exception is if the git checkout fails after the operation, in which case the checkout of course wouldn't follow the rewritten commit. (If you install the latest version from source, @bcongdon committed #187 to improve the messaging in case of checkout failure.)

But to back up a moment, I don't think I understand how you're using git restack. Normally, I run git restack after an operation abandoned a commit, such as git commit --amend with descendant commits. But it sounds like you're using git restack before you want to start some work. What are you using it for in that case? Do you often have abandoned commits, and you defer cleaning them up until later?

If you're trying to rebase ("restack") the current commit onto the latest main branch, then git restack actually doesn't do that — you probably want an invocation like git move -d main. (I am working on an implementation of git sync to make this a little easier, and I also need to write documentation for handling this workflow, since it's pretty common.)

[arxanas]

I wrote up my general workflow in more detail at https://github.com/arxanas/git-branchless/wiki/Workflow:-divergent-development. But even with that being written, there's nothing wrong with a delayed-restack approach, like you use.

[kevincox]

How large is the repository you're working with?

Not large. Checkout times are negligible.

[kevincox]

Rather than amend a given patch (I assume that's what you're doing?), I always check it out and start making new WIP patches on top of it, with messages like temp: fix foo, etc. Doing so never causes the descendant commits to be abandoned, since it's a new line of work.

That's an interesting approach. I think the downside here is that often I want to send the parent for review after these fixes and so I need to rebase them into one to publish for review. So at least in the workflows I see to push for review as a rebased set I need to abandon the commits the children reference.

Another ergonomic concern is that it's hard to see what the restack target for a given abandoned is. I suppose it says "rewritten as XXX" above it, but I don't generally spend time verifying that it's the commit I think it is.

I don't think this is a major problem for me because I generally don't care. I know it is some older version. If I think it might be relevant I would probably just rebase to be sure. But most of the time the exact parent isn't too relevant for me continuing development.

I think your workflow should be supported fine (excepting whatever bug you saw), but I just happen not to do it that way. If you encounter additional issues, please continue to report them and I'll see what I can do.

Yeah, I think it should. It would be nice to delay the restack but not critical for my current projects. Even the bug is a minor inconvenience as I could wrap it into a script that checked out the right branch again. Thanks for the tool, it is really improving my workflow.

[JeffFaer]

At the risk of necroing this...

That being said, I think there's room to improve the interface for git restack, like maybe adding a -a/--all option to restack everything, and only restacking the current commit stack by default

I think I'd also want to see that type of behavior with git sync, where by default it only affects the current commit and its parents, and maybe also its descendants. I often have a lot of things going on in parallel, and sometimes I abandon stuff for a while, and I'd rather not have to figure out any merge conflicts (whether they be real file-level merge conflicts or logical merge conflicts where the code will suddenly stop working until it's refactored to work with whatever changes were introduced on main) until I have some spare time to actually dedicate to the task

[arxanas]

@JeffreyFalgout Originally, git sync only synced the current commit stack, but, in that case, there wasn't much difference between doing that and running git move -s 'stack()' -d 'main()'. To support your workflow, I recommend you avoid using git sync directly and either run git sync 'stack()' or git move in some form.

(Honestly, the revset argument to git sync is not that useful, but it's there for consistency.)

[NonLogicalDev]

@arxanas I think it would be invaluable to be able to delay conflict resolution for later. This is one of the big things that I think Stacked Git (https://github.com/stacked-git/stgit) has gotten right.

I can have upwards of 15 different features that are based on top of main branch. Some are experiments that I work off and on. With stacked git I have the ability to restack those changes only when I feel like working on them.

I think Git Branchless has a lot of merits, for one I really like how it handles commit trees. But restacking operation that locks you in a stateful workflow is holding me back from being able to use it effectively.

It feels like Git Branchless could have either git goto --restack or git restack --recursive HEAD (restack all descendants of this commit) to update the commit you are moving to. Otherwise, if you have a lot of stacked changes you might be stuck in a "rebase" workflow for quite a while, and that gets us right back to git rebase issues we are trying to move away from.

Should you have to context switch to a different branch to work on something else or work on a hotfix, you either have to power through conflict resolutions or abort entirely. A more surgical and essentially stateless restack operation (like in Stacked Git) would be a huge boon.

[arxanas]

I can have upwards of 15 different features that are based on top of main branch. Some are experiments that I work off and on. With stacked git I have the ability to restack those changes only when I feel like working on them.

Do you mean that the features are all stacked on each other, or that you have 15 different branches whose common ancestor is main?

If the former, there isn't currently a way to explicitly "cut out" a single commit without attempting to restack its descendants, but you could use this workaround instead: first, run git commit --amend (optionally with --no-edit) to cut out the current commit and leave its descendants abandoned, and then optionally use git move or whatever to move it to its intended destination.

But restacking operation that locks you in a stateful workflow is holding me back from being able to use it effectively.

Which state are you talking about specifically? That commit rewrites are tracked, so that restack knows where to move commits? If so, you can opt to either ignore the "rewritten" annotations in the smartlog, or copy commits instead of moving them with git cherry-pick.

It feels like Git Branchless could have either git goto --restack or git restack --recursive HEAD (restack all descendants of this commit) to update the commit you are moving to.

git restack accepts a commit as an option indicating what to restack, although it represents "The IDs of the abandoned commits whose descendants should be restacked. If not provided, all abandoned commits are restacked", so you'd have to specify the old commit which has been abandoned. (This could be improved if we think specifying the target commit is better). Otherwise, if you want to manually specify which commits to move, you can run e.g. git move -s 'children(<target>)' -d <dest> to rebase them manually.

I also recommend you take a look at Jujutsu, since it can defer conflict resolution arbitrarily, because conflicts are stored in the commits themselves, and therefore rebases always succeed.

[GiorgosAlexakis]

git rerere is your friend

[arxanas]

By the way, these days, you can run e.g. git restack 'stack()' to restack only rewritten commits in the current commit stack; see https://github.com/arxanas/git-branchless/wiki/Reference:-Revsets