add support for pushing to tracked remote #1278
Comments
|
I think you're referring to https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushdefault, right? Do you mean that you use different remotes for different branches in the same repo? If it's the same for all branches, then you can set |
|
@martinvonz I think this should do it, though I was referring to a behaviour similar to git's |
|
I think that means making the remote configurable per branch. I had not planned that, but I don't see any reason we shouldn't do it. |
|
We now have a concept of a branch on a specific remote being "tracked" per branch. This means that the branch would never be pushed to a remote it's not tracking. I think that, for many purposes, this could be enough. For more automation, we could in principle make one of the tracked remotes the default push destination. However, currently |
…emote set If you have multiple remotes to push to, you might want to keep some changes in your private fork. Git CLI has one upstream remote per branch, but jj supports multiple tracking remotes, and therefore "jj git push" can start tracking new remotes automatically. This patch makes new bookmarks not eligible for push if tracked bookmarks already exists on other remotes. I considered adding a warning, but it's not always possible to interrupt the push shortly after a warning is emitted. This check can be turned off by specifying --remote=NAME explicitly. Another stricter (and simpler in terms of implementation) idea is to force user to pass --new-bookmark or something to push any local bookmark to new remote. jj-vcs#1278
…emote set If you have multiple remotes to push to, you might want to keep some changes in your private fork. Git CLI has one upstream remote per branch, but jj supports multiple tracking remotes, and therefore "jj git push" can start tracking new remotes automatically. This patch makes new bookmarks not eligible for push if tracked bookmarks already exists on other remotes. I considered adding a warning, but it's not always possible to interrupt the push shortly after a warning is emitted. This check can be turned off by specifying --remote=NAME explicitly. Another stricter (and simpler in terms of implementation) idea is to force user to pass --new-bookmark or something to push any local bookmark to new remote. jj-vcs#1278
If you have multiple remotes to push to, you might want to keep some changes (such as security patches) in your private fork. Git CLI has one upstream remote per branch, but jj supports multiple tracking remotes, and therefore "jj git push" can start tracking new remotes automatically. This patch makes new bookmarks not eligible for push by default. I considered adding a warning, but it's not always possible to interrupt the push shortly after a warning is emitted. --all implies --allow-new because otherwise it's equivalent to --tracked. It's also easier to write a conflict rule with --all/--deleted/--tracked than with two of them. -c/--change doesn't require --allow-new because it is the flag to create new tracking bookmark. jj-vcs#1278
If you have multiple remotes to push to, you might want to keep some changes (such as security patches) in your private fork. Git CLI has one upstream remote per branch, but jj supports multiple tracking remotes, and therefore "jj git push" can start tracking new remotes automatically. This patch makes new bookmarks not eligible for push by default. I considered adding a warning, but it's not always possible to interrupt the push shortly after a warning is emitted. --all implies --allow-new because otherwise it's equivalent to --tracked. It's also easier to write a conflict rule with --all/--deleted/--tracked than with two of them. -c/--change doesn't require --allow-new because it is the flag to create new tracking bookmark. jj-vcs#1278
If you have multiple remotes to push to, you might want to keep some changes (such as security patches) in your private fork. Git CLI has one upstream remote per branch, but jj supports multiple tracking remotes, and therefore "jj git push" can start tracking new remotes automatically. This patch makes new bookmarks not eligible for push by default. I considered adding a warning, but it's not always possible to interrupt the push shortly after a warning is emitted. --all implies --allow-new because otherwise it's equivalent to --tracked. It's also easier to write a conflict rule with --all/--deleted/--tracked than with two of them. -c/--change doesn't require --allow-new because it is the flag to create new tracking bookmark. #1278
I'd like to always push to the tracked remote as most often I don't have write privileges on most repos I work on and I usually don't have mine set as origin because sometimes I have multiple mirrors (i.e. a remote for gitlab and another for github, so I use those names).
Currently
jjgives me anError: Unexpected git error when pushing: unexpected http status code: 403; class=Http (34)which I believe is also not the best (I had to think through it for a while to figure out the actual problem).Of course, I can just change one of my usual remotes to what
jjexpects them to be, but I find this rather inflexible.The text was updated successfully, but these errors were encountered: