Junio C Hamano <gitster@xxxxxxxxx> writes:
> greened@xxxxxxxxxxxxx (David A. Greene) writes:
>
>> Just to clarify, what is the expectation of things in contrib?
>> Basically the same as other code?
>
> That heavily depends on your exit strategy.
>
> 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.
This is the strategy I was planning to pursue. After extensive
experience with git-subtree and some local enhancements I have in
real-world work, I am convinced it is a great complementary tool to
git-submodule. It seems odd to me to have one in core and one not.
> * 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.
The enhancements to git-subtree that I have and/or am planning to
implement will probably require some changes to core, mostly bugfixes.
Some of the rebase tests I've sent are heading in that direction. They
are problems I discovered while trying to enhance subtree.
> * 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".
I don't think this is a concern.
> * 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.
That's a fair point. Besides than removing this --annotate option, I
anticipate two other potentially breaking changes:
1. Reorganizing metadata to be more useful - The metadata tags are
somewhat misleading at the moment and there is additional metadata
I've thought about adding.
2. Changing the split algorithm to reuse more of git core -
Specifically, I would like to leverage filter-branch to eliminate a
bunch of custom code in the split algorithm. In fact doing so would
fix a couple of bugs that have come in. My intent for this change is
to not alter the resulting history from what split does now (except
fixing the known bugs) but I can't absolutely guarantee that will be
the case until I implement it and try it out.
> * 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).
Other than the metadata rework mentioned above, I personally don't
anticipate a lot of change to it. Some ideas have come in from
elsewhere but I'm not yet convinced they're necessary. My guess is that
any future metadata changes will be more for convenience than any core
fnctionality. Thus, they could be added in a backward-compatible way.
> - 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.
That's an important point, especially given the time constraints I have.
Despite all my efforts, work is still taking the majority of my coding
time. That may improve given some other life schedule changes but we
will see. I think I can also justify taking some work time to implement
things, since the enhancements are all driven by work needs.
Overall, I think moving subtree to core is the best plan, given
submodule's status and the fact that both tools address similar tasks
but do them in fundamentally different ways, leading to useful
trade-offs for users. One of the things I plan to do is add a section
to subtree's documentation that discusses submodule, subtree and
reasonable scenarios when one may be a better fit than the other.
-David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html