-
Notifications
You must be signed in to change notification settings - Fork 130
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
Make git push -u without arguments set up the upstream remote by default #1061
Comments
An alternative would be to use Granted , it does not set up upstream information, so you can't then use i.e. You might want to have a look at that blog post :) Note also that you can also use |
Hello @pasky and @phil-blain , I had made a similar patch request on git mailing list and after some discussions, I found that the current behaviour is better. If no argument is provided to Here is the link - https://lore.kernel.org/git/[email protected]/
Note: So, I think this issue should be closed :) |
@Abhra303 ok, but what's your argument for Junio says "I think erring on the side of caution is more sensible than blindly assuming that the user wants a new branch with the same name" - I guess I simply disagree with that since the friction this adds feels more harmful to me than the (moreover easily reversible / undoable) risk it introduces. |
Hello @pasky,
If you see the docs of
The There are some devs who do not want to create a new branch while running argument-less People ( most probably you're also in this category) who want You can check the docs to know about other values.
It was for
That's why I am sure |
Oh, I see what you are saying - I'm not necessarily saying that the push.default modes semantics should change. There are two aspects:
(A weaker version of this suggestion could be that the error message when there is no upstream branch should suggest push.default=current to make it more discoverable.) |
Honestly, I also think that the docs for
I myself personally use |
With Git 2.37.0, you can configure Git to setup tracking when a new branch is first pushed: git config --global push.autoSetupRemote true This works with both |
As @phil-blain noted, the new config option This is not (yet?) a change in git's default behavior, but the "new" option is also hinted at when you get the classic error you noted above. @pasky , @dscho, does this address this project idea, or do you believe we should also make the change in behavior proposed here, omitting the need for |
A common workflow with the very popular workflow of topic branches is to create a branch, commit, then push it upstream. This invariably devolves to calling
git push
, receiving the hintand copy-pasting that to actually do the first push of the topic branch.
Ideally, just calling
git push -u
should do the same thing as this copy-paste (the hint is always correct in typical situations).The text was updated successfully, but these errors were encountered: