"No-op" merges?

[BatmanAoD]

Often in Git, I want to ensure my feature branch is up-to-date with the trunk, but not make any changes if it already incorporates the tip of the trunk. I generally do this with a merge (though I realize that rebase is also a common strategy).

In jj, it appears that merge always creates a new commit (and somewhat weirdly, it permits the parent commit to be empty, which I expect is a pretty typical case when merging something with @). Is there a way to create a merge commit if and only if none of the parents contain every other parent? I.e. for two parents, the xor of the commit sets isn't empty; for more than two, every parent is "behind" at least one other parent in the Git sense.

[martinvonz]

IIUC what you want, jj new 'all:heads(heads(::@ ~ empty()) | main)' probably does that. What that does:

1. heads(::@ ~ empty()) gives the first non-empty commit(s) that are ancestors of @. Typically that's just one commit, unless you have some merge commits.
2. heads(heads(::@ ~ empty()) | main) gives only the newest commit between the commits from step 1 and main.
3. all: allows you to specify all those commits (typically one or two) as new parents.

Btw, merge is basically an alias for new.

[martinvonz]

I suppose you can define a revset alias like this:

revset-aliases.here = "heads(::@ ~ (empty() ~ merges()))"

Then you can do e.g. jj branch set my-branch -r here or jj new 'all:here|main'. If it turns out to be common for people to define such an alias, we can make it a built-in.

Regarding the all: bit and the desire to not create a merge if one parent is an ancestor of another, #2600 is related to that. As I said on that bug, I think we should actually be better at not dropping redundant ancestors. Perhaps the right solution here is to add a jj git sync command (#1039) and give it a config option to choose between rebase and merge. If configured to merge, it would presumably behave the way you're asking for jj merge to behave. Does that sound good to you?

[BatmanAoD]

Yeah, sync is semantically the operation I want and makes sense here, I think; and it would indeed be helpful if the merge variant of sync behaved this way, especially since it's close to how Git behaves.

[BatmanAoD]

Odd, this worked for me earlier today in one repo, but in another, I'm getting this error:

❯ : jj new 'all(heads(heads(::@ ~ empty()) | master))'
Error: Failed to parse revset:  --> 1:5
  |
1 | all(heads(heads(::@ ~ empty()) | master))
  |     ^----------------------------------^
  |
  = Invalid arguments to revset function "all": Expected 0 arguments
Hint: Prefix the expression with 'all' to allow any number of revisions (i.e. 'all:all(heads(heads(::@ ~ empty()) | master))').


❯ : jj new 'all:all(heads(heads(::@ ~ empty()) | master))'
Error: Failed to parse revset:  --> 1:5
  |
1 | all(heads(heads(::@ ~ empty()) | master))
  |     ^----------------------------------^
  |
  = Invalid arguments to revset function "all": Expected 0 arguments

[martinvonz]

I think you meant jj new 'all:heads(heads(::@ ~ empty()) | master)'. all: is a special prefix, not part of the revset syntax. However, there's also a revset function called all(). That function doesn't take any arguments.

[BatmanAoD]

Oh, you're right; I thought I'd copied the command the same way both times, but I must have done it with all:heads(...) the first time.