Re: [RFC PATCH] push: start warning upcoming default change for push.default

lists@haller-berlin.de (Stefan Haller) writes:

Marc Branchaud [off-list ref] wrote:

quoted

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.

Not for us, no.  (But this is maybe a different topic.)

In our workflow (centralized repository), we never ever have a local
branch with a different name than its upstream branch. Never.

When we say

  git checkout -b topic origin/master

then it's always a mistake, and what we really meant was

  git checkout -b --no-track topic origin/master

It would have been nice if you explained larger picture of your
workflow, as almost anything else in life, a blanket statement like
the above is not a universal truth.  It is clear you were aware of
that from your "Not for *us*", there is not enough clue for others
to tell if their workflow is similar to yours to decide if the above
rule of thumb of yours is a good one to follow for them.

Let's illustrate what I mean by "explain larger picture of workflow"
with a few examples.

An example of where "checkout -b topic origin/master" would not be a
mistake is when it is the norm for your project for contributors to
integrate their work with "pull --rebase", it is perfectly sensible
for a contributor to

	git checkout -b frotz origin/master

to start working on his feature "frotz", and way before the feature
becomes ready, starting to work on unrelated feature "nitfol" with

	git checout -b nitfol origin/master

and keep building these in parallel, running "git pull --rebase" to
float yet-to-be-published his own work on updated the shared history
before continuing to work on a topic until the feature is done.  As
the contributor may not know upfront which of these independent
features will become ready when he starts working, it is sensible
to be on the latter "nitfol" topic and "git push" it to update the
shared history with the finished work on the branch.

In this case, you would want "git push" a branch to its @{upstream}.

Another example that "checkout -b topic origin/master" would not be
a mistake is when you fork your favorite project at GitHub, work on
two independent topics. You work the same way as the above (you may
not "pull --rebase", though), and then push both of them out and ask
them to be pulled "Please pull my 'frotz' and 'nitfol' branches".

In this case, you would want "git push" a branch to update the
branch with the same name (i.e. either 'current' or 'matching').

Junio C Hamano [off-list ref] wrote:

lists@haller-berlin.de (Stefan Haller) writes:

quoted

When we say

  git checkout -b topic origin/master

then it's always a mistake, and what we really meant was

  git checkout -b --no-track topic origin/master

It would have been nice if you explained larger picture of your
workflow, as almost anything else in life, a blanket statement like
the above is not a universal truth.

I wasn't saying that "checkout -b topic origin/master" isn't useful for
*anybody*; it's just not useful for us.  But you are right, I should
have explained who "us" is, and what our workflow is, sorry.

We're a closed-source company that uses git more or less like an
old-style, non-distributed VCS. (This is not because "we don't get it",
as someone phrased it elsewhere in this thread, but because it's what
makes most sense for us.)

The central repository has special significance, because it sends an
email for every commit, and it is hooked up to the CI system. For these
reasons, everything that people work on is pushed to the central
repository, on a topic branch with the same name as the local branch.
Also, it is very common for two or more developers to collaborate on a
topic branch, and the central repository is the hub for this (developers
pull topics with "pull --rebase"). There's no direct exchange between
developer's clones, because others on the team wouldn't see a commit
mail.

Topics are never pushed to master; we have a "merge --no-ff" policy for
integration.

Sometimes, we need to branch a topic (let's call it B) off another topic
(say A), because B needs some of A's code before it's integrated (we'll
rebase B onto master once A is merged back, to keep the history clean).
Same thing here: we say "checkout -b B origin/A", but we don't want to
have B's upstream to be set to origin/A. Again, we forgot to say
--no-track.

To sum it up, push.default=current is almost perfect for this kind of
workflow; except that you still need to configure your upstream branches
so that pull works, and status (and the shell prompt) displays the right
information.


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/