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

Re: Random thoughts on "upstream"

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 17, 2013, 00:00 UTC
Message-ID
<CAMP44s1dB+VQnzPL-qVADMTC6-Y8AfUvBOmy+4kusujyT_jW4g@mail.gmail.com>
In-Reply-To
<7vobca3465.fsf@alter.siamese.dyndns.org>
On Thu, May 16, 2013 at 6:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 43 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Thu, May 16, 2013 at 12:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> The value "upstream" for push.default does not make sense in the
>>> context of a triangular workflow, as you may well base your work on
>>> 'master' from the upstream, which is a branch with a very generic
>>> purpose (e.g. "to advance the state of the overall project"), but
>>> your work may have a more specific purpose (e.g. "to improve frotz
>>> feature") that deserves to be on a branch named after that specific
>>> purpose in the repository you publish your work on.  That is, after
>>> working on your 'frotz' branch this way:
>>>
>>>     git checkout -t -b frotz origin/master
>>>     work work work, commit commit commit
>>
>> If the user has branch.autosetupmerge=always, that's not correct; even doing:
>>
>> % git checkout -b frotz origin/master
>>
>> Would setup the upstream. And I believe for v2.0 we do want
>> branch.autosetupmerge=always, but we might not want to always override
>> the push location.
>>
>>> Now I have a curious value "single" in the above configuration that
>>> is not understood by current Git.  It is to trigger a new rule to
>>> modify the way remote.publish.push refspec is used:
>>>
>>>     When on branch 'frotz', where pushremote_get() would return
>>>     'publish', find where refs/heads/frotz would be pushed with the
>>>     refspec for that remote (i.e. refs/heads/*:refs/heads/topics/*
>>>     maps refs/heads/frotz to refs/heads/topics/frotz) and push only
>>>     that, i.e. update refs/heads/topics/frotz over there with the
>>>     tip of 'frotz' we are pushing.
>>>
>>> That may be a solution for those who do not find 'current' good
>>> enough.
>>
>> What happens if I want to push to 'refs/heads/topics/frotz-for-juno'?
>
> You would weigh pros-and-cons of supporting such a "single branch
> only" special case, and add a branch level override, and if the
> benefit outweighs the cost of complexity, design and implement it.
I already implemented it. I already sent the patch.
-- 
Felipe Contreras
Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 26 in “Random thoughts on "upstream"”
  1. Junio C HamanoMay 16, 2013
  2. Felipe ContrerasMay 16, 2013
  3. Junio C HamanoMay 16, 2013
  4. Felipe ContrerasMay 17, 2013
  5. Junio C HamanoMay 17, 2013
  6. Felipe ContrerasMay 17, 2013
  7. Felipe ContrerasMay 17, 2013
  8. Ramkumar RamachandraMay 17, 2013
  9. Junio C HamanoMay 17, 2013
  10. Ramkumar RamachandraMay 17, 2013
  11. Junio C HamanoMay 17, 2013
  12. Ramkumar RamachandraMay 18, 2013
  13. Ramkumar RamachandraMay 18, 2013
  14. Felipe ContrerasMay 18, 2013
  15. Felipe ContrerasMay 18, 2013
  16. Junio C HamanoMay 19, 2013
  17. Ramkumar RamachandraMay 19, 2013
  18. Felipe ContrerasMay 19, 2013
  19. Ramkumar RamachandraMay 19, 2013
  20. Felipe ContrerasMay 19, 2013
  21. Junio C HamanoMay 20, 2013
  22. Ramkumar RamachandraMay 23, 2013
  23. Felipe ContrerasMay 23, 2013
  24. Junio C HamanoMay 23, 2013
  25. Ramkumar RamachandraMay 23, 2013
  26. Ramkumar RamachandraMay 24, 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.