From: Ingo Rohloff <lundril@gmx.de>
To: git@vger.kernel.org
Subject: Documentation about "push.default=upstream" is confusing
Date: Sun, 9 Feb 2014 17:31:57 +0100 [thread overview]
Message-ID: <20140209163157.GA7652@localhost> (raw)
Hello,
I recently started to use git and now are digging through more and more
of the low level details.
What I recently tried was to do this for a repository created by Bob:
git remote add -t for_bob anna <url>
So setup a remote (created by anna) for which a branch called
"for_bob" is fetched.
Then "git fetch anna".
Then
git checkout -b from_anna anna/for_bob
So create a "from_anna" branch in Bobs repository which tracks the "for_bob"
branch in the remote "anna" repository.
Now "git pull" works as expected for the "from_anna" branch.
But "git push" does not, because "from_anna" has a different branch name
than the branch you want to push to (you want to push to the "for_bob"
branch).
So after googling I found out about the "push.default=upstream" config
option, which seems to do exactly what I want: It uses the tracking
information to decide to which remote branch I want to push.
Now for cross checking I looked up the documentation of "push.default" at
http://git-scm.com . It says:
----- snip ------
push.default ...
upstream - push the current branch back to the branch whose changes are
usually integrated into the current branch (which is called @{upstream}).
This mode only makes sense if you are pushing to the same repository you
would normally pull from (i.e. central workflow).
----- snip -----
I think the second sentence here is quite confusing.
To me it seems "push.default=upstream" is actually the best choice for a
*de-centralized* workflow.
Rationale:
Assume I pull the "master" branch from several remote repositories
(de-centralized workflow I guess).
To handle that I setup several remote tracking branches called:
repo1_master (tracks repo1/master)
repo2_master (tracks repo2/master)
reap3_master (tracks repo3/master)
Now without "push.default=upstream" I would have to either always explicitly
do something like:
git push repo1 repo1_master:master
git push repo2 repo2_master:master
Or modify ".git/config" to add that per default via "push=" entries.
Whereas with "push.default=upstream" everything works as expected it seems.
So if I am not wrong here, I would propose to rephrase the sentence
------ snip -----
This mode only makes sense if you are pushing to the same repository you
would normally pull from (i.e. central workflow).
------ snip -----
To do that: Could someone point out, when it does NOT make sense to use
"push.default=upstream" ?
with best regards
Ingo
next reply other threads:[~2014-02-09 16:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-09 16:31 Ingo Rohloff [this message]
2014-02-10 19:06 ` Documentation about "push.default=upstream" is confusing Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140209163157.GA7652@localhost \
--to=lundril@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.