Re: Unexpected behavior with branch.*.{remote,pushremote,merge}

[Jeff King <peff@peff.net>]

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