git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jardel Weyrich <jweyrich@gmail.com>
Cc: Michael J Gruber <git@drmicha.warpmail.net>,
	Sascha Cunz <sascha-ml@babbelbox.org>,
	"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [BUG] Possible bug in `remote set-url --add --push`
Date: Mon, 14 Jan 2013 22:39:30 -0800	[thread overview]
Message-ID: <7vip6z54rh.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7vpq1755jb.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Mon, 14 Jan 2013 22:22:48 -0800")

Junio C Hamano <gitster@pobox.com> writes:

> Jardel Weyrich <jweyrich@gmail.com> writes:
>
>> If you allow me, I'd like you to forget about the concepts for a minute, and focus on the user experience.
>> Imagine a simple hypothetical scenario in which the user wants to push to 2 distinct repositories. He already has cloned the repo from the 1st repository, thus (theoretically) all he needs to do, is to add a new repository for push. He then uses `remote set-url --add --push <2nd-repo>` (which I personally thought would suffice). However, if he tries to push a new commit to this remote, it would be pushed _only_ to the 2nd-repo.
>
> The primary reason behind push-url was that
>
>  (1) usually you push to and fetch from the same, so no pushUrl is
>      ever needed, just a single Url will do (this is often true for
>      cvs/svn style shared repository workflow); and
>
>  (2) sometimes you want to fetch from one place and push to another
>      (this is often true for "fetch from upstream, push to my own
>      and ask upstream to pull from it" workflow), and in that case
>      you want pushUrl in addition to Url.  Most importantly, in this
>      case, you do *NOT* want to push to Url.  You only push to
>      pushUrl.
>
> Setting *one* pushURL is a way to say "That URL I fetch from is
> *not* the place I want to push (I may not even be able to push
> there); when I say 'push', push there instead".  Your proposed
> semantics will make it impossible to arrange such an asymmetric
> setting.

Now I think I finally see where that misunderstanding comes from.
It is "remote -v" that is misdesigned.

    $ git clone ../there here
    $ cd here
    $ git remote -v
    origin /var/tmp/there (fetch)
    origin /var/tmp/there (push)

This is totally bogus.  It should report something like this:

    $ git remote -v
    origin /var/tmp/there (fetch/push)

Then after running "git remote set-url --push origin ../another" we
should see

    $ git remote -v
    origin /var/tmp/there (fetch)
    origin /var/tmp/another (push)

which would make it clear that the original fetch/push came from the
(1) usuall you push and fetch from the same place so there is only
one setting, and the two lines came from the (2) sometimes you need
a separate places to fetch from and push to.

At this point, if you say "set-url --push origin ../third", then
"another" will disappear and gets replaced by "third"; if you
instead say "set-url --add --push origin ../third", then we will see
two (push) lines, in addition to one (fetch), making it clear that
you are still in (2) above, fetching from and pushing to different
places, and having two places to push to.

I misread your response

    From: Jardel Weyrich <jweyrich@gmail.com>
    Subject: Re: [BUG] Possible bug in `remote set-url --add --push`
    Date: Sat, 12 Jan 2013 06:09:35 -0200
    Message-ID: <CAN8TAOvP_HX6BEK86aYoX-kVqWDmsbyptxTT2nk+fx+Ut1Tojg@mail.gmail.com>

where you showed that there was only remote.origin.url (and no
pushurl) in the first step, and somehow thought you had a
remote.origin.pushurl in the first place.

  reply	other threads:[~2013-01-15  6:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-12  5:44 [BUG] Possible bug in `remote set-url --add --push` Jardel Weyrich
2013-01-12  7:10 ` Junio C Hamano
2013-01-12  8:09   ` Jardel Weyrich
2013-01-12  8:23     ` Junio C Hamano
2013-01-12  8:44   ` Sascha Cunz
2013-01-12  9:33     ` Jardel Weyrich
2013-01-14 13:07       ` Michael J Gruber
2013-01-14 16:41         ` Jonathan Nieder
2013-01-14 19:09         ` Junio C Hamano
2013-01-15  5:20           ` Jardel Weyrich
2013-01-15  6:22             ` Junio C Hamano
2013-01-15  6:39               ` Junio C Hamano [this message]
2013-01-15  9:44                 ` Michael J Gruber
2013-01-15 15:53                   ` Junio C Hamano
2013-01-16  8:46                     ` Michael J Gruber
2013-01-16 15:50                       ` Junio C Hamano
2013-01-16 16:19                         ` Michael J Gruber
2013-01-16 19:30                         ` Andreas Schwab
2013-01-16 20:01                           ` Junio C Hamano
2013-01-16 10:14                     ` [PATCH] git-remote: distinguish between default and configured URLs Michael J Gruber
2013-01-16 10:27                       ` Michael J Gruber
2013-01-16 10:42                       ` John Keeping
2013-01-16 12:45                         ` Michael J Gruber
2013-01-16 13:04                           ` John Keeping
2013-01-16 19:19                           ` Junio C Hamano
2013-01-16 16:15                     ` [BUG] Possible bug in `remote set-url --add --push` Phil Hord
2013-01-16 16:24                       ` Michael J Gruber

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vip6z54rh.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=jweyrich@gmail.com \
    --cc=sascha-ml@babbelbox.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).