Tags don't match download tar #21
Comments
|
Sounds reasonable, will do in the future. |
|
Thanks! |
spectral54
pushed a commit
to spectral54/libfuse
that referenced
this issue
Sep 14, 2022
This adds support for having conflicting git refs in the view, but we never create conflicts yet. The `git_refs()` revset includes all "add" sides of any conflicts. Similarly `origin/main` (for example) resolves to all "adds" if it's conflicted (meaning that `jj co origin/main` and many other commands will error out if `origin/main` is conflicted). The `git_refs` template renders the reference for all "adds" and adds a "?" as suffix for conflicted refs. The reason I'm adding this now is not because it's high priority on its own (it's likely extremely uncommon to run two concurrent `jj git refresh` and *also* update refs in the underlying git repo at the same time) but because it's a building block for the branch support I've planned (issue libfuse#21).
spectral54
pushed a commit
to spectral54/libfuse
that referenced
this issue
Sep 14, 2022
When there are two concurrent operations, we would resolve conflicting updates of git refs quite arbitrarily before this change. This change introduces a new `refs` module with a function for doing a 3-way merge of ref targets. For example, if both sides moved a ref forward but by different amounts, we pick the descendant-most target. If we can't resolve it, we leave it as a conflict. That's fine to do for git refs because they can be resolved by simply running `jj git refresh` to import refs again (the underlying git repo is the source of truth). As with the previous change, I'm doing this now because mostly because it is a good stepping stone towards branch support (issue libfuse#21). We'll soon use the same 3-way merging for updating the local branch definition (once we add that) when a branch changes in the git repo or on a remote.
spectral54
pushed a commit
to spectral54/libfuse
that referenced
this issue
Sep 14, 2022
I'm about to add some support for branches and tags (for issue libfuse#21) and it seems that we didn't have explicit testing of merging of views. There was `test_import_refs_merge()` in `test_git.rs` but that's specifically for git refs. It seems that it's made obsolete by the tests added by this commit, so I'm removing it.
spectral54
pushed a commit
to spectral54/libfuse
that referenced
this issue
Sep 14, 2022
I've finally decided to copy Git's branching model (issue libfuse#21), except that I'm letting the name identify the branch across remotes. Actually, now that I think about, that makes them more like Mercurial's "bookmarks". Each branch will record the commit it points to locally, as well as the commits it points to on each remote (as far as the repo knows, of course). Those records are effectively the same thing as Git's "remote-tracking branches"; the difference is that we consider them the same branch. Consequently, when you pull a new branch from a remote, we'll create that branch locally. For example, if you pull branch "main" from a remote called "origin", that will result in a local branch called "main", and also a record of the position on the remote, which we'll show as "main@origin" in the CLI (not part of this commit). If you then update the branch locally and also pull a new target for it from "origin", the local "main" branch will be divergent. I plan to make it so that pushing "main" will update the remote's "main" iff it was currently at "main@origin" (i.e. like using Git's `git push --force-with-lease`). This commit adds a place to store information about branches in the view model. The existing git_refs field will be used as input for the branch information. For example, we can use it to tell if "refs/heads/main" has changed and how it has changed. We will then use that ref diff to update our own record of the "main" branch. That will come later. In order to let git_refs take a back seat, I've also added tags (like Git's lightweight tags) to the model in this commit. I haven't ruled out *also* having some more persistent type of branches (like Mercurials branches or topics).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi! Welcome to github. Nice to find you here.
I've just hit upon a minor annoyance, and it might be good to correct it sooner rather than later. I'm scripting something which builds fuse, and it looks something like (pseudocode):
The only annoyance with this is that the download URL follows the git tag. Since the git tags have underscores, the link is:
So it's not possible to just update one
$FUSE_VERSION, you also have to update the URL separately, to represent thefuse_2_9_5part. It would be nice to just have the one variable to update. Is it possible to usefuse-2.9.5tags instead? It would make life easier.Thanks for your consideration, and I won't be disappointed if you decline.
The text was updated successfully, but these errors were encountered: