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.
next prev parent 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).