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
