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

Re: [PATCH 3/6] push: change `simple` to accommodate triangular workflows

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 20, 2013, 21:56 UTC
Message-ID
<7v38scqwej.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CALkWK0mTthYyHRkxqK2Z3uP3uUmtQADyZt7CERY_40iQSQyzAA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
Show 16 quoted lines
> Junio C Hamano wrote:
>>> They're not the same thing.  It is very much intentional and intended:
>>> the safety net is not to "ensure that the push and pull are
>>> symmetrical" (i.e. among other things, error out if
>>> branch.$branch.merge is unset), but rather "ensure that the push and
>>> pull are never asymmetrical".
>>
>>     not to "ensure that the push and pull are symmetrical"
>>     rather "ensure that the push and pull are never asymmetrical".
>>
>> They still talk the same thing to me.  What am I missing?
>
> Never mind the wording then.  I am proposing preventing asymmetry by
> explicitly disallowing a push when $branch is different from
> branch.$branch.merge, instead of shutting down immediately when
> branch.$branch.merge is unset.

We always said "upstream is to update the branch you fetch and integrate with", and tried to make sure the push destination is the branch you configured the current branch (i.e. the one you are trying to push out) to fetch and integrate with. That is how we prevent asymmetry.

We fail if branch.$branch.merge is set to something else. We also fail if branch.$branch.merge is *not* set, because by definition the branch you are trying to push to in that scenario cannot be the branch you fetch and integrat with by "git pull [--rebase]".

I know your patch was attempting to change the behaviour for the latter. You are trying to let anything go if branch.*.merge is not set. How would it help prevent assymetry?

Show 9 quoted lines
>>> Now I'd like to question what you are labelling as "safety".  What is
>>> the consequence of erroring out when branch.$branch.merge is unset
>>> when pushing using `upstream`?
>>
>> Nothing noteworthy.
>>
>> I wasn't suggesting to change what `upstream` does at all.
>
> No, but I did....
Really?  Then where did this come from?
> I didn't want to contaminate this series with an unrelated improvement
> to `upstream`
Show 6 quoted lines
>> If you are using a
>> centralized workflow, and if a branch does not have branch.*.merge
>> configured, we do not know to which branch you are pushing it back,
>> so we error out.
>
> And I said: have a sane default.

Like you said, I do not want to contaminate this series with such an unrelated change. Worse, you are trying to break a sane default by replacing it with "anything goes".

We already have a sane default, which is to error out. We do not need your broken default.

Previous: Ramkumar RamachandraNext: Junio C Hamano
Message 16 of 24 in “push.default in the triangular world”
  1. 0/6 push.default in the triangular worldRamkumar Ramachandra, Jun 19, 2013
  2. 1/6 t/t5528-push-default: remove redundant test_config linesRamkumar Ramachandra, Jun 19, 2013
  3. Junio C HamanoJun 19, 2013
  4. 2/6 config doc: rewrite push.default sectionRamkumar Ramachandra, Jun 19, 2013
  5. Junio C HamanoJun 19, 2013
  6. Junio C HamanoJun 20, 2013
  7. Johan HerlandJun 20, 2013
  8. 3/6 push: change `simple` to accommodate triangular workflowsRamkumar Ramachandra, Jun 19, 2013
  9. Junio C HamanoJun 19, 2013
  10. Junio C HamanoJun 20, 2013
  11. Ramkumar RamachandraJun 20, 2013
  12. Junio C HamanoJun 20, 2013
  13. Philip OakleyJun 20, 2013
  14. Junio C HamanoJun 20, 2013
  15. Ramkumar RamachandraJun 20, 2013
  16. Junio C HamanoJun 20, 2013
  17. Junio C HamanoJun 20, 2013
  18. Junio C HamanoJun 20, 2013
  19. 4/6 push: remove dead code in setup_push_upstream()Ramkumar Ramachandra, Jun 19, 2013
  20. Junio C HamanoJun 19, 2013
  21. 5/6 t/t5528-push-default: generalize test_push_*Ramkumar Ramachandra, Jun 19, 2013
  22. Junio C HamanoJun 19, 2013
  23. 6/6 t/t5528-push-default: test pushdefault workflowsRamkumar Ramachandra, Jun 19, 2013
  24. Junio C HamanoJun 19, 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.