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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).