FR: When using jj edit instead of jj new set HEAD@git to @ instead of @- (and preferably to a symbolic branch name)

[EBNull]

Is your feature request related to a problem? Please describe.

tl;dr: I need to manually change / deal with / track HEAD@git due to local tooling shortcomings and I'd like jj to help by setting HEAD@git for me to a symbolic branch name (if it exists) as I call jj edit.

I use Jujitsu in a colocated git repository. Jujitsu thus maintains the HEAD@git ref as the parent of my jj working copy at all times via

jj/lib/src/git.rs

Lines 923 to 925 in 47c010f

	/// Sets `HEAD@git` to the parent of the given working-copy commit and resets
	/// the Git index.
	pub fn reset_head(

.

My workflow typically maintains a local jj structure that is rooted at main@git. I treat children of this commit as github PRs / published work (using the stacked commits workflow). These children are the basis of an empty merge commit that I call public containing all these sibling changes (that also have branches matched to a github PR). I then typically have a few more commits or trees stacked above public containing some WIP work that is not ready to have a PR.

When I'd like to run an integration test / push to a staging environment with all my collected changes I use the empty public merge commit as it represents a union of what I'll expect to eventually be stacked onto main@git in the future.

Local CI tooling I don't control assumes:

• that I am on a branch
• requires a clean git working copy
• tries to run git operations (including pushing and pulling).

This tooling fails currently because:

• While jj sees the working copy as on the public merge commit, git@HEAD is an arbitrary parent of my working copy
  • Hence git sees a dirty working copy (containing other parent changes), meaning my tool refuses to run.
  • I can work around this by jj new public to switch to an empty child which then sets HEAD@git to what jj calls public.
• I'm on a detached head, and this tooling really wants to be on a real git branch.
  • I can git checkout public to change git's view of its HEAD (the contents of $(git rev-parse --git-dir)/HEAD) from a sha1 hash to ref: refs/heads/public.

Describe the solution you'd like
I would like jj to set HEAD@git to the branch name of the current revision of the current working copy's change, if it exists, or the detached head sha1 when I run jj edit (rather than jj new).

Describe alternatives you've considered
It could be an option to do the above, or I could use a local alias, or maybe a hook...

[yuja]

Since jj doesn't track whether the current working commit is edit-ing or checked out (by jj new), it wouldn't be easy to export HEAD@git to different place. (It could be hacked one time by jj edit, but subsequent working-copy snapshot might break the assumption.)

One thing we can fix without changing the underlying data model, I think, is to update the Git index to the merged parent tree (not to the first parent) so the previous merge operation made by jj is staged.

The detached head stuff is discussed several times, and #2338 is the latest one I suppose.