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
Documenting pushdefault config option #257
Comments
I prefer method number one, the explicit way: About the cons:
Method 2: Using Method 3: Setting I don't think it's a goal of the devguide to teach how to use |
That's what I'm currently doing, but I would like to be able to go through the steps without having to thinking about all the commands/arguments and/or copy/pasting them :)
Good to know the order is not an issue :) Specifying the wrong names still is though: someone might do FWIW I care more about factoring out the repo since it should (almost) always be |
I also prefer Method 1 as the preferred way as it is most explicit. Most of the time, I will type out the command, but I have also aliased the frequently used ones in my bash config and have tab completion too. Method 2: I rarely use this. When working on multiple repos across different orgs, it's easier and less error prone for me to just be explicit (I never use Method 3 is handy but is an advanced workflow. Maintainers may find this helpful. As for the possibility of the wrong remote being sent, I am not sure how to prevent this case. I suppose that using |
During the recent updates I kept method 1 in the docs, since it was the preferred form. The alternative methods are currently not documented, but they could be added to the gitbootcamp page. I was thinking we could also collect this and similar tips under a "tips and tricks" section in the gitbootcamp page. |
I used to do method 1 for the reasons everyone outlines, but I have switched to method 3 since I like to think I finally know what git is doing. ;) |
And I should mention that method 3 is rather handy once you're comfortable with git, so it should only be in a section targeting core devs and with a mention that if you don't understand the implications of this shortcut then you shouldn't do it. |
I should also mention that another really useful thing to go with the
That way |
Next action: Add method 3 to section targeting core developers. |
There seem to be 3 variations of the
git push
command:git push origin branchname
and always specify the remote and the branchgit push -u origin branchname
on the first push to setorigin
as the default and then just usegit push
pushdefault
toorigin
in.git/config
and just usegit push
The first method is the one suggested in the devguide
(e.g. in the submitting section); the second is also documented in the pushing changes section; the third is apparently somewhat recent and not yet documented.
The pushdefault is configured by adding to
.git/config
:Where
origin
refers to the user's fork of cpython. AFAICT almost all the pushes should go toorigin
.Each method has pros and cons:
First method:
Second method:
Third method:
hg push
The question is: which one should we adopt as the recommended method?
The text was updated successfully, but these errors were encountered: