intended workflow when interacting with a git repository, specifically for github PRs where upstream doesn't like you force-pushing

[zygoloid]

My git workflow for github PRs is generally:

• git checkout -b branchname from the main branch, make some changes, git push -u origin branchname
• create a matching github PR
• receive and address some review comments, git commit -a, git push
• github PR is merged, delete my branch (or usually, forget to do so)

What is the expected corresponding jj workflow? The closest I've found is:

• make some changes, jj close, jj branch create branchname -r @-, jj git push
• create a matching github PR
• receive and address some review comments, jj close, jj branch set branchname -r @-, jj git push --branch branchname
• github PR is merged, delete my branch (or maybe it gets autodeleted if it's deleted on github and then I pull?)

The third step in particular seems cumbersome compared to the git workflow, and requires me to keep telling jj which branch I'm working on. Is there a better way?

[martinvonz]

Good question! I know that many (probably even most) GitHub projects want you to address code review comments by adding new commits on top. These projects typically integrate PRs by merging or squashing. In this project, we instead amend commits and try to keep a single commit per logical change and then integrate PRs by rebasing. That matches what e.g. the Git and Mercurial projects require (w.r.t. keeping commits clean - the Git project integrates features by merging), and also what we do internally at Google with the Fig tool. There can still be multiple commits per PR, although I only do that to work around GitHub's poor support for stacked PRs (I still expect each commit to be reviewed on its own). Incidentally, there was a post on GitHub's blog today about the commit-per-logical-change workflow. It's good to see that at least a few people at GitHub care about this workflow.

Since we use the commit-per-logical-change workflow in this project, I typically don't create a branch until I'm ready to send the commit(s) for review, which I the do with jj git push --change @-, which creates a branch based on the Change ID (the second, magenta-colored ID in the jj log output).

To address review feedback, I check out the commit, make the changes and run jj squash/amend and then jj git push --change @- again (or even jj git push to push all branches). If you instead want to name the branch yourself, you can use e.g. jj branch create branchname -r @- as you're already doing (or create the branch before jj close and you can skip the -r @- bit). When you squash/amend, it will move to the rewritten commit, so just jj git push will work.

Once the PR has been merged, I run jj git fetch to propagate the branch-deletion that happened on the remote (as you speculated it might).

Anyway, if the GitHub project you're contributing to uses the squash/merge workflow (where PRs matter and commits don't matter much), I think what you're currently doing is unfortunately the best you can currently do. Well, you could drop the --branch branchname argument if there are no other branches that you don't want to push.

Perhaps we should add a way of having a current branch like Git has. Perhaps being able to do something like jj git push -r <commit> --to <branchname> to basically be a shorthand for jj branch set <branchname> -r <commit> and jj git push --branch <branchname>. Yet another option might be to implement #246 to let you do something like jj branch set <branchname> -r @- followed by jj git push --branch-at @-.

[yuja]

# Start working on a new commit on top of my_pr branch, moving the branch forward to the working-copy commit
jj checkout -b my_pr
<address comment 1>
# Compare to before the fixes
jj diff
# Add a description and continue addressing comments in another commit on top
jj commit -m "address comment 1" --branch
<address comment 2>
# Compare to before the fixes
jj diff --from my_pr@origin
# Add a description. Note that if this is the last commit we're going to make,
# we don't want to use `jj commit --branch` and move the branch forward.
jj describe -m "address comment 2"
# Push the branch pointed to by the working-copy commit
jj git push

My idea is slightly different. There's no explicit active branch because IMHO it wouldn't work well with JJ's working-copy revision.

# Start working on the existing my_pr
jj checkout my_pr
# Add commit
jj commit -m "fix 1"
# Add another commit
jj commit -m "fix 2"
...
# The fixes went well, let's finalize the last commit and move the branch.
# The nearest ancestor branch 'my_pr' will be moved to this commit.
# (If the history isn't linear, or if the nearest revision has multiple branches, 
# the command would fail.)
# Maybe this could be `jj commit` && `jj branch move -r @-`
jj commit -m "fix n" --move-branch
# Push new changes to my_pr branch
jj git push

# Start new feature branch (if you prefer named branch)
jj branch set new_pr
# Add commit: branch 'new_pr' will stay there
jj commit -m "fix 1"
# Add another commit
jj commit -m "fix 2"
...
jj commit -m "fix n" --move-branch
# Push 'new_pr' branch
jj git push

[arxanas]

@arxanas and @yuja, does that match what you were thinking?

I wasn't properly considering how that would interact with the working copy commit (as git-branchless doesn't have one), but I agree with @yuja's proposal above about having a directive to move the nearest ancestor branch to the imminent commit.

It also means that the user needs to remember to pass the --branch/-b flag every time they close/commit.

That's what I would prefer in my workflow. It doesn't matter too much from a technical perspective whether we require --branch and don't move branches by default, or require --no-branch and do move branches by default. To support Git users, we could do the latter, and have lazy-branchers like me opt in via alias or configuration option.

Maybe it makes sense to have a "Git compatibility mode"? On one hand, having dramatically different behavior based on a single option might be risky/confusing, but on the other hand, it would be a lot easier to iterate on the UI without confusing Git users. In particular, I think that branches/tags don't differ enough to warrant separate concepts, and neither do checked-out branches versus non-checked-out branches (which also lead to a host of complexity like symbolic references).

Aside: despite having gone to the trouble of inventing symbolic references, Git actually doesn't work too well with them. For example, I tried to make a symbolic reference master which pointed to origin/master, but this terribly confuses Git, and it starts updating the local/remote branch in places where it shouldn't. Git is pretty much only equipped to handle the case of HEAD being a symbolic reference, and that reference has to have no more than one layer of symbolic indirection. Here's another confusing case where Git inappropriately resolves a symbolic reference: arxanas/git-branchless#149 (reply in thread)

Aside: in #321 (comment), I give a theoretical justification for inferring branches: "...history edges let us infer logical branches, without having to name those branches explicitly. Instead, the branches are determined by the operations you do on the commits." The ability to name branches is still useful, but naming things doesn't work well for conflict resolution in a distributed context. This is why I suggested moving the branches only when you make a new commit: because it matches the model of determining branches via the operations you do on the commits, rather than as entirely separate entities with their own rules.

[martinvonz]

From @chandlerc:

Don't get me wrong, I can see the use cases. I understand how it could be used. I just don't find that to be a motivating workflow. Here I'll go slightly beyond just my personal preference -- almost everyone I have worked with on a team using Git for a significant time has complained about how confusing it is to check out a commit (but not the branch). And none of them have complained about checking out the branch and making it active.

Right, but I believe that the reason they think so is because of how scary Git makes it. There's ~10 lines of instructions for how to escape for from the so-called "detached HEAD" state (a scary name as well). There's of course good reason for that, because it's easy to lose commits that way if you're not experienced enough to use the reflog. Jujutsu (and git-branchless) doesn't have that problem, because anonymous heads are tracked and show up in log output. Despite Git's loud warnings, there are actually people who develop mostly using detached HEAD (I know someone on the Git team at Google who does). I was quite surprised when I learned that six months ago or so. Mercurial also uses anonymous branching in its tutorial.

That said, making the transition as easy as possible for Git users is a very important goal. I'm not saying we should de-prioritize named-branch workflows. I'm just saying that anonymous branching is probably something you'll get used to relatively quickly. As a data point, I think it's actually very few Fig/Mercurial users at Google who use branches/bookmarks.

The only widespread complaint I have heard on teams doing development using Git (as opposed to folks working on VCSes) has been a desire to have something more like git-worktree. The branches aren't the problem there, just wanting to have separate working copies pointing at separate branches.

But git-worktree does exist (as you clearly know), so what are they complaining about? Just that they were not aware of the feature? (Pointing them to separate branches is the only allowed way of using them, IIUC - you're not allowed to check out the same branch in two worktrees.)

From @arxanas:

That's what I would prefer in my workflow. It doesn't matter too much from a technical perspective whether we require --branch and don't move branches by default, or require --no-branch and do move branches by default. To support Git users, we could do the latter, and have lazy-branchers like me opt in via alias or configuration option.

I agree. Defaulting to moving forward any branch(es?) on the working-copy commit sounds good. For people using a branchless workflow, that would still work well if we simply make it allowed to run jj commit without --no-branch (@yuja's --[no-]move-branch is probably a better name) even if there is no branch. I think I like that proposal, so thank you.

So, that would mean this sequence of commands for the named-branch workflow:

# Check out a new commit on top of my_pr and move my_pr to it
jj switch my_pr
# Add commit, moving the branch forward
jj commit -m "fix 1"
# Add another commit, moving the branch forward again
jj commit -m "fix 2"
# Push new changes to my_pr branch, but since `@` is empty, pushes `@-` instead
jj git push

To be clear, this is the no-active-branch solution @yuja and @arxanas suggested. A branch that points to the working-copy commit simply behaves very similar to an active branch in git/hg. This solution means jj edit <branch> would always make it "active" (by virtue of pointing to the working-copy commit), and there would be no jj edit --no-branch, which seems like a good simplification to me.

Maybe we still want a way of creating a new branch and switching to it with a single command, like git checkout -b <new-branch> <start-point>, but that's a detail we can decide on later.

[yuja]

# Check out a new commit on top of my_pr and move my_pr to it
jj switch my_pr
# Add commit, moving the branch forward
jj commit -m "fix 1"
# Add another commit, moving the branch forward again
jj commit -m "fix 2"
# Push new changes to my_pr branch, but since `@` is empty, pushes `@-` instead
jj git push

Pushing @- instead of @ seems fine, but after that, the history would look like:

@ (no description set) my_pr
o "fix 2" my_pr@origin

Doesn't it lead to future branch conflicts?

1. PR merged and the my_pr branch gets deleted by the remote.
2. jj git fetch detects deletion of my_pr, but our my_pr points to @, not to @-.

We could special case a branch pointing to an empty head, but I'm afraid that would cause another confusing behavior.

[martinvonz]

Doesn't it lead to future branch conflicts?

Good catch! Perhaps we could move the local branch to @- as an early step in jj git push, so the local branch and remote branch would point to the same commit. That would be like detaching the branch (in Git speak), but maybe that's fine as long as we tell the user about it so it's not too surprising.