On 01/06/2021 13:12, Felipe Contreras wrote: > So it's more like: > > centralized = ~decentralized > triangular = ~two-way > > A centralized workflow consists of a single repository where branches > are typically two-way, but not necessarily. > > A decentralized workflow consists of multiple repositories where > branches are typically triangular, but not necessarily. > > So the triangularity is per branch, not per repository, and same_repo > means a two-way branch, could be a centralized or decentralized > workflow. My personal viewpoint is that triangular flow happens when you cannot push to the repo you consider as upstream. Rather you typically have a publish/backup repo instead (semi-public, semi-private - few are interested ;-). That (can't push one way around the triangle) part of the flow is separate from the distinction between patch flows and merge (Pull) request flows. E.g. My personal Git repo can be triangular with both git.git and git-for-windows, plus a few (what I view as) fetch-only repos from other collaborators/maintainers beyond the triangular 'golden' upstream repo. I often consider GitHub as a centraliser, but I don't think it's what is being considered above. -- A thought did come to mind that a Git serve/repo (typically bare) should be able to offer a 'refs/users/*' space (c.f. refs/remotes used by individual users) that allows a type of 'centralised' operation (almost as if all the users used a common alternates repo). Users could only push to their own /user refs, but could pull from the main refs/heads, and their own refs/users/ space. This would give flexibility to smaller corporate central operations to offer 'triangular flow' where each dev would feel like they have their own 'push' repo, when in reality it's really personalised branches. As usual the authentication of user names being handed off elsewhere;-). It could avoid some of the --alternate management aspects. It's a thought.. -- Philip
