Feedback for the experimental advance-branches feature

[emesterhazy]

Please leave any feedback that you have for the experimental advance-branches config setting added in

• Implement FR #2338 for current branches / automatically advancing branches #3129

This feature should be available in the next (0.17) release or today if you build from source at head.

---

Update from ilyagr:

Here is a sample configuration from the PR description linked above:

[experimental-advance-branches]
enabled-branches = ["glob:*"]
disabled-branches = ["main", "glob:push-*"]

If/when there are more docs, it might be nice to link them here.

[emesterhazy]

There were a few open questions from a discussion on the PR.

1. Should we do nothing if there are multiple branches eligible to advance?
2. Should we only advance a branch if there isn't already a branch pointing to the target commit?
3. Should we add a special case for new commits with multiple parents (aka merges) at moves a branch to the merge commit?

Feel free to share your thoughts on these as well.

[Cretezy]

Are docs going to be ready for the 0.17 release? I could take up writing or reviewing them.

[emesterhazy]

I wasn't planning to include this in the release notes since it's an experimental feature, but perhaps it's not a bad idea. There might be some additional polish we want to do first though, such as the split issue raised below.

[BatmanAoD]

One other issue I've noticed: split should probably move the branch forward, so that it's still at @- after the operation is done.

[bnjmnt4n]

Related issue: #3419.

[tp-woven]

Thanks for implementing this @emesterhazy!

Just wanted to chime in on the @ vs @- discussion:

Whether or not to advance to @ or @- doesn't actually make much difference in the code. I can add another config option to control that behavior.

I am very much in favor of advancing to @. This is because my workflow usually looks like this:

1. jj co main -m"working on whatever" (or sometimes without the message, and I run jj describe later)
2. Change some code
3. jj git push --change=@
4. Iterate 2+3 until ready for review
5. Get PR comments
6. jj new -m"address pr comments"
7. jj branch set <branch name> <- ideally, this shouldn't be needed
8. Change some more code
9. jj git push <- pushes @
10. Iterate 8+9 until ready for merge

I guess most folks use the squash workflow and continually push their changes down, in which case @- makes sense, but personally I prefer this (mostly to make it easier to see diffs in IDEs, etc.)

EDIT: Added steps 4 and 10 for clarification

[BatmanAoD]

This feature certainly can't help with forgetting to create the branch, of course.

Why not just adopt a squash-based workflow, rather than advocating for this feature (which is already arguably supporting a niche use case, per those prior discussions) to work differently?

[BatmanAoD]

To put it differently, you are effectively using a squash-like workflow, in that you are repeatedly modifying an existing commit. From the perspective of the final commit history and the sequence of commits seen on the remote, there's no difference between what you're doing and repeatedly squash-ing. Why not just embrace that?

[tp-woven]

This feature certainly can't help with forgetting to create the branch, of course.

No, but the branch is already created by jj git push --change=@. This feature can help with forgetting to update it.

Why not just adopt a squash-based workflow

The main reasons I work on the commit itself rather than squashing are shell and IDE integrations - I prefer to see the status/diffs of the "whole" commit while I work, rather than "what I changed since the last squash".

[BatmanAoD]

Ah. This draft MR would resolve that, I think: #3405

[tp-woven]

Oh, nice! That could be really useful!

[amiryal]

Thanks @emesterhazy, it’s a very welcome ergonomic improvement!

• Should we do nothing if there are multiple branches eligible to advance?

Advance all of them.

• Should we only advance a branch if there isn't already a branch pointing to the target commit?

For jj commit: this sounds like a situation that can only happen in the edit workflow, for which the use case of advance-branches is not clear to me to begin with. If anything, then the branch pointing to the target (old @) should advance to the new @.

For jj new: forgive me, but I do not see the use case for advance-branches at all. Can we add a configuration to limit this feature to jj commit only?

• Should we add a special case for new commits with multiple parents (aka merges) at moves a branch to the merge commit?

Advance from the first parent only, maybe? Tough question; it could be another configuration toggle.

[BatmanAoD]

The open questions were actually the result of a discussion about how to handle merges. In the current implementation, there's no good way to merge two "advanceable" branches and only advance one of them.

The "only advance a branch if there isn't already a branch pointing to the target commit" idea was suggested so that users could explicitly select which branch to advance:

jj new <branch1> <branch2>
jj branch set <branch1> -r @
jj branch commit -m "merge <branch2> into <branch1>"

For jj new: forgive me, but I do not see the use case for advance-branches at all. Can we add a configuration to limit this feature to jj commit only?

jj commit is effectively just jj new, except that -m (if provided) targets the old commit rather than the new commit. I don't know if it's possible or desirable to further differentiate their behavior.

Advance from the first parent only, maybe?

If I understand correctly, there's not really a "first parent" in the JJ commit metadata, but yes, advancing the first listed parent listed in the new command itself is the proposal in question. (Originally suggested here.)

[allancalix]

This is a great quality of life feature thanks for adding this! One thing I want to note as I set this is I wanted to have some sensible global defaults (only advance on branch with some pr glob convention) and disable on main.

I then set jj config set --repo experimental-advance-branches.enabled-branches '["main"]' on a repo where I push directly on top of main but the enabled-branches in the local config and disabled-branches in the global config conflicted. It's not that obvious how these config options get merged together and will behave as a result.

I just ended up setting both options locally but a couple ideas come to mind:

• log a warning if matching branches are in both enabled and disabled sets
• enforce in the config option that both options be set at the same level

Either way I think the flexibility here is awesome, especially with the glob support.

Here's what I ended up with for reference:
Shell function to override per repo
Global options preventing this behavior on main

[BatmanAoD]

Intuitively, I'd expect it to work as follows:

Start with globally enabled branches, subtract the globally excluded branches, add the locally enabled branches (ignoring global exclusions in case of conflict), subtract locally disabled branches.

Or, equivalently (and probably closer to an actual implementation), for any given branch name:

• Match against local exclusions. If there's a match, stop; don't advance.
• Match against local inclusions. If there's a match, stop; do advance.
• Match against global exclusions. If there's a match, stop; don't advance.
• Match against global inclusions. If there's a match, advance.
• Otherwise, don't advance.

Of course this could be extended to more than two levels of configuration.

[amiryal]

Are there any thoughts about extending this feature to jj rebase? If some branches point to @- before the operation, and that commit gets rebased away from @-, then any advance-eligible branches should remain at the new @- (instead of being moved to the rebased commit). This behaviour would be especially handy when shuffling the order of commits within the same line of work with jj rebase -r x -B y, always keeping the branch pointing to the last commit in the chain.

[emesterhazy]

That's an interesting suggestion. I think the core of the issue is that branches in jj don't really work the same way that branches work in Git, and I'm a bit apprehensive about trying to make them work the same way in all or most cases. If we add too many differences we'll end up with two fundamentally different branch models, and I'm not sure that's a good idea.

I wonder how this same issue would look with topics (#3402). Maybe it wouldn't be a problem because all of the commits would be tagged for the same topic before and after the rebase and the push algorithm would figure out where to set the branch for git compatibility.

[amiryal]

I was not aware of the Topics effort, thanks! I agree, branches as they exist today in jj are really just bookmarks (and not so good ones at that), and their main power today is for Git interoperability.

So, when thinking about how auto-advancing branches should behave, one needs to keep in mind the Topics discussion, because I also agree that it would make sense for the topic bookmark→git branch to “remain where it should be”, relative to the topic.

[NoahTheDuke]

I read the above and didn't see this, so apologies if it was already covered.

I've tried this out, and the one issue I have is that if I have a branch b1 off main, and I have config enabled-branches = ["*"], when I run jj commit -m "new change" on b1, it advances main as well, no matter how far back main is. This makes it mostly useless for me as I make all of my new changes off main but I want to advance main only when I commit directly to it or when I merge.

I'd prefer if the functionality only advanced the first branch found by looking backwards along the commit graph. That way, I can have aaa (main) --> bbb (b1) --> ccc (HEAD), and then I type jj commit and now it's aaa (main) --> bbbb -> ccc (b1) --> ddd (HEAD). If it's aaa --> bbb (main) (b1) --> ccc (HEAD) and I type in jj commit, then moving both makes sense.

[BatmanAoD]

I actually thought this did only look one commit back, but I hadn't tested that. I'm not sure going back more than one commit is wrong, though.

To prevent auto-advancing trunk branches, you should configure disabled-branches = ["main", "master"].

[emesterhazy]

It should only look one commit back and advance the branch at @- to @ before the new commit is created. I'm not sure exactly what is happening in your case, but it sounds like either a misconception about how the feature works, or a bug in the implementation.

Can you replicate the issue and copy and paste the output of the jj commands to show the graph before and after the commit?

[ilyagr]

I am trying this out for a while, and it's been mostly good so far. However, I just have had one bad experience with experimental-advance-branches, though in a pretty messy situation. I think I have to disable it :(

Setup: I have three branches, forget-local, bug3223, and changeid that I'm working on, and a merge of them called ilya2 that I use to compile my personal version of jj. Whether this is a thing of beauty or horror, I leave it up to the reader:

My config is:

[experimental-advance-branches]
enabled-branches = ["glob:*"]
disabled-branches = ["main", "gh-pages"]

Problem: Now, I jj new ilya2 without any intention of moving branches. However, all the branches move confusingly:

I'm guessing this is the experimental-advance-branches's fault, but it doesn't seem essential to the "advancing branches" functionality, so I hope it's fixable.

Update: I thought that maybe adding ilya2 to disabled-branches would help (this would make sense for my setup regardless of whether it helps with this problem), but it did not help with this problem.

[BatmanAoD]

Maybe I'm misunderstanding, or you wrote something different from what you meant, but no, edit updates the working copy based on jj's (and potentially git's) internal state; never the reverse.

[spoerri]

When using jj edit, even jj status causes the working copy to be “applied”, to rebase subsequent commits.

[BatmanAoD]

Oh, I see, you're saying that after setting the working copy to be an existing commit using jj edit, snapshotting the working copy (with any jj command) will cause the descendants to be rebased.

I'm still not sure how this is analogous to advancing branches. The branches are only ever part of the backend internal state, not the files in the working copy.

[spoerri]

after setting the working copy to be an existing commit using jj edit, snapshotting the working copy (with any jj command) will cause the descendants to be rebased.

That's right.

not sure how this is analogous to advancing branches

1. We have a precedent for updating some repo state automatically from the working copy, triggered by any jj command. This is actually more compelling to do for advancing branches than for rebasing! The whole character of branch advancing is automatic. Rebasing is more surprising, so if we're happy to rebase automatically on any jj command, we should certainly be happy to do it for advancing branches.
2. Advancing branches should work for the actual jj edit case too. There's no justification for jj to rebase descendants but leave branches pointing to stale commits (aside for implementation priority of course)

To be clear: this would obviate jj commit, and can cleanly support a clean workflow:

jj new -m "cool feature"
... hack hack ...
jj git push -r @     # automatically advance branches to @ first

And that makes "-r @" an attractive default for jj git push, just like for many jj commands.

[BatmanAoD]

I guess I'm just fundamentally not understanding what problem you think this would solve. So far most of the issues have been from people seeing branches be advanced that they didn't want to advance. If the branch automatically advanced while pushing, there wouldn't be any opportunity to even check that what you're pushing is what you want to push.

[BatmanAoD]

One issue that has come up a couple times for me now, and seems like it might be a bug: if you have a bookmark that is one commit ahead of another, and you use new to "switch" from the one behind to the one ahead, it updates the branch that's behind, which doesn't seem correct to me.

Demo:

❯ jj bookmark create stay-behind
Created 1 bookmarks pointing to yrsssxum b0f767e1 stay-behind | (empty) (no description set)

❯ jj commit -m"stay-behind commit"
Working copy now at: syyxzlyp a6b46978 (empty) (no description set)
Parent commit      : yrsssxum 5ff6a440 stay-behind | (empty) stay-behind commit

❯ jj bookmark create one-ahead
Created 1 bookmarks pointing to syyxzlyp a6b46978 one-ahead | (empty) (no description set)

❯ jj describe -m"commit that is one ahead of stay-behind"
Working copy now at: syyxzlyp 9f1956a4 one-ahead | (empty) commit that is one ahead of stay-behind
Parent commit      : yrsssxum 5ff6a440 stay-behind | (empty) stay-behind commit

❯ jj new stay-behind
Working copy now at: pxsonutv 97372339 (empty) (no description set)
Parent commit      : yrsssxum 5ff6a440 stay-behind | (empty) stay-behind commit

❯ jj new one-ahead
Working copy now at: wqyqkuyx f8ef382e (empty) (no description set)
Parent commit      : syyxzlyp 9f1956a4 one-ahead stay-behind | (empty) commit that is one ahead of stay-behind

Note that after jj new one-ahead, stay-behind is now on the same commit as one-ahead.

[nilskch]

@emesterhazy I would have expected that the new change/commit has the bookmark of the previous commit.

I assume you are using jj commit all the time and never jj new ? :D This feels more natural with jj commit, but it does not feel natural with jj new in my opinion.

The tests assume that jj desc + jj new == jj commit, but I think this assumption is wrong here. I want to always push the @ commit, not the one before.

Your design leads to unexpected behaviour to people like me who use jj new:

What do you think?

[bnjmnt4n]

See #3129 (comment).