643 commits

Author	SHA1	Message	Date
Yuya Nishihara	fca92f1e16	cli: add --config-file=PATH argument ... This would be useful for scripting purpose. Maybe we can also replace the current --config-toml=<TOML> use cases by --config-file=<PATH> and simpler --config=<KEY>=<VALUE>. https://github.com/martinvonz/jj/issues/4926#issuecomment-2506672165 If we want to add more source variants (such as fd number), it might be better to add --config-from=<type>:<path|fd|..>. In any case, we'll probably want --config=<KEY>=<VALUE>, and therefore, we'll need to merge more than one --config* arguments.	2024-12-13 10:27:03 +09:00
Yuya Nishihara	e1ab2477cd	docs: mention "jj file untrack" in Git compatibility list ... Closes #5059	2024-12-13 10:20:48 +09:00
Yuya Nishihara	0f845b6930	docs: quote "jj file untrack" consistently	2024-12-13 10:20:48 +09:00
Austin Seipp	e7e66d23b1	Back out 89d57ffb: "build: add rust-toolchain.toml" ... This backs out commit 89d57ffb29. This is causing a CI failure because we can't build musl binaries, presumably because the rust-toolchain file overriding the chosen musl toolchain for some reason. Backout until we can reapply a proper fix. Signed-off-by: Austin Seipp <aseipp@pobox.com>	2024-12-12 15:54:30 -06:00
Yuya Nishihara	53b8eeb5ab	templater: rename "logical" eq/ne operators ... They are the equality operators. There aren't logical, bitwise, arithmetic thingy.	2024-12-12 22:48:45 +09:00
Benjamin Tan	da5b790f7a	templater: add relational operators (>=, >, <=, <) ... Closes #5062.	2024-12-12 19:56:29 +08:00
Yuya Nishihara	0de36918e4	config: merge and print inline tables as values ... Before, "jj config get"/"list" and .get() functions processed inline tables as tables (or directories in filesystem analogy), whereas "set"/"unset" processed ones as values (or files.) This patch makes all commands and functions process inline tables as values. We rarely use the inline table syntax, and it's very hard to pack many (unrelated) values into an inline table. TOML doesn't allow newlines between { .. }. Our common use case is to define color styles, which wouldn't be meant to inherit attributes from the default settings. The default pager setting is flattened in case user overrides pager.env without changing the command args.	2024-12-12 10:11:51 +09:00
Waleed Khan	c2b86197f5	docs: collapse contributing.md suggested cargo install commands ... Should be easier to copy-and-paste and install everything this way?	2024-12-11 11:05:47 -08:00
Waleed Khan	89d57ffb29	build: add rust-toolchain.toml ... Follow-up from discussion at https://discord.com/channels/968932220549103686/1288926971719323762 I don't think we achieved consensus in that thread. We could use `stable` or `nightly` here instead if we prefer. Note that user `rustup` overrides are still respected in the presence of a `rust-toolchain.toml`.	2024-12-11 11:05:47 -08:00
Yuya Nishihara	e1936a2e8b	docs: suggest "jj bookmark move" where makes sense ... Closes #5067	2024-12-11 10:37:45 +09:00
Waleed Khan	652d16369a	docs: in sparse-v2.md, use Markdown warning admonition ... Renders more nicely on the documentation website.	2024-12-07 13:50:44 -08:00
Waleed Khan	129ea5262f	docs: in contributing.md, use Markdown warning admonition ... This has special rendering on the website, which makes it stand out more clearly.	2024-12-07 13:50:44 -08:00
Martin von Zweigbergk	b7ba3fc0be	docs: update installation docs to say that cmake is needed ... Since we enabled the `zlib-ng` feature from `gix` in 2412fd4, `cmake` is needed when installing from source.	2024-12-06 08:23:27 -08:00
Scott Taylor	fa7d9c09fc	merge_tools: add merge-conflict-exit-codes option ... Some Git merge drivers can partially resolve conflicts, leaving some conflict markers in the output file. In that case, they exit with a code between 1 and 127 to indicate that there was a conflict remaining in the file (since Git uses a shell to run the merge drivers, and shells often use exit codes above 127 for special meanings such as exiting due to a signal): https://git-scm.com/docs/gitattributes#_defining_a_custom_merge_driver We should support this convention as well, since it will allow many Git merge drivers to be used with Jujutsu, but we don't run our merge tools through a shell, so there is no reason to treat exit codes 1 through 127 specially. Instead, we let the user specify which exact exit codes should indicate conflicts. This is also better for cross-platform support, since Windows may use different exit codes than Linux for instance.	2024-12-03 20:08:31 -06:00
Remo Senekowitsch	d76bcd9305	docs: clarify dynamic completion features	2024-11-29 21:22:38 +01:00
Scott Taylor	7f57866332	merge_tools: allow setting conflict marker style per-tool ... I left the "merge-tool-edits-conflict-markers" option unchanged, since removing it would likely break some existing configurations. It also seems like it could be useful to have a merge tool use the default conflict markers instead of requiring the conflict marker style to always be set for the merge tool (e.g. if a merge tool allows the user to manually edit the conflicts).	2024-11-26 09:05:17 -06:00
Scott Taylor	ea72a4af28	tutorial: fix conflict formatting issue	2024-11-25 16:47:59 -06:00
Martin von Zweigbergk	5aee10aa6d	faq: add an entry about why merge commits are often empty	2024-11-25 10:46:52 -08:00
Scott Taylor	472fd35ff1	docs: rewrite conflict marker docs to include new styles ... The current docs for conflict markers start out by introducing Git "diff3" conflict markers, and then discussing how Jujutsu's conflict markers are different from Git's. I don't think this is the best way to explain it, because it requires the reader to first understand Git's conflict markers before they go on to learn Jujutsu's conflict markers. Instead, I think it's better to explain the conflict markers from scratch with a more detailed example so that we don't assume any particular knowledge of Git. This structure also works better with the new config option, since we can talk about the default option first, and then go on to explain alternatives later.	2024-11-23 08:28:47 -06:00
Lars Francke	ffe5519fd0	Update tutorial for 0.23 and clarify diffedit	2024-11-22 21:23:12 +01:00
Tim Janik	86a2a2b1e9	docs/git-compatibility.md: preserve working copy files when co-locating ... Use `jj new && jj undo` instead of `jj new @-` at the end of converting to a co-located repository, because the latter "stashes" newly added working copy changes into a sibling commit. See also: https://github.com/martinvonz/jj/discussions/4945 Signed-off-by: Tim Janik <timj@gnu.org>	2024-11-22 19:20:36 +01:00
Emily	c0a9e20222	docs: tighten the "previewing docs" section	2024-11-20 06:06:53 +01:00
Emily	cedaa5bb00	docs: migrate from poetry to uv ... Our docs are built with MkDocs, which requires Python and several deps. Previously those deps were managed with Poetry, which is also written in Python. This commit replaces Poetry with `uv`, a Rust-based Python project/package manager, and thus removes several steps from the docs build process. Before: <install Python> <install pipx> pipx install poetry poetry install poetry run -- mkdocs serve After: <install uv> uv run mkdocs serve	2024-11-20 06:06:53 +01:00
Luke Randall	068fa0f37e	revset: allow tags() to take a pattern for an argument ... This makes it more consistent with `bookmarks()`. Co-authored-by: Austin Seipp <aseipp@pobox.com>	2024-11-20 00:47:23 +00:00
Herman J. Radtke III	3be6f03938	docs: git blame comparison ... Add comparison for git blame and jj file annotate.	2024-11-19 09:58:28 -08:00
Yuya Nishihara	296961cb19	cli: git push: do not push new bookmarks by default ... If you have multiple remotes to push to, you might want to keep some changes (such as security patches) in your private fork. Git CLI has one upstream remote per branch, but jj supports multiple tracking remotes, and therefore "jj git push" can start tracking new remotes automatically. This patch makes new bookmarks not eligible for push by default. I considered adding a warning, but it's not always possible to interrupt the push shortly after a warning is emitted. --all implies --allow-new because otherwise it's equivalent to --tracked. It's also easier to write a conflict rule with --all/--deleted/--tracked than with two of them. -c/--change doesn't require --allow-new because it is the flag to create new tracking bookmark. #1278	2024-11-19 21:11:22 +09:00
Martin von Zweigbergk	a22620d30c	docs: say that support for Git's remote config is partial ... #4889	2024-11-16 17:41:08 -08:00
Tim Janik	e8bbd89ec1	docs/community_tools.md: add paragraph about jj-fzf ... Signed-off-by: Tim Janik <timj@gnu.org>	2024-11-16 23:49:03 +01:00
Tim Janik	68d4ec7f0a	docs/community_tools.md: restore alphabetical order ... Signed-off-by: Tim Janik <timj@gnu.org>	2024-11-16 23:49:03 +01:00
Martin von Zweigbergk	9fc3255238	docs: try to clarify that changes are not a first-class concept	2024-11-16 14:20:37 -08:00
Philip Metzger	eb91547e52	docs: Make the Roadmap a toplevel website entry ... This also fixes the Xethub link, by pointing it to the web archive, which no longer is available.	2024-11-16 11:11:59 +01:00
Benjamin Tan	4db4f413a7	revset: add fork_point function ... This can be used to find the fork point (best common ancestors) of a revset with an arbitrary number of commits, which cannot be expressed currently in the revset language.	2024-11-16 04:08:01 +08:00
Benjamin Tan	5a793f61d6	cli: duplicate: add --destination, --insert-after, and --insert-before options	2024-11-15 19:42:13 +08:00
Robin Stocker	560d66ecee	docs: switch all toml examples to heading notation	2024-11-14 16:29:49 +00:00
Remo Senekowitsch	a650af3fcd	completion: improve docs for activation ... It was not clear if users should activate both sets of completions if they wanted the dynamic ones. The shell commands for activating the dynamic completions are aligned with the static version. Users can choose / are responsible themselves to add the activation to their shell config if they want them in every shell instance. For fish specifically, `script | source` is more idiomatic than `source (script | psub)`.	2024-11-13 18:13:54 +01:00
Emily	7d9e9a1434	docs: remove trailing whitespace in .md	2024-11-12 01:16:08 +01:00
Emily	235d57c053	docs: beginnings of an 'editor setup' section	2024-11-12 01:16:08 +01:00
Yuya Nishihara	6739dccc6d	templater: add != operator as user would probably expect that it exists	2024-11-10 21:41:24 +09:00
Remo Senekowitsch	c9e751ae6e	completion: teach rename about local bookmarks	2024-11-10 07:26:22 +01:00
Remo Senekowitsch	db2b5890f8	util: add exec command for arbitrary aliases	2024-11-09 11:49:33 +01:00
Martin von Zweigbergk	86de9139b3	docs: fix a few typos noticed by automation at Google	2024-11-07 23:04:11 -08:00
Benjamin Tan	1372b39341	template: add support for logical equality operator	2024-11-08 01:55:18 +08:00
Tim Janik	aa040021da	docs/FAQ.md: answer monitoring jj log with watch and TUIs ... * Suggested `watch --color` as recommended by @ilyagr * Answered monitoring `jj log` with watch and TUIs * Minor wording fix. * Adjusted watch(1) and hwatch links as suggested by @ilyagr Signed-off-by: Tim Janik <timj@gnu.org>	2024-11-07 09:40:25 -08:00
Philip Metzger	7d1041c9d5	FAQ: Mention when users should use jj-lib or integrate via the CLI	2024-11-05 18:34:05 +00:00
Ilya Grigoriev	e8f722cfe1	docs config diff-editor: advertise Meld some more ... I think most people would benefit from trying both an internal and an external merge tool. I was also considering mentioning `kdiff3` or `diffedit3` more heavily. For `kdiff3`, I find its diff editing interface very confusing and I don't know of anybody who happily uses it as a diff editor. For `diffedit3`, I'm not very objective.	2024-11-04 19:14:18 -08:00
Ilya Grigoriev	4ecf75efc1	docs config diff-editor: clean up, change KDiff3 example to Meld ... I don't think recommending KDIff3 for diff editing is good advice in most cases (as opposed to merge conflict resolution, for which KDiff3 is very good). OTOH, trying Meld for diff editing is a good idea for many people. Historically, this part of the docs uses KDiff3 because it was written when `meld` was the default and `:builtin` did not exist.	2024-11-04 19:14:18 -08:00
Martin von Zweigbergk	c7cd014fe6	docs: add more detail to section about stale working copies ... We only explained that working copies can become stale when updating a commit from another workspace, but there are other cases too. I also tried to better explain what the state actually means.	2024-10-30 18:13:48 -07:00
Martin von Zweigbergk	30ab71d340	bookmarks: add support for git.auto-local-bookmark (to match docs) ... We had documented that we support `git.auto-local-bookmark` but we don't. The documentation has been incorrect since d9c68e08b1. This patch fixes it by adding support for `git.auto-local-bookmark` with fallback to the old/current `git.auto-local-branch`. .	2024-10-30 08:01:02 -07:00
SoraTenshi	fa5372f453	docs: include remote add command	2024-10-29 09:15:45 -07:00
Richard Macklin	8cdb0e4d6e	docs: Replace "first make sure..." comment with equivalent --only flag ... This part of the git-comparison table was implying you need to manually check and clear staged changes in order to only update the previous commit's message. That isn't the case, though. As mentioned in the `git-commit` documentation [1], this can be directly achieved by using the `--only` flag with `--amend`: > If this option is specified together with --amend, then no paths need > to be specified, which can be used to amend the last commit without > committing changes that have already been staged. [1]: https://git-scm.com/docs/git-commit#Documentation/git-commit.txt--o	2024-10-26 17:35:29 -07:00