Commit graph

18 commits

Author SHA1 Message Date
Yuya Nishihara
f8d56e816d cli: print parent commit summary on checkout
On "jj checkout", description of the working-copy commit is empty, and the
working-copy parent provides more information. It might be a bit verbose to
print parent summary on every history rewriting, but I think that's okay.
2023-05-02 15:04:13 +09:00
Ilya Grigoriev
0e2579ee6a Switch graph node to use for commit instead of
This follows up on 5c703aeb03.

The only reason for this change is that, subjectively, the result looks better to me. I'm not sure why, but I couldn't get used to the old symbol in spite of its seeming reasonableness. It felt really bold and heavy.

If people agree, we can wait until we need to update the screenshots for some other reason before merging this. Sorry I didn't figure this out while the discussion about the referenced commit was going on.

I'm not 100% certain how many fonts support each symbol. Please try it out and let me know if it doesn't work for you.

Compare after:

![image](https://user-images.githubusercontent.com/4123047/229251383-563b889d-7233-42e2-a3c5-bf9368a4d1fd.png)

and before:

![image](https://user-images.githubusercontent.com/4123047/229251695-7fd0ff2c-2832-4262-ade5-5120288cccdf.png)
2023-04-02 23:15:37 -07:00
Martin von Zweigbergk
5c703aeb03 cli: replace o as graph node by when using unicode graph
@joyously found `o` confusing because it's a valid change id prefix. I
don't have much preference, but `●` seems fine. The "ascii",
"ascii-large", and "legacy" graph styles still use "o".

I didn't change `@` since it seems useful to have that match the
symbol used on the CLI. I don't think we want to have users do
something like `jj co ◎-`.
2023-03-12 23:21:05 -07:00
Yuya Nishihara
66458a097e templater: require infix ++ operator to concatenate expressions
This eliminates ambiguous parsing between "func()" and "expr ()".

I chose "++" as template concatenation operator in case we want to add
bit-wise negate operator. It's also easier to find/replace than "~".
2023-03-01 16:39:23 +09:00
Yuya Nishihara
6bbf4c6fcf tests: extract log template function/variable for code readability
Also rewrites some lengthy templates. That's why the test output slightly
changed.
2023-03-01 16:39:23 +09:00
Martin von Zweigbergk
a67fbb6714 cli: switch default graph style to be Sapling's curved style
We seem to quite unanimously prefer this style, so let's make the
default.
2023-02-12 07:23:29 -08:00
Ilya Grigoriev
8c1a5539ad cli: Include revset in hint for resolve_single_rev
The revset is already printed in the error message, but it's easy to miss since
the error message is in different color.
2023-02-05 21:22:18 -08:00
Yuya Nishihara
e63ea86841 templater: do not complete "(no commit description)" by default
This allows us to use "if(description,)" to test empty description. And
I think this change is unavoidable if we want to add support for commit
template.
2023-02-01 16:13:43 +09:00
Yuya Nishihara
15e51315ec cli: make short_commit_description() compatible with default summary template 2023-01-16 11:53:35 +09:00
Ilya Grigoriev
ef3071ba09 Improve short_commit_description for commits without a description 2023-01-11 23:32:39 -08:00
Yuya Nishihara
6f8fb09609 cli: append "\n" to commit description specified by -m/--message
Otherwise the description set by -m would differ from the one set by editor.
This fixes test_describe() which says "make no changes", but previously "\n"
would be added by the second "jj describe".

As you can see, almost all hashes change in CLI tests. This means in-flight
PRs will need to be rebased to update insta snapshots.

Description text could be normalized by CommitBuilder, but the caller would
have to normalize it beforehand to compare with the current description, so
we would need an explicit function anyway. Another idea is to add a newtype
that represents a normalized description, and make CommitBuilder require it.
Commit::description() will return &Description in place of &str to ensure
that commit.description() == raw_str wouldn't compile.

Git CLI provides --cleanup=<mode> option to switch normalization rules, but
I don't think we'll need such feature.
2022-12-22 14:59:03 +09:00
Yuya Nishihara
9158c96202 cli: show hint if e.g. checkout revset resolved to multiple revisions
As suggested at
https://github.com/martinvonz/jj/issues/878#issuecomment-1345466602
2022-12-15 22:55:29 +09:00
Martin von Zweigbergk
d8feed9be4 copyright: change from "Google LLC" to "The Jujutsu Authors"
Let's acknowledge everyone's contributions by replacing "Google LLC"
in the copyright header by "The Jujutsu Authors". If I understand
correctly, it won't have any legal effect, but maybe it still helps
reduce concerns from contributors (though I haven't heard any
concerns).

Google employees can read about Google's policy at
go/releasing/contributions#copyright.
2022-11-28 06:05:45 -10:00
Martin von Zweigbergk
21cda3431c cli: drop support for ui.enable-open-commits config 2022-11-05 06:14:37 -07:00
Martin von Zweigbergk
0d1bf7cb3b cli: disable open commits by default 2022-08-26 23:34:52 -07:00
Martin von Zweigbergk
cd458ec96b cli: teach jj checkout a -m flag, to match jj new
The two commands are very similar and we should probably make one an
alias of the other (or just delete one), but for now let's at least
make them more similar by supporting `-m` for both.

I currently think `jj new` is more natural when starting a new change
on top of the current one and `jj checkout` is more natural when
starting a new change on top of another one, as well as when you just
want to look around or run tests. `jj checkout` doesn't currently
default to the working copy like `jj new` does. Perhaps we should make
it do that. Will people eventually feel that it's natural to run `jj
checkout` to create a new change on top of the working copy, or will
they feel that it's natural to run `jj new` on an unrelated commit
even to just look around, or will we want them as synonyms forever?
2022-08-26 23:34:52 -07:00
Martin von Zweigbergk
418ab22be0 cli: add config for using only new UX for open commits
By adding `ui.open-commits=false` in your config, you can now make `jj
checkout` always create a new working-copy commit on top of the
specified commit. If the config is set, open commits will also appear
in the same color as closed commits in `jj log` etc. This will let
some of us experiment with the new UX before we decide if it's a good
idea or not. I left `jj close` in place because it's useful for
setting a description and creating a new commit in one step.

I didn't mention the new config in the release notes because I hope we
can reach a decision and remove the config before the next release.
2022-07-01 08:58:08 +08:00
Martin von Zweigbergk
54285a9c56 tests: add test of jj checkout
I'm about to change how `jj checkout` works w.r.t. open/closed commits
(and in particular by moving some logic from the library crate to the
CLI), so let's make sure we have some test coverage.
2022-07-01 08:58:08 +08:00