From: "Wesley J. Landaker" <wjl@icecavern.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Thomas Rast" <trast@student.ethz.ch>,
git@vger.kernel.org, "Björn Steinbrink" <B.Steinbrink@gmx.de>
Subject: Re: [RFC] pull/fetch rename
Date: Tue, 20 Oct 2009 20:01:43 -0600 [thread overview]
Message-ID: <200910202001.44079.wjl@icecavern.net> (raw)
In-Reply-To: <7v7huplkyj.fsf@alter.siamese.dyndns.org>
On Tuesday 20 October 2009 17:11:32 Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
> > Junio C Hamano wrote:
> >> "Wesley J. Landaker" <wjl@icecavern.net> writes:
> >
> > ...
> > There would not be a configuration option.
> > ...
> >
> >> It's not even funny.
>
> Re-read what you were responding to and notice that I was commenting on
> Wesley's proposal that _is_ about a configuration variable.
Yes, I brought up the configuration variable, not Thomas.
My main goal was to try to suggest a transition plan that would be less
painful, but maybe it was actually worse. After reading Junio's response I
think I agree that going down that path might be the worst of both worlds,
but the basic model I was proposing (even if it's a bad idea in this case)
was largely basing on (my perceived impression of) how the recent changes to
push behavior were staged (i.e. with deprecation, new configuration
variables, etc).
I still think that, long term, making push and pull symmetric, EITHER by 1)
making push also update the working tree (in some sane way that I don't have
a proposal for) or 2) making pull be just about transfering objects, not
also merging (in some reasonable way that doesn't break useability, like
also adding "git update" or something at the same time) would be an overall
benefit.
next prev parent reply other threads:[~2009-10-21 2:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-20 17:47 [RFC] pull/fetch rename Thomas Rast
2009-10-20 19:59 ` Wesley J. Landaker
2009-10-20 21:46 ` Junio C Hamano
2009-10-20 22:53 ` Thomas Rast
2009-10-20 23:11 ` Junio C Hamano
2009-10-21 2:01 ` Wesley J. Landaker [this message]
2009-10-20 23:16 ` Junio C Hamano
2009-10-20 21:42 ` Nanako Shiraishi
2009-10-20 22:41 ` Thomas Rast
2009-10-20 23:56 ` Daniel Barkalow
2009-10-21 3:06 ` Björn Steinbrink
2009-10-21 4:22 ` Daniel Barkalow
2009-10-21 11:57 ` Björn Steinbrink
2009-10-21 17:12 ` Daniel Barkalow
2009-10-21 6:22 ` Junio C Hamano
2009-10-21 17:19 ` Clemens Buchacher
2009-10-21 17:21 ` [PATCH] modernize fetch/merge/pull examples Clemens Buchacher
2009-10-21 21:38 ` Junio C Hamano
2009-10-21 21:41 ` [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given Junio C Hamano
2009-10-22 10:21 ` Nanako Shiraishi
2009-10-22 22:26 ` Junio C Hamano
2009-10-21 21:46 ` [PATCH] git-merge: imply --no-ff " Junio C Hamano
2009-10-22 6:35 ` Clemens Buchacher
2009-10-22 8:51 ` [PATCH] modernize fetch/merge/pull examples Thomas Rast
2009-10-22 9:48 ` [RFC] pull/fetch rename Thomas Rast
2009-10-21 6:30 ` Mike Hommey
2009-10-21 6:33 ` Junio C Hamano
2009-10-21 7:06 ` Mike Hommey
2009-10-21 7:22 ` Junio C Hamano
2009-10-21 7:45 ` Jeff King
2009-10-21 7:47 ` Jeff King
2009-10-24 6:30 ` 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=200910202001.44079.wjl@icecavern.net \
--to=wjl@icecavern.net \
--cc=B.Steinbrink@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=trast@student.ethz.ch \
/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.