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 21:37:01 +0530	[thread overview]
Message-ID: <CALkWK0mfWs3LBocvn=QMcX0_ZCROx4Nw=+xjpCbKLQU0JzSdXg@mail.gmail.com> (raw)
In-Reply-To: <7vwqq2j7c9.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> Only if I want to publish the result of the work forked from your
> "triangle" as my "triangle", but that is not the case.  A fork to be
> integrated by other is by definition more specialized than the
> original, and I would publish my "pushbranch" subtopic as such, not
> as "triangle".

Okay, so it should _never_ push out as "triangle", because it is an
insane default.

> But that is not what is happening, unless you keep thinking
> "push.default decides the name of the branch regardless of what
> repository it lives in", which is where our difference lies, I
> think.

I assumed that we want all push.default modes to do something
"sensible" in both central and triangular workflows.  push.default
dictating a push destination would break triangular workflows.  It's
very clear to me.

> Imagine the case where I forked two branches from your "triangle"
> topic and pushing them to my repository using the triangular
> workflow.  By your definition, they will both try to push to
> "triangle", which means you, the "triangle" topic maintainer, cannot
> receive two independent pull requests from me.  You can only get a
> single branch that pre-merges both, and if you want to get one but
> not the other, you have to do the untangling of these two topics.

Okay, you've made your point.  Due to namespace conflict, the solution
I proposed is not at all a "sane" default.  It's just confusing and
Bad (TM).

> I am not saying that you have to pick one to use for push.default
> among the remaining ones (i.e. matching, current, what else?).  It
> is very plausible that the triangular workflow wants a different
> logic to pick what branches are to be updated and how.  Perhaps we
> would want something that is capable of mapping your local branch
> name to a branch name suitable in your publishing repository, and I
> am not opposed to have such a mode.

Okay, we'll have to do some sort of split and mark push.default =
upstream/ simple suitable-only-for-centralized-workflows, or something
to that effect (deprecation?) :|

I'll try to think of something.

  reply	other threads:[~2013-06-10 16:07 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
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 [this message]
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='CALkWK0mfWs3LBocvn=QMcX0_ZCROx4Nw=+xjpCbKLQU0JzSdXg@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).