Commit graph

718 commits

Author SHA1 Message Date
Martin von Zweigbergk
d34060f013 cli: print "Added X files, ..." message only if any files changed
Looking at the impact on the smoke test and the tutorial, I think I
went overboard in 83c0519. Let's only print the message if any files
changed.
2021-11-19 23:14:19 -08:00
Martin von Zweigbergk
ad6b6f516d tests: update smoke_test, broken by commit 83c051984e 2021-11-19 23:03:25 -08:00
Martin von Zweigbergk
6b0a568e44 docs: add pointer from README to Git-comparison doc 2021-11-18 22:06:15 -08:00
Martin von Zweigbergk
83c051984e cli: print "Added X files, modified Y files, removed Z files" on all updates
I was confused myself why the message was only printed by `jj co` and
not e.g. `jj undo`. That probably means that it should always be
printed (or never be printed).
2021-11-17 21:57:15 -08:00
Martin von Zweigbergk
6c0f3625ff tests: avoid accessing working copy just to get its commit ID
The view has been the source of truth for the currently checked-out
commit for a long time now.
2021-11-17 12:45:18 -08:00
Martin von Zweigbergk
b35086d4c9 repo: use local variable for WorkingCopy in Repo::init()
No need to pass it into `Repo` and then get it back from there.
2021-11-17 10:22:15 -08:00
Martin von Zweigbergk
33b272f5fa working_copy: make some functions require mutable references
We use interior mutability for caching in `WorkingCopy`, but let's
still take mutable reference in the functions where the state change
is visible.
2021-11-17 10:15:33 -08:00
Martin von Zweigbergk
32018da423 cli: add a command for untracking already tracked paths
Especially when working on a new-to-you project, it's common to end up
with unwanted files automatically tracked before you realize that you
should have added them to the `.gitignore`. Even after adding them to
the `.gitignore`, it's not trivial to make them no longer tracked (you
need to move them away, run e.g. `jj st`, then move them back). This
patch adds `jj untrack` to simplify that (without actually moving the
files).

Closes #14.
2021-11-17 09:19:41 -08:00
Martin von Zweigbergk
287602966e working_copy: add a method for untracking specified paths 2021-11-17 08:41:37 -08:00
Martin von Zweigbergk
41860692e9 trees: pass a matcher to the entry iterator 2021-11-14 22:00:46 -08:00
Martin von Zweigbergk
f2d5aa188d tree: refactor TreeEntriesIterator to look like TreeDiffIterator
Consistency is better, and I think this will make it a little easier
to add support for restricting the iterator by a `Matcher`.
2021-11-14 21:50:10 -08:00
Martin von Zweigbergk
f846112f80 cleanup: remove an unnecessary reference-taking noticed by Clippy 2021-11-14 12:47:14 -08:00
Martin von Zweigbergk
30845c1f3b cleanup: fix formatting regression 2021-11-14 12:46:38 -08:00
Martin von Zweigbergk
ae3ff4e1be cli: add command aliases such as "commit" for "close"
Although "commit" isn't technically correct for what `close` does,
it's how new users think of it, so let's make it a bit easier for
them.
2021-11-10 11:11:09 -08:00
Martin von Zweigbergk
ced252f766 cleanup: replace some as_slice() by & 2021-11-10 10:55:58 -08:00
Martin von Zweigbergk
e5dd93cbf7 cleanup: make Vec inside CommitId etc. non-public 2021-11-10 10:46:10 -08:00
Martin von Zweigbergk
9375106a05 cli: use same color for timestamps in operation log as in commit log 2021-11-07 21:41:22 -08:00
Martin von Zweigbergk
27107637f2 git: fix regression in pruning of remote refs
A while ago, I replaced a call to git2-rs's `Remote::fetch()` by calls
to `Remote::download()` and `Remote::update_tips()`. The function is
documented to be a convenience for those function, but it turns out
that the pruning of deleted remote refs is a separate call
(`Remote::prune()`), so we need to call that too.
2021-11-07 16:02:18 -08:00
Martin von Zweigbergk
bdea3ae31a git: don't pass remote credentials callback to Remote::update_tips()
AFAICT, the credentials callback is not used by
`Remote::update_tips()`.
2021-11-07 15:57:19 -08:00
Martin von Zweigbergk
0a43bc7088 cleanup: fix a formatting regression 2021-11-07 15:56:30 -08:00
Martin von Zweigbergk
798b4bc897 demos: add demo showing how conflicting commits can be rebased etc 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
bf64f89521 demos: update conflict-resolution demo with recent changes
Conflicts are now preserved in the working copy until their conflict
markers are gone (they used to be considered resolved).
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
2796b5a8e1 docs: update tutorial with new conflict handling in the working copy 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
c1bdba5403 cli: make jj st list paths with conflicts
Now that the working copy preserves conflicts, we can easily list
them.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
99e5a28d17 cli: don't materialize conflicts when editing diffs
The diff-editing code shares the `TreeState` functionality with the
working-copy code. That means we can now let the user edit conflicts
without materializing them first. So now the user can do e.g. `jj edit
-r <some commit>` and resolve only some of the conflicts.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
e901a4e66b repo: don't materialize conflicts on checkout
Since the working copy can now handle conflicts, we don't need to
materialize conflicts when checking out a commit.

Before this patch, we used to create a new commit on top whenever we
checked out a commit with conflicts. That new commit was intended just
for resolving the conflicts. The typical workflow was the resolve the
conflicts and then amend. To use the same workflow after this patch,
one needs to explicitly create a new commit on top with `jj new` after
checking out a commit with conflict.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
ea82340654 working_copy: preserve conflicts in the working copy until markers are removed
I realized only recently that we can try to parse conflict markers in
files and leave them as conflicted if they haven't changed. If they
have changed and some conflict markers have been removed, we can even
update the conflict with that partial resolution.

This change teaches the working copy to write conflicts to the working
copy. It used to expect that the caller had already updated the tree
by materializing conflicts. With this change, we also start parsing
the conflict markers and leave the conflicts unresolved in the working
copy if the conflict markers remain.

There are some cases that we don't handle yet. For example, we don't
even try to set the executable bit correctly when we write
conflicts. OTOH, we didn't do that even before this change.

We still never actually write conflicts to the working copy (outside
of tests) because we currently materialize conflicts in
`MutRepo::check_out()`. I'll change that next.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
cea6061f3d conflicts: add a function for parsing a materialized conflict
I initially made the working copy materialize conflicts in its
`check_out()` method. Then I changed it later (exactly a year ago, on
Halloween of 2020, actually) so that the working copy expected
conflicts to already have been materalized, which happens in
`MutableRepo::check_out`().

I think my reasoning then was that the file system cannot represent a
conflict. While it's true that the file system itself doesn't have
information to know whether a file represents a conflict, we can
record that ourselves. We already record whether a file is executable
or not and then preserve that if we're on a file system that isn't
able to record it. It's not that different to do the same for
conflicts if we're on a file system that doesn't understand conflicts
(i.e. all file systems).

The plan is to have the working copy remember whether a file
represents a conflict. When we check if it has changed, we parse the
file, including conflict markers, and recreate the conflict from
it. We should be able to do that losslessly (and we should adjust
formats to make it possible if we find cases where it's not).

Having the working copy preserve conflict states has several
advantages:

 * Because conflicts are not materialized in the working copy, you can
   rebase the conflicted commit and the working copy without causing
   more conflicts (that's currently a UX bug I run into every now and
   then).

 * If you don't change anything in the working copy, it will be
   unchanged compared to its parent, which means we'll automatically
   abandon it if you update away from it.

 * The user can choose to resolve only some of the conflicts in a file
   and squash those in, and it'll work they way you'd hope.

 * It should make it easier to implement support for external merge
   tools (#18) without having them treat the working copy differently.

This patch prepares for that work by adding support for parsing
materialized conflicts.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
f6839a4ceb files: implement Debug for MergeResult, display byte vector as string 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
856b219943 working_copy: if a file's recorded mtime is equal to the state's mtime, set to 0 early 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
033bfe7d5b working_copy: fix an incorrect comment about timestamps 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
9ac643ed1a working_copy: rename confusingly named read_time field 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
baa403b41e working_copy: clarify code for preserving current file state
On Windows, we preserve the executable bit. I plan to also teach the
working copy to preserve conflict state. This refactoring prepares for
that by simplifying how we preserve parts of the current file state.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
7c12014513 working_copy: extract a function for updating the file state and tree if dirty 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
730c442462 working_copy: move file_state() off of TreeState
The function doesn't use `self`, so let's move it off of
`TreeState`. That way we can call it even while holding a mutable
reference.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
f86ffbd47b working_copy: take advantage of DirEntry::path() 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
5dce6e9884 working_copy: avoid using file_state() for getting mtime of tree_state file
I want to change the signature of `file_state()` and this caller is
different from the others and only needs the mtime.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
efe7316354 working_copy: make FileType variants more similar to TreeValue variants
This change doesn't make much difference yet, but I think it will
enable further improvements.
2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
bf61e9cf3e working_copy: don't stat ignored files 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
76c58b3949 tree_builder: rename repo() to more accurate store() 2021-11-07 15:17:51 -08:00
Martin von Zweigbergk
acf3798abc revsets: allow underscore in identifiers 2021-11-07 07:55:52 -08:00
Martin von Zweigbergk
0dac2e5ed5 docs: mention Breezy as a similar tool
Closes #40.
2021-11-04 08:32:42 -07:00
Martin von Zweigbergk
d37e484fc8 docs: explain what the tool is about, not why I started it 2021-10-28 15:01:19 -07:00
Martin von Zweigbergk
c293638028 docs: add more detail about the project status (like what's missing) 2021-10-28 15:01:19 -07:00
Martin von Zweigbergk
5c0e929b29 docs: add a "Related Work" section to README 2021-10-28 15:01:19 -07:00
Martin von Zweigbergk
60ea81882f cli: use same template for jj log --no-graph as for jj log
It is weird how the template changes because you ask for now
graph. Also, I've never wanted the long format. Let's just remove it.
2021-10-27 21:28:04 -07:00
Martin von Zweigbergk
853b40cf18 cleanup: run rustfmt on formatter (missed in recent commit) 2021-10-27 21:26:22 -07:00
Martin von Zweigbergk
98337e819d demos: add more jj log calls to the working-copy demo
Thanks to @arxanas for the suggestion.
2021-10-27 21:16:29 -07:00
Martin von Zweigbergk
4f8632519b docs: update demo links with recent changes 2021-10-27 18:12:21 -07:00
Martin von Zweigbergk
571336b827 demos: add some blank lines to separate groups of commands (and comments) 2021-10-27 16:55:59 -07:00