revert: default location arguments to -B @#9060
Conversation
Make the location arguments (--onto, --insert-after, --insert-before) optional for revert. This change introduces a default destination of -B @ when no specific location is provided. Inserting the revert before the current working copy aligns with the common workflow of wanting to immediately build upon or examine the reverted state. Because this only provides a fallback for previously "missing" arguments, it does not break or change the behavior of existing usages that already provide explicit location flags.
glehmann
force-pushed
the
gln/revert-default-location-wkym
branch
from
e3d07d8 to
cb66dab
Compare
|
This seems like a good idea to me. |
|
I personally like this default, but I'm not an "edit" workflow user. |
|
There’s some prior discussion here: #6358. Like Yuya, I would find this default useful, but I’m not an “edit” workflow user either. |
|
I don't like this change to much as an |
|
@PhilipMetzger: What argument do you usually use for the destination? Do you usually do |
I usually use
yes, its roughly that. |
|
I'm confused, is it |
|
I'm using both workflows depending on what I'm doing, and I'm always using jj is already quite biased towards the new-squash workflow, and I'm mostly ok with that—just a few places where I'd like jj wouldn't push me out of the edit workflow. |
Its both as I said usually the first one if I'm not sure where I'm at and the second one where its clear what the revert should do.
I disagree with that since the only place where you're explicitly asked to create a new commit is when conflicts arise.
While I get your point, its not about "pushing" someone out of the workflow but providing equally unopinionated defaults to users. By making easier for the "new+squash" workflow you make it harder for all "edit" users. |
I don't see why it should be equally "bad" just to be equal for both workflows. And making it easier for the new-squash workflow users wouldn't change anything for the edit workflow users, so it wouldn't make it any harder compared to now. Some use cases would be easier, but none would be harder. BTW as I said I'm always using |
It stays unopinionated which is good, like if we optimized for the "edit" workflow by rebasing it by default on top of
It does make it harder to stay on top of
^, so either rebasing by default on to |
What does "stay on top of
On top of Why would you want to revert on top of your current working copy by default? |
If my tree looks like this
No, because it would reflect of what I'd expect from the command see the discussion above.
Because my in-flight changes may be on a different branch entirely or I want to work on the revert separately with
I mean you can achieve the same thing with a |
|
This is why this PR proposes providing a default location. It's not dropping the location flags, and we can still land the revert commit wherever we want. From where I stand, you are describing difficulties that can occur, but none of them is a good argument against providing a default location. It seems like there are several ways to look at this. It might be useful if others shared their thoughts to help move things along. |
By choosing one workflow over the other which you willfully ignore here.
And you're essentially saying that you don't consider it a good argument and with that disrespecting all users of this workflow. And having this default location will likely cause problems to users of it which you're unable to accept. Maybe @matts1 also has something to say on this since he's also an user of the |
Are you willingly ignoring that I'm also an edit workflow user?
I don't think disagreeing with your arguments is being disrespectful. Are you being disrespectful when you disagree with mine?
Again, I disagree with that statement. Could you accept it? PS: I value the perspective you bring to discussions about jj. However, our exchanges often become unpleasant enough that I find it difficult to continue the conversation. |
|
I think @PhilipMetzger is saying is that the default might make "edit" users accidentally apply the reverted commit before the working copy when they expected to to be on top of the working copy. Is that correct, Philip? I'm a bit surprised that users want the reverted commit on top of the working copy. |
Yes, I also realized that my previous answer can be generalized as wanting the reverted commit to be a sibling of |
5 participants
Make the location arguments (--onto, --insert-after, --insert-before) optional for revert. This change introduces a default destination of -B @ when no specific location is provided.
Inserting the revert before the current working copy aligns with the common workflow of wanting to immediately build upon or examine the reverted state.
Because this only provides a fallback for previously "missing" arguments, it does not break or change the behavior of existing usages that already provide explicit location flags.
Checklist
If applicable:
CHANGELOG.mdREADME.md,docs/,demos/)cli/src/config-schema.json)how it works, how it's organized), including any code drafted by AI
eye towards deleting anything that is irrelevant, clarifying anything that
is confusing, and adding details that are relevant. This includes, for
example, commit descriptions, PR descriptions, and code comments.