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

Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 7, 2014, 20:48 UTC
Message-ID
<xmqqzjn7bjre.fsf@gitster.dls.corp.google.com>
In-Reply-To
<20140107204035.GA27932@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 11 quoted lines
> The point was that the meaning of "@{upstream}" (and "branch.*.merge")
> is _already_ "forked-from", and "push -u" and "push.default=upstream"
> are the odd men out. If we are going to add an option to distinguish the
> two branch relationships:
>
>   1. Where you forked from
>
>   2. Where you push to
>
> we should leave @{upstream} as (1), and add a new option to represent
> (2). Not the other way around.
That matches my feeling as well.

I am not sure if "push -u" is truly odd man out, though. It was an invention back in the "you fetch from and push to the same place and there is no other workflow support" days, and in that context, the "upstream" meant just that: the place you fetch from, which happens to be the same as where you are pushing to right now. If "push -u" suddenly stopped setting the configuration to merge back from where it is pushing, that would regress for centralized folks, so I am not sure how it could be extended to also support triangular folks, but I do think @{upstream} should mean "this is where I sync with to stay abreast with others".

Previous: Jeff KingNext: Ramkumar Ramachandra
Message 4 of 37 in “format-patch: introduce branch.*.forkedFrom”
  1. format-patch: introduce branch.*.forkedFromRamkumar Ramachandra, Jan 7, 2014
  2. Ramkumar RamachandraJan 7, 2014
  3. Jeff KingJan 7, 2014
  4. Junio C HamanoJan 7, 2014
  5. Ramkumar RamachandraJan 7, 2014
  6. Jeff KingJan 7, 2014
  7. Ramkumar RamachandraJan 7, 2014
  8. 0/5 <branch>@{publish} shorthandJeff King, Jan 8, 2014
  9. 1/5 sha1_name: refactor upstream_markJeff King, Jan 8, 2014
  10. 2/5 interpret_branch_name: factor out upstream handlingJeff King, Jan 8, 2014
  11. Ramkumar RamachandraJan 8, 2014
  12. 3/5 branch_get: return early on errorJeff King, Jan 8, 2014
  13. 4/5 branch_get: provide per-branch pushremote pointersJeff King, Jan 8, 2014
  14. Jeff KingJan 8, 2014
  15. t5531: further "matching" fixupsJeff King, Jan 8, 2014
  16. Junio C HamanoJan 10, 2014
  17. Jeff KingJan 11, 2014
  18. Jeff KingJan 8, 2014
  19. 5/5 implement @{publish} shorthandJeff King, Jan 8, 2014
  20. Junio C HamanoJan 8, 2014
  21. Jeff KingJan 9, 2014
  22. Junio C HamanoJan 9, 2014
  23. Philip OakleyJan 9, 2014
  24. Jeff KingJan 9, 2014
  25. Junio C HamanoJan 9, 2014
  26. Junio C HamanoJan 24, 2014
  27. Jeff KingJan 24, 2014
  28. Ramkumar RamachandraJan 24, 2014
  29. Junio C HamanoJan 24, 2014
  30. Philip OakleyFeb 15, 2014
  31. Jeff KingFeb 18, 2014
  32. Johan HerlandFeb 18, 2014
  33. Junio C HamanoFeb 18, 2014
  34. Ramkumar RamachandraJan 8, 2014
  35. Junio C HamanoJan 7, 2014
  36. Ramkumar RamachandraJan 7, 2014
  37. Junio C HamanoJan 7, 2014

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.