This includes the fix for
https://github.com/BurntSushi/ripgrep/issues/3127. The fix let us
optionally allow unclosed character classes in .gitignore files. It is
allowed by default when using the `GitignoreBuilder` (as we do), so we
get the fix without code changes.
I'm planning to try to add conflict labels to `MergedTree` and
`MergedTreeId`, and it will be easier to add them if both are structs
with similar methods. Since we don't support reading/writing legacy
conflicts anymore (as far as I'm aware), I think it should be safe to
delete the `MergedTreeId::Legacy` variant now.
When cloning with the branch option:
- Only the specified branch will be fetched
- The trunk alias is only set if the specified branch happens to be the default branch
- The clone fails if the branch does not exist in the remote
This comment currently says that we update all conflicted commits when
reading the derialized extra metadata, but that's not true for commits
with the `jj:trees` commit header.
Since we can now update tags internally, local and remote tags may be out of
sync in non-colocated Git repositories. "tags" template should indicate that.
This will help "jj bookmark track" know whether absent remote ref can be created
for the specified remote. "jj bookmark" subcommands shouldn't depend on
gix::Repository API.
Although we don't have "jj git tag set"/"delete" commands, this fixes weird undo
behavior #6325. The discussion in #6325 is derailed, but there would be another
issue for the "abandon unreachable" behavior.
Fixes#6325
- Added support for workspace-specific configuration using `jj config` commands.
- Introduced `--workspace` option to `jj config edit`, `jj config set`, and `jj config unset`.
- Workspace configuration file is stored in `.jj/workspace-config.toml` per workspace.
- Simplified workspace path handling logic.
- Updated documentation and test snapshots to reflect new behavior.
This improves flexibility for users working across multiple workspaces.
Co-authored-by: Eidolon <furyhunter600@gmail.com>
Co-authored-by: ase <adam@sandbergericsson.se>
Since "tracked" state doesn't exist in Git, git::import_refs() should ignore
absent->absent "changes". git::export_refs() just works because it compares only
ref targets.
This will allow us to set up tracking state and push new bookmarks in two steps
#7072.
Absent tracked remote refs are deleted with the corresponding local ref. I
originally considered this rule could be enforced by git::import/export_refs(),
but it seemed weird if absent remote refs were left when the tracking local ref
was deleted by user. Therefore, this invariant is ensured by the view API.
Since "jj bookmark track" cannot track absent remote refs yet, this patch
doesn't have UX changes that should be documented.
On a unix OS which isn't linux, "--when.platform = ['unix']" matches,
so adjust the assertion accordingly. Fixes this test on OpenBSD and
should fix the tests on other unix systems, in particular other *BSDs.
I'm going to rename "tag" in the view API to "local_tag". Since the underlying
data structures are split to View and RemoteView, it's not important to add
"local_" prefix. However, I think this change is good for consistency.
The migration logic is basically the same as 717d0d3d6d "git: on
deserialize/import/export, copy refs/heads/* to remote named git." Now
git::import_refs() processes bookmarks and tags in the same way.
git::export_refs() is unchanged because we don't have any commands that would
move local tags internally.
Git-tracking tags will be stored there. I don't have a concrete plan for proper
remote tags support, but I think tags fetched/pushed internally can be recorded
as remote tags.
I'm thinking of adding remote tags table to support tag mutation commands, so I
think it's time to update the storage format. RefTarget is serialized to a list
of alternate terms because we don't need to support legacy formats here.
Having tests illustrates the behavior. Making this public de-duplicates
the code with ERSC. This also allows determining whether a change id
comes from the header or is synthetic.
This is just a nice-to-have for me, we will also duplicate the code
until this is merged (if that happens).
This fixes the bug described below.
I have `submodule.recurse=true` set in my .gitconfig. When trying
to fetch repos with submodules (e.g. git/git), I got errors like these:
```console
$ jj git fetch
remote: Enumerating objects: 853, done.
remote: Total 853 (delta 448), reused 439 (delta 413), pack-reused 315 (from 2)
Error: Git process failed: External git program failed:
Could not access submodule 'sha1collisiondetection'
```
This error occured when fetching only, *not* when cloning. It occured
even when there wasn't anything to fetch.
I only tested repositories that never had submodules initialized or
fetched (which would have to be done with Git).
I think this helps readability a bit. I updated `TreeDiffEntry` and a
few related places. I think there are many other places where we could
use the new type.
I'm about to add a generic `Diff<T>` that's more similar to
`Merge<T>`, so I want to free up the name. It seems better to have
`Diff<T>` and `ContentDiff` than e.g. `GenericDiff<T>` and `Diff` or
having to use qualified imports.
1.90 was just released, so this seems reasonable, and it finally lets us
use let-chains. This includes all the clippy fixups too, and some small
changes suggested by Ilya.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
