You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As part of my github workflow I will typically make a change followed by a jj git push (and then go open a PR). Almost always when I push I'm about to move onto something else, but sometimes will forget to do a jj new before making changes. This makes it easy to accidentally add an inadvertant change to the previously pushed change, which will then be pushed up to that PR on the next jj git push.
In the case that I do realize that I have made some changes as well, it is not super trivial to split out those changes. I've been experimenting with a command like the following to restore my branch to the remote version without losing the local changes.
I'd like to just make it harder to make this mistake in the first place.
Describe the solution you'd like
Add a flag and/or config option (open to naming suggestions) for jj git push so that after the command, if @ is at one of the remote tracked bookmarks that was just pushed, automatically perform jj new.
This would make it harder to accidentally edit that change directly, and after a jj git push the state of the repo would be similar to if I had just "switched to that change" when following the "squash workflow".
If the current @ was not just pushed, then I don't think a jj new is warranted as the push was run in order to push some change other than what is currently being worked on.
Describe alternatives you've considered
The alternative here is basically "stop forgetting to run jj new"
Additional context
I'm willing to contribute this feature, but wanted to check if it is desired before doing so.
The text was updated successfully, but these errors were encountered:
Describe the solution you'd like
Add a flag and/or config option (open to naming suggestions) for jj git push so that after the command, if @ is at one of the remote tracked bookmarks that was just pushed, automatically perform jj new.
If you add this as a condition on the immutable_heads() revset, jj will perform an automatic jj new for you to prevent you from editing an immutable commit.
@PhilipMetzger but wouldn't that prevent me from doing a jj squash when I do want to update those changes? After getting PR feedback for instance, my workflow is to do
jj new github-branch-name
// make edits and ensure they look right
jj squash
jj git push
@PhilipMetzger but wouldn't that prevent me from doing a jj squash when I do want to update those changes?
Yes, since that tip usually is for Github branch oriented workflows where you need to typically add a commit to address feedback. Otherwise this is probably a duplicate of #5881 and #5818. In my opinion this is clearly a workflow issue and nothing the system can address by itself except by educating users a bit better.
Is your feature request related to a problem? Please describe.
As part of my github workflow I will typically make a change followed by a
jj git push
(and then go open a PR). Almost always when I push I'm about to move onto something else, but sometimes will forget to do ajj new
before making changes. This makes it easy to accidentally add an inadvertant change to the previously pushed change, which will then be pushed up to that PR on the nextjj git push
.In the case that I do realize that I have made some changes as well, it is not super trivial to split out those changes. I've been experimenting with a command like the following to restore my branch to the remote version without losing the local changes.
I'd like to just make it harder to make this mistake in the first place.
Describe the solution you'd like
Add a flag and/or config option (open to naming suggestions) for
jj git push
so that after the command, if@
is at one of the remote tracked bookmarks that was just pushed, automatically performjj new
.This would make it harder to accidentally edit that change directly, and after a
jj git push
the state of the repo would be similar to if I had just "switched to that change" when following the "squash workflow".If the current
@
was not just pushed, then I don't think ajj new
is warranted as thepush
was run in order to push some change other than what is currently being worked on.Describe alternatives you've considered
The alternative here is basically "stop forgetting to run
jj new
"Additional context
I'm willing to contribute this feature, but wanted to check if it is desired before doing so.
The text was updated successfully, but these errors were encountered: