git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>,
	Leandro Lucarella <leandro.lucarella@sociomantic.com>
Subject: Re: [PATCH 2/4] push: make upstream, simple work with pushdefault
Date: Mon, 10 Jun 2013 14:13:45 +0530	[thread overview]
Message-ID: <CALkWK0mesZay8Cpi6yTvhUG=136=9JLyFUZXm8t_fMOrY0F62Q@mail.gmail.com> (raw)
In-Reply-To: <7vip1moq3k.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> I am not sure what you mean by artificial.

By artificial, I mean that the precondition is absolutely unnecessary
for the code following it to work.  The precondition was introduced in
a separate commit, specifically denying one usecase because the author
(you) thought that made sense.

> If you have push.default set upstream or simple, then a push run
> while on the branch 'foo' will figure out what happens when you do a
> fetch by looking at 'branch.foo.merge' to find the branch we are set
> to integrate from 'branch.foo.remote' remote.  The simple further
> says that branch name must be the same as 'foo'.

I understand this perfectly well, as evidenced by the tests I've
written out in 4/4.

> And that is what setup_push_UPSTREAM() is designed to do.  Rejecting
> a call that breaks the precondition is perfectly the right thing to
> do: if you set to push to "upstream" and if you are trying to push
> to a different remote, for example.
>
> The triangle topic changed the precondition without updating the
> logic to check it, which was the bug, not the original check.

Did I claim otherwise?  :)
The topic is about fixing a bug introduced by rr/triangle.

> I actually am OK with 'upstream' that rejects triangular, while
> making 'simple' do something different [*1*].

Okay, so you haven't outlined a solution either.  Like I said in the
cover-letter, I've spent hours breaking my head and can't figure out a
better solution.  The bigger problem is that upstream/ simple were
designed with only central workflows in mind.  How do we deal with it
now?

Yes, upstream/ simple work only when @{u} resolves, and I haven't
changed this (because we don't have a well-defined meaning for what
branch.<name>.merge without a branch.<name>.remote means).  My
argument is very simple: no push.default mode should not dictate the
push destination; only the push refspec.  What makes sense to the user
is an upstream/ simple that works as expected with pushdefault: do the
tests I've outlined in 4/4 not make sense?  *scratches head*

I don't understand why upstream/ simple should _not_ push to a
different destination from the one being merged from.  I'll repeat:
push source/ destination is orthogonal to push refspec, and
push.default modes dictate the refspec.

  reply	other threads:[~2013-06-10  8:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-09 17:13 [PATCH 0/4] Fix triangular workflows for upstream, simple Ramkumar Ramachandra
2013-06-09 17:13 ` [PATCH 1/4] t/push-default: remove redundant test_config lines Ramkumar Ramachandra
2013-06-09 17:13 ` [PATCH 2/4] push: make upstream, simple work with pushdefault Ramkumar Ramachandra
2013-06-09 22:51   ` Junio C Hamano
2013-06-10  8:43     ` Ramkumar Ramachandra [this message]
2013-06-10  9:37       ` Junio C Hamano
2013-06-10 11:48         ` Ramkumar Ramachandra
2013-06-10 15:47           ` Junio C Hamano
2013-06-10 16:07             ` Ramkumar Ramachandra
2013-06-10 19:09               ` Junio C Hamano
2013-06-13  9:10                 ` Ramkumar Ramachandra
2013-06-13 16:48                   ` Junio C Hamano
2013-06-13 17:39                     ` Junio C Hamano
2013-06-13 17:45                       ` Ramkumar Ramachandra
2013-06-09 17:13 ` [PATCH 3/4] t/push-default: generalize test_push_{success, commit} Ramkumar Ramachandra
2013-06-09 17:13 ` [PATCH 4/4] t/push-default: test pushdefault with all modes Ramkumar Ramachandra

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='CALkWK0mesZay8Cpi6yTvhUG=136=9JLyFUZXm8t_fMOrY0F62Q@mail.gmail.com' \
    --to=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=leandro.lucarella@sociomantic.com \
    /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).