On 12-03-09 05:25 AM, Carlos Martín Nieto wrote:
On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote:
More inexperienced users will often push right after committing, and at
that time they're still very much in the "working-on-one-branch" state of
mind. "upstream" would be a safer default mode of operation for 'git push'
for them even when they have their personal publishing repository (also in
a shared public repository settings, "matching" is rarely the right
default mode).
In preparation for flipping the default to the "upstream" mode from the
"matching" mode that is the upstream default, start warning users when they
rely on unconfigured "git push" to default to the "matching" mode.
Original patch and commit message by: Junio C Hamano<gitster@xxxxxxxxx>
Signed-off-by: Matthieu Moy<Matthieu.Moy@xxxxxxx>
---
This patch prepares a transition to 'upstream', unlike the previous
version which was advertizing 'current'. In most case, this would be
the same, but 'upstream' is probably more sensible in case it points
to a branch other than 'current'. I don't care much either way.
For people using git as VCS that happens to have local history rather
than taking full advantage of the distributed nature (or who aren't
aware of it or don't get it), 'matching' is bound to be confusing.
However, IMO 'current' makes more sense. Consider
git clone ../foo; cd foo;
git checkout -b topic origin/develop
ed main.c
git push
With upstream I've just updated origin's dev branch, even though I might
have meant to create a new 'topic' branch. Alternatively, I might have
run
git checkout -b topic
in which case I certainly want 'current'. I don't see that workflow
where the upstream branch is named differently from the local one should
be that big a consideration when trying to determine a default to help
people unfamiliar as they'd be certainly more likely to consider branch
names to be binding. Maybe you have seen this differently in your
students, but that's the impression I get from #git.
I disagree and consider "upstream" to be the more reasonable default.
I think that an incantation like
git checkout -b topic origin/master
makes it pretty clear that topic is meant to be merged into origin's
master branch. And so a simple "git push" as you describe I think
*should* update origin's master branch.
OTOH, with a default of "current" I believe the simple "git push" will
create a new branch named topic in the origin repo. To me that's
implying too much from the simple "git push" command. If the user
really wants a branch named topic in the origin repo, I think it's
reasonable for git's default behaviour to require the user to say so
explicitly ("git push origin topic").
I also disagree that an incantation like
git checkout -b topic
means that the user wants "current" when they "git push". There's no
indication here that the user is at all interested in remote branches
with this topic, and I think it would be presumptuous for git to make
such a link by default. (Besides, what if the user has more than one
remote? Which should be used?)
In this case the "upstream" default would mean that git couldn't
identify a remote for the topic branch and so the "git push" would fail.
I think that's appropriate, because the user never told git how the
topic branch relates to any remote branches.
M.
--
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