We do it for all the other kinds of objects already. It's useful to
have the path for backends that store objects by path (we don't have
any such backends yet). I think the reason I didn't do it from the
beginning was because we had separate `RepoPath` types for files and
directories back then.
When initializing a workspace that shares its working copy with a Git
repo (i.e. `jj init --git-repo=.`), we import refs and HEAD when
creating the `WorkspaceCommandHelper` (as we do for all commands when
the working copy is shared). That makes the explicit import we do in
`cmd_init()` unnecessary. It also makes the checkout of HEAD I added
for the fix of #102 unnecessary. More importantly, as @yuja reported
in #177, it makes the command crash (at least if the repo is small
enough that the two checkouts happen within a second). I think the
problem is that the second checkout tries to create the same commit
except that the Change ID is different (the problem is not the
predecessors as I speculated in the issue tracker). The fix is to
simply avoid doing the redundant work. We still need a proper fix for
#27 eventually.
Closes#177.
We depend on comparing the workspace root with the Git repo's path to
know if we're sharing the working copy with it. For that to work
reliably, we need the paths to be canonicalized, so that's what this
patch tries to do.
This patch adds a very simple e2e test of having a working copy shared
with Git. The test initially failed on Windows. The symptom was that
the "master" branch did not get updated when we create a commit using
`jj`. That suggested that we didn't correctly detect that the working
copy was shared. After a lot of troubleshooting, I think I mostly
understand what we going on here (thanks to @arxanas for suggesting
https://github.com/mxschmitt/action-tmate). The path we get from
`git2::Repository::workdir()` seems to not be canonicalized in the
same way as `std::fs::canonicalize()` canonicalizes. Specifically, it
does not have the "\\?\" prefix we get from that function. I suppose
that's because libgit2 is a C library and canonicalizes the path using
some other system call.
"log -p | less" is the option I often use with hg/git to find interesting
bits from the changelog, and I think it's also valid with jj. Unlike
"hg log -p --stat", "jj log -p --summary" does not show both diff summary
and patch to reflect the internal structure. This behavoir is arguable and
may be changed later.
The logic of show_patch() is extracted from cmd_show().
We might want to split show_diff() into config/option handling part and
diff displayer function, but I'm not sure. Since some of the show_diff
functions depends on ui, we can't isolate show_diff() from the ui object
anyway.
let opts = parse_diff_option(ui, args); // map config/option to diff opts
show_diff(ui, formatter, opts, ...); // would be nice if ui could be removed
This parepares for "log --patch" option, where the formatter will be passed
as a function argument. Unlike diff/show, graphlog needs a temporary output
buffer per commit.
There was a TODO about adding a test case for a delete/modify conflict
in a branch target that got resolved by abandoning a commit. The
resolution is to delete the branch. That case couldn't happend with
our old evolution-based mechanism for tracking rewrites (because we
couldn't un-prune a commit then).
Successful commands should probably not write to stderr. If we later
add commands that e.g. print warnings to stderr, we'll want to cover
that explicitly in test.
This involved copying `UnresolvedHeadRepo::resolve()` into the CLI
crate (and modifying it a bit to print number of rebased commit),
which is unfortunate.
The function is now pretty simple, and there's only one caller, so
let's inline it. It probably makes sense to move the code out of
`repo.rs` at some point.
It's the transaction's job to create a new operation, and that's where
the knowledge of parent operations is. By moving the logic for merging
in another operation there, we can make it contiuously update its set
of parent operations. That removes the risk of forgetting to add the
merged-in operation as a parent. It also makes it easier to reuse the
function from the CLI so we can inform the user about the process
(which is what I was investigating when I noticed that this cleanup
was possible).
If we have recorded in `MutableRepo` that commits have been abandoned
or rewritten, we should always rebase descendants before committing
the transaction (otherwise there's no reason to record the
rewrites). That's not much of a risk in the CLI because we already
have that logic in a central place there (`finish_transaction()`), but
other users of the library crate could easily miss it. Perhaps we
should automatically do any necessary rebasing we commit the
transaction in the library crate instead, but for now let's just have
a check for that to catch such bugs.
Certain commands should never rewrite commits, or they take care of
rebasing descendants themselves. We have an optimization in
`commands.rs` for those commands, so they skip the usual automatic
rebasing before committing the transaction. That's risky to have to
remember and `MutableRepo` already knows if any commits have been
rewritten (that wasn't the case before, in the Evolution-based
code). So let's just have `MutableRepo` do the check instead.
It's useful for the UI layer to know that there's been concurrent
operations, so it can inform the user that that happened. It'll be
even more useful when we soon start making the resolution involve
rebasing commits, since that's even more important for the UI layer to
present to the user. This patch gets us a bit closer to that by moving
the resolution to the repo level.
We had a few lines of similar code where we added a new of the
operation log and then removed the old heads. By moving that code into
a new type, we prepare for further refactorings.
I want to make it so when we apply a repo-level change that removes a
head, we rebase descendants of that head onto the closes visible
ancestor, or onto its successor if the head has been rewritten (see
#111 for details). The view itself doesn't have enough information for
that; we need repo-level information (to figure out relationships
between commits).
The view doesn't have enough information to do the.
It's unusual for the current commit to have descendants, but it can
happen. In particular, it can easily happen when you run `jj new`. You
probably don't want to abandon it in those cases.
We very often expect success, and we sometimes want to get the stdout,
too. Let's add a convenience function for that. It saves a lot of
lines of code.
I had accidentally given the two positional arguments for `jj git
remote add` the same index. While fixing that, I realized that maybe
`clap` can infer the index based on the declaration order in the
struct. That does indeed seem to work, so I just removed all the
explicit `index` arguments instead.
The Derive API is easier to work with, less error-prone, and less
verbose, so it seems like a good improvement.
It was quite a bit of work to make the switch, and I'll be surprised
if I didn't make any mistakes in the translation. We unfortunately
don't have enough e2e tests to be very confident, so we'll have to fix
any problems as we discover them.
I've at least verified that the output of `jj debug completion --fish`
is unchanged, except for a few help texts I changed for different
reasons (consistency, clarity, avoiding redundancy).
It's useful for tests, scripts, and debugging to be able to use
specific config instead of the user's config. That's especially true
for our automated tests because they didn't have a place to read
config from on Windows before this patch (they read their config from
`{FOLDERID_RoamingAppData}`, which I don't think we can override in
tests).
I'm a little hesitant to do this because most tools I'm familiar with
have the config file directly in `~/`. It's also easier to describe
where to put the file if it doesn't vary across platforms. But we're
still early in the project, so let's try it and see if we get any
complaints.
