Jeff King <peff@xxxxxxxx> 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?
> 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?
> 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.
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html