From: Marc Branchaud <mbranchaud@xiplink.com>
To: Jeff King <peff@peff.net>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
Git List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 0/4] Support triangular workflows
Date: Mon, 18 Mar 2013 11:55:56 -0400 [thread overview]
Message-ID: <5147390C.9060907@xiplink.com> (raw)
In-Reply-To: <20130318142526.GA23075@sigill.intra.peff.net>
On 13-03-18 10:25 AM, Jeff King wrote:
> On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
>
>> I've put off implementing remote.default corresponding to
>> remote.pushdefault, as Jeff suggested in [1], because it's currently
>> not an itch; apart from the obvious symmetry, I don't know what
>> purpose it serves: why would anyone want to fetch from a remote other
>> than origin by default? Why wouldn't they simply swap that remote's
>> name with "origin"? However, it's a nice thing to have for symmetry,
>> and it should be trivial to implement: any interested person is
>> welcome to pick it up.
>
> Yeah, I agree that it does not have much point, aside from people who
> have an unreasonable aversion to using the word "origin". There was a
> series posted last summer to add remote.default:
>
> http://article.gmane.org/gmane.comp.version-control.git/201065
>
> It ended up stalled and never got merged. I think the main impetus was
> that "git clone -o foo" should leave "foo" in remote.default (of course,
> that still leaves unanswered why anyone would really want to use "-o
> foo" in the first place).
I'm the guy who dropped the ball on that series. I still intend to pick it
up (honest!) but I just haven't had the time.
The impetus was originally getting relative submodule paths to work on
detached HEADs [1]. My patch for that doesn't work when someone does "clone
-o", because various parts of git assume there's a remote named "origin".
The discussion led to the idea of using the remote name specified during the
initial clone, and implementing that as a remote.default config value.
As for why "clone -o" exists, it was added in v1.1.0:
commit e6c310fd0d7384973efc6b1d5999a5e8a5b2f3bd
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Thu Dec 22 23:37:24 2005 +0100
git-clone: Support changing the origin branch with -o
Earlier, git-clone stored upstream's master in the branch named 'origin',
possibly overwriting an existing such branch.
Now you can change it by calling git-clone with '-o <other_name>'.
[jc: added ref format check, subdirectory safety, documentation
and usage string.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It sounds like the original need for the -o option is no longer pertinent.
OTOH, for folks who deal with several remotes it's nice to name them, and
"origin" isn't necessarily a useful or intuitive name.
M.
[1] http://thread.gmane.org/gmane.comp.version-control.git/200145
prev parent reply other threads:[~2013-03-18 16:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-18 13:16 [PATCH 0/4] Support triangular workflows Ramkumar Ramachandra
2013-03-18 13:16 ` [PATCH 1/4] remote.c: simply a bit of code using git_config_string() Ramkumar Ramachandra
2013-03-18 22:14 ` Eric Sunshine
2013-03-18 13:16 ` [PATCH 2/4] remote.c: introduce a way to have different remotes for fetch/ push Ramkumar Ramachandra
2013-03-18 14:31 ` Jeff King
2013-03-18 14:56 ` Ramkumar Ramachandra
2013-03-18 14:58 ` Jeff King
2013-03-18 22:17 ` Eric Sunshine
2013-03-18 13:16 ` [PATCH 3/4] remote.c: introduce remote.pushdefault Ramkumar Ramachandra
2013-03-18 22:19 ` Eric Sunshine
2013-03-18 13:16 ` [PATCH 4/4] remote.c: introduce branch.<name>.pushremote Ramkumar Ramachandra
2013-03-18 22:23 ` Eric Sunshine
2013-03-18 14:25 ` [PATCH 0/4] Support triangular workflows Jeff King
2013-03-18 14:28 ` Ramkumar Ramachandra
2013-03-18 14:32 ` Jeff King
2013-03-18 15:55 ` Marc Branchaud [this message]
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=5147390C.9060907@xiplink.com \
--to=mbranchaud@xiplink.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=marcnarc@xiplink.com \
--cc=peff@peff.net \
/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.