Jørgen Edelbo <jed@xxxxxxxxxxxx> writes:
>> You say I can only push HEAD. I understand this that I have to stop work on C
>> (perhaps commit or stash any unfinished work), then checkout A, push it,
>> checkout B, push it, checkout C and unstash the unfinished work. If my
>> understanding is correct, the new restriction is a no-go.
>
> Ok, this way of working is not supported. It just never occurred to me that
> you would work this way. Forgetting to push something that you have just
> completed is very far from what I am used to. I think it comes most natural
> to push what you have done before changing topic. The reason I make a commit
> is to get it out of the door.
People work in very different ways, and mine and yours are extreme
opposites. I almost never push out a commit that is just off the
press, I use topic branches heavily and work on multiple topics
(either related or unrelated) in parallel all the time, so it is
very usual for me to push out more than one branches with a single
push---by definition, if we support pushing only the current branch
out, "working on more than one topics and after perfecting these,
push them together" cannot be done.
If one sets push.default to something other than the matching, and
does not have any remote.*.push refspec in the configuration, J6t's
"I forgot to push while I was on that branch" and my "I deliberately
did not push those branches out while I was on them, but now I know
I am ready to push them out" cannot be done without explicit
refspecs on the command line.
But stepping back a bit, I think this "I commit because I want to
get it out the door" is coming from the same desire that led to a
possible design mistake that made various push.default settings push
only the current branch out.
The possible design mistake that has been disturbing me is the
following.
The "push.default" setting controls two unrelated things, and that
is one too many. Between the matching modes and the rest, it tells
what branch(es) are pushed out (either "all the branches with the
same name" or "the current branch"). That is one thing, and I tend
to agree that "push only the current branch" would be a sane default
many people would prefer (and that is the reason we made it the
default for Git 2.0).
Among the various non matching modes, it also determines where a
branch that is pushed out would go ("current" pushes to the same
name, "upstream" pushes to @{upstream}, etc.). But this "once I
choose what branch to push out, the branch being pushed out knows
where it wants to go", does not take effect if one explicitly names
what to push, e.g. in this sequence where one forgets to push
'frotz' out:
j6t$ git checkout frotz
... work work work ...
j6t$ git checkout xyzzy
... work work work ...
... realize 'frotz' is done
j6t$ git push origin frotz
The last push may work differently from the push in this sequence:
j6t$ git checkout frotz
... work work work ...
j6t$ git push ;# or "git push origin"
In the latter sequence, the niceties of push.upstream to push
'frotz' out to the frotz@{upstream} (and your "git push origin
refs/heads/frotz:refs/for/frotz" mapping done in git-gui) will take
effect, but in the former, the refspec "frotz" on the command line
is taken as a short-hand for "frotz:frotz".
We may want to teach "git push" that the command line refspec that
names a local branch may not be pushing to the same name but wants
to go through the same "mapping" used when "git push" is done while
the branch is checked out, with some mechanism.
It is a separate but very related topic, I think.
--
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