Empty files can be confusing in diff output. For example:
```
Added regular file file1:
Added regular file file2:
1: foo
```
This commit adds an "(empty)" placeholder instead. Since it's not
colored, and doesn't have line numbers, it will hopefully not be
mistaken for a file with the contents "(empty)".
Almost the entire method deals with `FileType::Normal`, so we can
reduce indentation and repeated matching on the file type by doing it
early and returning in the non-normal-file cases.
For tree-level conflicts, we're eventually not going to have
`ConflictId`. We'd want to make `write_conflict_to_store()` take a
`Merge<Option<TreeValue>>` and return an updated such value. That
would leave very little logic in the function, so let's just inline it
instead.
AFAIK, we can't make HEAD detached in an empty Git repository, so we need
to temporarily switch to the new default branch before checking out.
Fixes#2047
`update_from_content()` already writes file content for each term of
an unresolved merge, so it seems consistent for it to also write the
file content for resolved merges. I think this should simplify further
refactoring for tree-level conflicts and for preserving the executable
bit.
Since `update_from_contents()` only works with file contents and not
the executable or other kinds of paths, I think it makes more sense
for it to deal with `FileId`s instead of `TreeValue`s.
There were still many instances of `conflict` left from before we
renamed `Conflict<T>` to `Merge<T>`. I decided to rename many of them
based on the type parameter instead of the container. I think that
made it more readable in many cases.
I think I moved way too many functions onto `Merge<Option<TreeValue>>`
in 82883e648d. This effectively reverts almost all of that
commit. The `Merge<T>` type is simple container and it seems like it
should be at fairly low level in the dependency graph. By moving
functions off of it, we can get rid of the back-depdencies from the
`merge` module to the `conflict` module that I introduced when I moved
`Merge` to the `merge` module. I'm thinking the `conflict` module can
focus on materialized conflicts.
Summary: It releases more frequently and tends to fix more bugs frequently than
direnv; it also seems to (in my experience) behave better with caching in flake
and non-flake scenarios.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I39f08cd691eeac8e243c2e059edfaa9c
It's messy if pager and child output are interleaved as the pager controls
the tty.
Windows code is untested. I think the underlying I/O behavior is similar, but
I don't have expertise.
Two things will be added:
a. show warning if child exited with non-zero status
b. attach pager stdin to stderr of child process
I think (a) could be propagated from generate_diff() as an error variant, but
for (b), it makes sense to pass ui down to the function.
They are shown next to the change and commit id, since they are other names the
commit can be referred by.
The description is separated from the branches by a ` | ` when there are
branches, so that one can tell the branches from the description without color.
The result looks like this: 
Maybe we could load GitBackend without resolving .git symlink, but that would
introduce more subtle bugs. Instead, we calculate the expected Git workdir path
from the canonical ".git" path.
Fixes#2011
Per discussion in #2009. This behavior isn't affected by e7e49527ef "git:
ensure that remote branches never diverge", but it's subtle enough to write
a test.
I was considering how refs would be imported if we had a per-remote view of
named branches (and tags): Each remote has a view, and jj remembers the last
known view state to compute diffs. That's the same for the pseudo "git" remote.
Under the current storage, these view states are represented as follows:
git_refs["refs/heads/{name}"] # pseudo "git" remote branches
git_refs["refs/tags/{name}"] # pseudo "git" remote tags
git_refs["refs/remotes/{remote}/{name}"] # real remote branches
and the diffs are merged in to branches[name].local_target and tags[name].
We also have branches[name].remote_targets[remote], but I think it's redundant
because a tracking branch should also be the last known state, not something
that can diverge from the actual state. To make that clear, this commit
replaces the use of the "merge" API.
