Re: [RFC PATCH] push: start warning upcoming default change for push.default
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 13, 2012, 22:54 UTC
- Message-ID
- <7v62e8t8m5.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120313213045.GD27436@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The branch.*.pushRemote you mentioned would help with that. But for me, > I would much rather have simply push.defaultRemote.
I would think that is a natural way to extend it. Don't we already have something similar that is per repository default that can be overriden with per branch configuration?
Show 12 quoted lines
> Speaking of which, I often get annoyed at the per-branch > auto-configuration of upstreams. For example, I find myself doing this: > > [get an idea, read a bug report on the list, etc] > $ cd git > $ hack hack hack > [oh, this is turning into something real. Let's make a branch] > $ git checkout -b jk/bug-fix > $ git commit -m 'fix bug' > > but now my bug-fix branch is based off of wherever I was (which is > usually some private topic-integration branch I run most of the time).
What in "checkout -b jk/bug-fix" makes jk/bug-fix a downstream of origin/master? I admit my brain is not working very well today, but I would have expected the branch to have either your local private topic integration branch as its @{u}, or no @{u} defined for it at all. Perhaps there is a design error of some sort around that code?
Show 11 quoted lines
> Which makes me wonder if perhaps people are using "upstream" to mean
> several different thing. I use it to say "this is the branch that this
> topic is based off of", which makes "git log @{u}.." helpful, "git
> rebase -i" just work, and gives some meaning to the ahead/behind message
> (it shows how my topic relates to the main project).
>
> But I think people also use upstream to mean "this is the definitive
> version of this branch in some central repo". So they would say that
> "jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind
> message is about "do I have any local work that needs pushed, or any
> remote work that needs pulled?"I think that is the more common interpretation. Earlier you said ahead/behind gives "some meaning", but compared to this "how many more do I have, how many more do others have while I was looking the other way", I am not sure what kind of cue that "some meaning" would give us.
> And I wonder if this is where some of the debate for > push.default=upstream comes from. Whether that is useful to you or not > would depend on how you set up your branches. In the latter model, I > would think pushing to the upstream would be the right thing.
No question about the conclusion in the last sentence, but at the same time, I do not think the push.default is about making things work smoothly for people who configure everything right.
Show 10 quoted lines
>> Because "upstream" is meant to be "For the branch I am on, you know >> how the branches map between the remote repository, so you already >> know what the right thing to do---do it" mode, the correct "guess" >> in your case is to error out and say "Nah, you are not talking with >> your upstream, so I do not have any clue what branches you want to >> push out and how. As you said that the push.default is upstream, not >> matching, I refuse to even do the matching push in your case. This >> is an error. Be more specific". > > Yeah, I agree that is the only sane thing to do.
Perhaps this can be a good sample entry for the experimental "tracker" thing to keep track of to see how the workflow will evolve around it; unless neither of us would get to work on it immediately, it is very likely to be forgotten, as this is a tangent in the overall discussion, even though the bug is real and solution is clear.