git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/4] push: make upstream, simple work with pushdefault

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Jun 10, 2013, 16:07 UTC
Message-ID
<CALkWK0mfWs3LBocvn=QMcX0_ZCROx4Nw=+xjpCbKLQU0JzSdXg@mail.gmail.com>
In-Reply-To
<7vwqq2j7c9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 5 quoted lines
> 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.

Show 7 quoted lines
> 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).

Show 7 quoted lines
> 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.
Previous: Junio C HamanoNext: Junio C Hamano
Message 9 of 16 in “Fix triangular workflows for upstream, simple”
  1. 0/4 Fix triangular workflows for upstream, simpleRamkumar Ramachandra, Jun 9, 2013
  2. 1/4 t/push-default: remove redundant test_config linesRamkumar Ramachandra, Jun 9, 2013
  3. 2/4 push: make upstream, simple work with pushdefaultRamkumar Ramachandra, Jun 9, 2013
  4. Junio C HamanoJun 9, 2013
  5. Ramkumar RamachandraJun 10, 2013
  6. Junio C HamanoJun 10, 2013
  7. Ramkumar RamachandraJun 10, 2013
  8. Junio C HamanoJun 10, 2013
  9. Ramkumar RamachandraJun 10, 2013
  10. Junio C HamanoJun 10, 2013
  11. Ramkumar RamachandraJun 13, 2013
  12. Junio C HamanoJun 13, 2013
  13. Junio C HamanoJun 13, 2013
  14. Ramkumar RamachandraJun 13, 2013
  15. 3/4 t/push-default: generalize test_push_{success, commit}Ramkumar Ramachandra, Jun 9, 2013
  16. 4/4 t/push-default: test pushdefault with all modesRamkumar Ramachandra, Jun 9, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.