On 02/07/2019 20:24, Theodore Ts'o wrote:
I think the real problem with all of this feature request is that it's
all presuming a particular workflow, and git is currently*not*
strongly opinionated about the workflow.
I'd suggest that git does have a clear preference for a workflow that is
based on the "upstream" view. (e.g. see 'rebase')
While Git tries to avoid being opinionated, it does develop a bias of
avoiding various common workflows, to the point that they are not even
well named.
In particular, we have a number of variants of the triangular workflow,
such as having a personal github fork, and a then also a maintainer's
repo to complete the triangle [which is even worse for those supporting
Git-for-Windows because of two level maintenance cascade, with different
compilation and OS requirements..]. Having three 'origins' is no fun.
There was an attempt to document a triangular flow a while back, but it
wasn't actually that one. e.g. [1])
The other preference aspect is the tendency to expect users to 'support
the machine' (e.g. the assume-unchanged file flag, which is commonly
misunderstood), rather than having a clarity about when Git will support
the user. Here we (they) are looking for the human readable name of the
branch that they forked from (and is likely to have been extended
since), rather than the oid hash of the fork point, though that is
clearly useful and should be recorded with the branch name as it is
immutable.
I am cautious about support for Gerrit on the basis that it could
accidentally reinforce a centralised workflow (to the detriment of
distributed operation), which should be avoided strongly as a deliberate
bias.
However the desire to _locally_ record the branch name that the current
branch was created from is something I would support (which is why I
suggested the unused branch description...).
Philip
[1]
https://public-inbox.org/git/5A8F8EE0162B49818813DAEFD68F61DA@PhilipOakley/
(sorry for any delays, I'm still in catch-up mode)
