I guess from my perspective, for these repositories, my fork _is_ the "origin"; I tend to mirror the repositories I contribute to (e.g. use the "fork" feature on Git{Hub,Lab}/etc), then clone my mirror, which lends itself to that mental model (origin is "mine").
--
Ben Denhartog
ben@xxxxxxxxxxxxx
On Fri, Dec 4, 2020, at 14:00, Jeff King wrote:
> On Fri, Dec 04, 2020 at 11:57:23AM -0800, Junio C Hamano wrote:
>
> > > * Refactor away from usage of FETCH_HEAD
> >
> > Yes, "fetch --all" is about updating the remote-tracking branches
> > and in retrospect, perhaps we might have avoided confusion if we
> > made it not to touch FETCH_HEAD, but it is not going to change now.
>
> I think its behavior of appending all of the entries is sensible (or at
> least is the least-surprising thing). The only weird part is that it
> does not keep the "make sure heads for merging come before not-for-merge
> entries" property that individual ones have.
>
> It could take a final pass after all of the sub-fetches have run and do
> that. I don't have any plans to work on it, but I'm tempted to call it a
> #leftoverbits candidate.
>
> > > * Set `remote.pushdefault = origin`
> > > * Set `push.default = current` (instead of `simple`, and is what
> > > my global config sets this to)
> >
> > I have a feeling that simple vs current does not make a difference
> > if you are pusing main to main, and if so, push.default could be
> > left to the default settings of 'simple'. But the key to successful
> > use of the triangular workflow is to configure so that "fetch/pull"
> > goes to one place (i.e. your upstream) and "push" goes to another
> > (i.e. your publishing repository), and "remote.pushdefault" is a
> > good ingredient to do so.
>
> I think my advice is just out-of-date (by quite a lot). In the early
> days, I remember being bitten by (or at least confused by) simple and
> how its use of upstream could work with multiple remotes. But we long
> ago fixed that, with ed2b18292b (push: change `simple` to accommodate
> triangular workflows, 2013-06-19), and these days it is explicitly
> documented to work the same as "current" when pushing to another remote.
>
> > It is however more common to use 'origin' as the name of your
> > upstream repository (so that "git fetch" and "git pull" would grab
> > things from there by default) and set remote.pushdefault to the
> > remote you push into, though (iow, I found remote.pushdefault
> > pointing at 'origin' a bit unusual). Doing so may make your
> > triangular workflow work smoother.
>
> Yeah, I wasn't going to nitpick his remote names, but that's the same
> convention I use. :) If people have custom forks of a repository that I
> access, I usually just name the remote for them after their username
> (including my own).
>
> -Peff
>
