From: Junio C Hamano <junkio@cox•net>
To: Josef Weidendorfer <Josef.Weidendorfer@gmx•de>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
Date: Wed, 06 Dec 2006 19:44:55 -0800 [thread overview]
Message-ID: <7v64cowers.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <200612070349.58521.Josef.Weidendorfer@gmx.de> (Josef Weidendorfer's message of "Thu, 7 Dec 2006 03:49:57 +0100")
Josef Weidendorfer <Josef.Weidendorfer@gmx•de> writes:
> IMHO there only should be one place/command which is creating new branches,
> and which is called by other porcelain commands [*1*].
Giving an option to git branch to set something like this up
would be nice. I would agree the division of labor you propose
is a good way to keep the scripts maintainable.
It however is a different matter if we would want to set up the
merge default always in the way you propose for a new branch at
the policy level.
It also is a different matter if "git branch" has enough
information to figure out which upstream "origin" needs to be
fetched from, given an origin SHA-1 expression to create a new
branch from, at the technical level
It entirely is possible to use the same remotes/origin/
hierarchy to track two physically different URLs (thus two
different "origin"s) on a mobile machine that has different
connectivity to the outside world depending on where you are
("that mirror is closer from here" and "I need to go over the
firewall while I am here"). Because they track the logically
same repository, it does not make sense to use different
hierarchies under remotes/ for this purpose.
In such a setup, "git branch new origin/for-public" would not be
able to tell which "origin" to fetch from, so it may not even be
feasible to do what you propose without an explicit help from
the command line option. At least, however, the call to "git branch"
you would add as a part of this proposal to "git clone" would
know which URL, because at that point it would not even know
about the alternate connectivity yet.
> Why should we not setup branch.*.merge when a create a new development
> branch from a tracking branch via "git branch", or "git checkout -b"?
So while I am definitely in favor of the technical side of your
proposal to have "git checkout -b" use "git branch", instead of
doing it by hand, I think it would be an easier sell to separate
the policy from the discussion at least in the beginning.
I say this not because I disagree with your question: "Why
should we not?" I do not have a ready-answer to that rhetorical
question yet. But that is different from saying "it does not
make sense to do this setup because of such and such concrete
reasons", so I haven't formed an opinion on this policy matter
yet.
next prev parent reply other threads:[~2006-12-07 3:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-06 12:07 [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone Andy Parkins
2006-12-06 12:20 ` Johannes Schindelin
2006-12-06 12:27 ` Jakub Narebski
2006-12-06 12:55 ` Andy Parkins
2006-12-06 12:36 ` Peter Baumann
2006-12-06 17:00 ` Josef Weidendorfer
2006-12-06 17:15 ` Jakub Narebski
2006-12-06 23:23 ` Johannes Schindelin
2006-12-07 2:49 ` Josef Weidendorfer
2006-12-07 3:44 ` Junio C Hamano [this message]
2006-12-07 14:52 ` Josef Weidendorfer
2006-12-07 14:13 ` Johannes Schindelin
2006-12-07 14:44 ` Josef Weidendorfer
2006-12-08 10:36 ` Jakub Narebski
2006-12-07 6:49 ` Aneesh Kumar K.V
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=7v64cowers.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=Josef.Weidendorfer@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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