Re: [PATCH] contrib/subtree: Remove --annotate

greened@obbligato.org (David A. Greene) writes:

That heavily depends on your exit strategy.

The contrib/ area was created back when Git was still young and we felt that it would be beneficial for building the community if contributions to non-core part were also included, encouraging developers whose strength are not necessarily in the core part to participate in various design-level discussions to grow the community faster. Back then, we felt that an obscure standalone project outside Git that would help the Git-life of users have a much better chance of surviving (and eventually be polished) if we had them bundled, even if the code quality and stability were sub-par.

Those young days are long gone. A standalone tool that aims to help users' Git-life would not just survive but flourish with much more certainty, as long as the tool is good. We have enough Git users to rely on words-of-mouth these days to ensure their success.

That is why I am very hesitant to add new things to contrib/ these days. It is very welcome thought that you are working on improving subtree, and eventually moving it out of contrib/. From the point of view of the project, either moving up (to be part of the git core proper) or moving out (to become an independent project) is far more preferreable than the status quo so far that was staying in contrib/ (without seeing much changes and slowly but steadily bitrotting).

If the aspiration is to move up to exit, then the quality and stability expectation is basically the same as stuff in core, and we need to strive to keep it stable and high quality.

On the other hand, if it is exiting by moving out, then Git-core developers wouldn't have much say in how you would run your project.

There are obvious pros-and-cons from various points of view when choosing between moving up and moving out:

 * If the integration between "git subtree" and the rest of the
   system is loose (in other words, if your improved version of "git
   subtree" taken from Git 2.8 is dropped into an even newer version
   of Git 2.13, or an older version like Git 2.4 for that matter, is
   it expected to work, given the promise of interface stability git
   core gives you?), there is not much technical reason why it must
   stay in core.  Of course, your improvements may need to take
   advantage of improvements on the core side and your new "git
   subtree" may start to require at least Git 2.8, or you may even
   send patches to the core side to extend and enhance the services
   you use from the core side, but as long as that happens only
   occasionally and the dependency does not require lock-step
   upgrade, we can still call such an integration "loose" and moving
   out will still be a viable possibility.

 * If there are many existing users who expect their Git to come
   with "git subtree", unbundling may inconvenience them unless we
   work closely with Distros, from which most of these users get
   their Git.

 * If you expect the pace of improvement would be far faster than
   the release schedule of git core (usually a cycle lasts for 8 to
   12 weeks), moving out would give users a shorter turnaround for
   getting new and improved "git subtree".

 * It may even turn out that the users are a lot more tolerant for
   instability (e.g. removal of rarely used features) in "git
   subtree" than they require the git core proper to be stable, in
   which case moving up (rather than moving out) to apply the same
   stability requirement to "git subtree" as the rest of the system
   would be undesirable.

 * Moving up and staying in has a big social implication. It gives
   the version that comes with git core an appearance of being
   authoritative, even when other people fork the project.

   - This discourages incompatible forks (e.g. when one such fork
     finds the need to improve the "metadata" left by merge
     operation and used by split, the resulting repository managed
     by it may no longer usable by other variants of "git subtree",
     and if there is one in-tree "authoritative" one that is
     maintained, such a fork will not get wide adoption without
     taking compatibility issues into account).

   - On the other hand, if the "authoritative" one moves too slowly,
     that may hinder progress.  An exit by "moving out" to become
     one of the projects that help people's Git-life would result in
     two or more honestly competing forks of "git subtree", which
     might give users a better end-result after a few years, even
     though the users who happened to have picked the losing side
     during these few years may end up having to rewrite the
     history.