Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement jj next/prev #878

Closed
dbarnett opened this issue Dec 10, 2022 · 5 comments · Fixed by #1200
Closed

Implement jj next/prev #878

dbarnett opened this issue Dec 10, 2022 · 5 comments · Fixed by #1200
Assignees
Labels
polish🪒🐃 Make existing features more convenient and more consistent

Comments

@dbarnett
Copy link
Collaborator

There should be a pair of commands jj next and jj prev for quickly checking out the next/previous commit from @, similar to the next/prev commands from git-branchless.

@dbarnett
Copy link
Collaborator Author

For now, you can add these aliases to your jj config to get something close:

[alias]
prev = ["co", "@--"]
next = ["co", "@-+ ~ @"]

but with a pretty big misfeature that in branch/merge cases instead of getting a picker to say which prev/next rev you want, it just blows up with an error about "more than one revision".

@martinvonz
Copy link
Owner

I agree. FYI, @rslabbert talked (on Discord) about possibly implementing an interactive command for selecting a commit to check out or edit. Having prev and next that are non-interactive in the linear case still seems useful, though.

@dbarnett
Copy link
Collaborator Author

Oh, another small usability improvement for "more than one revision": It wouldn't hurt anything to have the error list those actual multiple revisions it found, would it? Like:

$ jj next
Error: Revset "@-+ ~ @" resolved to more than one revision:
67318df2df48 tutorial: mention `jj edit` and when it's useful
a83a0415aed8 Do not use "..." between diff chunks when it only replaces 1 line of the diff

@ilyagr ilyagr added the polish🪒🐃 Make existing features more convenient and more consistent label Dec 11, 2022
@martinvonz
Copy link
Owner

Oh, another small usability improvement for "more than one revision": It wouldn't hurt anything to have the error list those actual multiple revisions it found, would it? Like:

$ jj next
Error: Revset "@-+ ~ @" resolved to more than one revision:
67318df2df48 tutorial: mention `jj edit` and when it's useful
a83a0415aed8 Do not use "..." between diff chunks when it only replaces 1 line of the diff

It would probably not hurt anything to include up to, say, 5 commits there.

If we wanted to format and color those commits as we usually, I'm not sure how to do it cleanly. So far, the errors we return have a single, plain-text error message, and an optional plain-text hint. We render the text in red and the hint in blue (by default). That happens here:

jj/src/cli_util.rs

Lines 1481 to 1487 in 4a889b9

Err(CommandError::UserError { message, hint }) => {
ui.write_error(&format!("Error: {}\n", message)).unwrap();
if let Some(hint) = hint {
ui.write_hint(&format!("Hint: {}\n", hint)).unwrap();
}
1
}
. We could of course print out the unwanted revisions before returning the error, which would end up looking more like this:

$ jj next
Hint: Revset "@-+ ~ @" resolved to more than one revision: 
67318df2df48 tutorial: mention `jj edit` and when it's useful
a83a0415aed8 Do not use "..." between diff chunks when it only replaces 1 line of the diff
Error: Revset "@-+ ~ @" resolved to more than one revision.

It might be better to just render it as plain-text error plus hint then, pretty much as you suggested above:

$ jj next
Error: Revset "@-+ ~ @" resolved to more than one revision.
Hint: The revset resolved to these revisions:
67318df2df48 tutorial: mention `jj edit` and when it's useful
a83a0415aed8 Do not use "..." between diff chunks when it only replaces 1 line of the diff

@ilyagr
Copy link
Collaborator

ilyagr commented Dec 12, 2022

Following the idea of #878 (comment), I like

[revset-aliases]
next = "@-+ ~ @" 
prev = "@--"  # Though I usually just type @--

Then, you can do jj up next, jj log -r next (especially if it resolves to multiple revisions), jj rebase -d next or even jj rebase -d next+, etc. You can do this instead of or in addition to the [alias]-es.

PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Jan 22, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Feb 5, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Feb 12, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Feb 12, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Feb 16, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit that referenced this issue Mar 23, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes #878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue May 25, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue May 25, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
@PhilipMetzger PhilipMetzger self-assigned this Jun 14, 2023
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Jul 3, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Jul 5, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Jul 5, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Jul 6, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Aug 3, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Aug 3, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Aug 3, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Aug 9, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Aug 16, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit that referenced this issue Aug 21, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes #878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Aug 24, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Aug 24, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I currently gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Sep 5, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit to PhilipMetzger/jj that referenced this issue Sep 5, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I gave each command separate a separate argument struct
for extensibility. 

Fixes martinvonz#878
PhilipMetzger added a commit that referenced this issue Sep 5, 2023
This is a naive implementation, which cannot deal with multiple children
or parents stemming from merges.

Note: I gave each command separate a separate argument struct
for extensibility. 

Fixes #878
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
polish🪒🐃 Make existing features more convenient and more consistent
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants