jj-vcs
Add command for recovering from sibling operation in working copy
Checklist
If applicable:
- [ ] I have updated
CHANGELOG.md - [ ] I have updated the documentation (
README.md,docs/,demos/) - [ ] I have updated the config schema (
cli/src/config-schema.json) - [ ] I have added/updated tests to cover my changes
If we call the flag --no-publish-operation, then jj op publish would make more sense. Plus, it avoids using the word "commit" which might be confusing (someone might ask, "What is a 'commit transaction'?").
If we call the flag --no-publish-operation, then jj op publish would make more sense.
Just to clarify, you're implicitly saying that you would not like --no-integrate-operation as much, right?
Yeah, my immediate thought was that it should be jj op commit because I think in terms of transactions, but that obviously has confusion with eg git commits. I dislike both jj op integrate and --no-integrate-operation because "integrate" is a brand new term for something that doesn't feel like it needs a new term (jj probably needs something new, but it can adopt something from another terminology like that of transactions). "integrate" also makes me wonder what all it's doing. "incorporate" is a little better, but sounds worse.
Put my vote down for jj op publish and --no-publish-operation. It's not a perfect fit, so I'd also go for jj op merge and --no-merge-operation, or "graft". (Both "merge" and "graft" are new terms, but at least they're borrowing from VCS terminology.)
To be fair, "integrate" isn't awful either.
The idea is that the command integrates/adopts the changes in the given operation (and any ancestors that were not already integrated) into the operation log. I'm of course also fine with "publish". I think it makes sense to say that publish the operation in the operation log.
I'll rename it jj op publish in a day or so if I don't hear anything more.
Just to clarify, you're implicitly saying that you would not like
--no-integrate-operationas much, right?Hmm, that's probably good too, as long as they match.
@jennings: It looks like you replied to me by editing my comment. I've made the same mistake before :) Just highlighting it here so your reply doesn't go unnoticed.
@jennings: It looks like you replied to me by editing my comment. I've made the same mistake before :) Just highlighting it here so your reply doesn't go unnoticed.
Oops, sorry and thanks! 🐑
The idea is that the command integrates/adopts the changes in the given operation (and any ancestors that were not already integrated) into the operation log. I'm of course also fine with "publish". I think it makes sense to say that publish the operation in the operation log.
Right, I understand. To me, this is more like a "merge" action. "Publish" is ok and matches the code, but implies only "make it visible" to me. I'd half expect to end up with multiple visible op heads that live in parallel until you do something else.
"Merge" captures the idea that the effects of the operation and its unmerged ancestors will now be incorporated/integrated into the surviving op head, same as a merge in the commit graph. (But perhaps jj avoids that term in order to make multi-parented commits feel less special?)
I'll rename it
jj op publishin a day or so if I don't hear anything more.
I haven't done that yet because it's unclear if that's the preference. It sounds like it's a toss-up. I'll wait a bit more to see if we hear other opinions and/or arguments.
Both the PR title and the command name give no clues as to what this is for, or what it does (at least to a user with limited experience).
Both the PR title and the command name give no clues as to what this is for, or what it does (at least to a user with limited experience).
We review commit by commit in this project, so we often don't include much in the PR description. See the first commit description in this case.
The --no-commit-transaction feature mentioned in the first commit is #2562
I'll rename it
jj op publishin a day or so if I don't hear anything more.I haven't done that yet because it's unclear if that's the preference. It sounds like it's a toss-up. I'll wait a bit more to see if we hear other opinions and/or arguments.
I personally vastly prefer jj op publish over op integrate because that was what we used in previous conversations about this feature.
