-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support git-like remote and local branch UX #1136
Comments
SGTM :) |
This should be configurable by remote repository in addition to a default setting. Wouldn't it be useful to also have an option for |
Makes sense.
That also makes sense to me. We'd need support for writing configuration files first. |
Typical query would be something like -r 'mine()' or -r 'branches()' to exclude remote-only branches jj-vcs#1136. I originally considered a filter applied only to local targets, but it might also be useful to filter by remote names. So both local and remote targets are tested. It's also nice that -r 'all()' includes deleted/forgotten branches. Suppose a local-ref target wouldn't likely be pointed by unrelated remote ref, I think non-strict filtering like this is practically okay.
Typical query would be something like -r 'mine()' or -r 'branches()' to exclude remote-only branches jj-vcs#1136. I originally considered a filter applied only to local targets, but it might also be useful to filter by remote names. So both local and remote targets are tested. It's also nice that -r 'all()' includes deleted/forgotten branches. Suppose a local-ref target wouldn't likely be pointed by unrelated remote ref, I think non-strict filtering like this is practically okay.
Typical query would be something like -r 'mine()' or -r 'branches()' to exclude remote-only branches jj-vcs#1136. I originally considered a filter applied only to local targets, but it might also be useful to filter by remote names. So both local and remote targets are tested. It's also nice that -r 'all()' includes deleted/forgotten branches. Suppose a local-ref target wouldn't likely be pointed by unrelated remote ref, I think non-strict filtering like this is practically okay.
I think this is a good idea, we also discussed it a bit with @yuja in #1762 (comment). I think an important detail is that if
|
Typical query would be something like -r 'mine()' or -r 'branches()' to exclude remote-only branches jj-vcs#1136. The query matches against local targets only. This means there's no way to select deleted/forgotten branches by -r option. If we add a default revset configuration, we'll need some way to turn the default off.
Typical query would be something like -r 'mine()' or -r 'branches()' to exclude remote-only branches jj-vcs#1136. The query matches against local targets only. This means there's no way to select deleted/forgotten branches by -r option. If we add a default revset configuration, we'll need some way to turn the default off.
Typical query would be something like -r 'mine()' or -r 'branches()' to exclude remote-only branches #1136. The query matches against local targets only. This means there's no way to select deleted/forgotten branches by -r option. If we add a default revset configuration, we'll need some way to turn the default off.
I'm not sure if this is the best way to render non-tracking branches, but it helps to write CLI tests. Maybe we can add some hint or decoration to non-tracking branches, but I'd like to avoid bikeshedding at this point. Since we haven't migrated the push function yet, a deleted branch can be pushed to non-tracking remotes. This will be addressed later. jj-vcs#1136
I'm not sure if this is the best way to render non-tracking branches, but it helps to write CLI tests. Maybe we can add some hint or decoration to non-tracking branches, but I'd like to avoid bikeshedding at this point. Since we haven't migrated the push function yet, a deleted branch can be pushed to non-tracking remotes. This will be addressed later. jj-vcs#1136
I'm not sure if this is the best way to render non-tracking branches, but it helps to write CLI tests. Maybe we can add some hint or decoration to non-tracking branches, but I'd like to avoid bikeshedding at this point. Since we haven't migrated the push function yet, a deleted branch can be pushed to non-tracking remotes. This will be addressed later. jj-vcs#1136
I'm not sure if this is the best way to render non-tracking branches, but it helps to write CLI tests. Maybe we can add some hint or decoration to non-tracking branches, but I'd like to avoid bikeshedding at this point. Since we haven't migrated the push function yet, a deleted branch can be pushed to non-tracking remotes. This will be addressed later. #1136
Although this is logically correct, the error message is a bit cryptic. It's probably better to reject push if non-tracking remote branches exist. jj-vcs#1136
Although this is logically correct, the error message is a bit cryptic. It's probably better to reject push if non-tracking remote branches exist. jj-vcs#1136
Although this is logically correct, the error message is a bit cryptic. It's probably better to reject push if non-tracking remote branches exist. #1136
… them I personally don't mind if "jj branch list" showed all non-tracking branches, but I agree it would be a mess if ~500 remote branches were listed. So let's hide them by default since non-tracking branches aren't so interesting. Closes jj-vcs#1136
I personally don't mind if "jj branch list" showed all non-tracking branches, but I agree it would be a mess if ~500 remote branches were listed. So let's hide them by default as non-tracking branches aren't so interesting. Closes jj-vcs#1136
Thanks @yuja for adding this. I think it's better to also hide these branches in |
I prefer to see remote branches in log, but we should have some way to hide them. Maybe we can add |
As far as I can see in the chat, there's no objection to changing the default, and git.auto-local-branch = false is generally preferred. docs/branches.md isn't updated as it would otherwise conflict with jj-vcs#2625. I think the "Remotes" section will need a non-trivial rewrite. jj-vcs#1136, jj-vcs#1862
As far as I can see in the chat, there's no objection to changing the default, and git.auto-local-branch = false is generally preferred. docs/branches.md isn't updated as it would otherwise conflict with jj-vcs#2625. I think the "Remotes" section will need a non-trivial rewrite. jj-vcs#1136, jj-vcs#1862
Description
jj
treats remote branches very differently compared to Git. Unfortunately,jj
is primarily used as a client to remote Git repositories which the user may or may not have control over. Certain idiomatic Git patterns don't fit this model well, leading to a bad UX:Adding a remote with a large number of branches that developers aren't necessarily expected to interact with regularly, e.g. https://github.com/gitster/git has a large number of historical topic branches. This is a somewhat GIt-specific problem since Git repos tend to have more branches than Mercurial repos have bookmarks.
jj branch list
becomes very large and largely irrelevantAdding multiple remotes with different branching structures. In Git, remotes can be used to "bookmark" URLs without necessarily fetching the entire contents of the remote/creating local branches for each remote branch.
Proposal
Add a config option that gives a more Git-like user experience to remote branches. An initial list of features could be:
jj branch list
jj git push --branch=no-local-target
, require an explicit--delete
flagThe text was updated successfully, but these errors were encountered: