45 lines
2.1 KiB
Plaintext
45 lines
2.1 KiB
Plaintext
|
Contributed Software
|
||
|
|
|
||
|
|
Although these pieces are available as part of the official git
|
||
|
|
source tree, they are in somewhat different status. The
|
||
|
|
intention is to keep interesting tools around git here, maybe
|
||
|
|
even experimental ones, to give users an easier access to them,
|
||
|
|
and to give tools wider exposure, so that they can be improved
|
||
|
|
faster.
|
||
|
|
|
||
|
|
I am not expecting to touch these myself that much. As far as
|
||
|
|
my day-to-day operation is concerned, these subdirectories are
|
||
|
|
owned by their respective primary authors. I am willing to help
|
||
|
|
if users of these components and the contrib/ subtree "owners"
|
||
|
|
have technical/design issues to resolve, but the initiative to
|
||
|
|
fix and/or enhance things _must_ be on the side of the subtree
|
||
|
|
owners. IOW, I won't be actively looking for bugs and rooms for
|
||
|
|
enhancements in them as the git maintainer -- I may only do so
|
||
|
|
just as one of the users when I want to scratch my own itch. If
|
||
|
|
you have patches to things in contrib/ area, the patch should be
|
||
|
|
first sent to the primary author, and then the primary author
|
||
|
|
should ack and forward it to me (git pull request is nicer).
|
||
|
|
This is the same way as how I have been treating gitk, and to a
|
||
|
|
lesser degree various foreign SCM interfaces, so you know the
|
||
|
|
drill.
|
||
|
|
|
||
|
|
I expect that things that start their life in the contrib/ area
|
||
|
|
to graduate out of contrib/ once they mature, either by becoming
|
||
|
|
projects on their own, or moving to the toplevel directory. On
|
||
|
|
the other hand, I expect I'll be proposing removal of disused
|
||
|
|
and inactive ones from time to time.
|
||
|
|
|
||
|
|
If you have new things to add to this area, please first propose
|
||
|
|
it on the git mailing list, and after a list discussion proves
|
||
|
|
there are some general interests (it does not have to be a
|
||
|
|
list-wide consensus for a tool targeted to a relatively narrow
|
||
|
|
audience -- for example I do not work with projects whose
|
||
|
|
upstream is svn, so I have no use for git-svn myself, but it is
|
||
|
|
of general interest for people who need to interoperate with SVN
|
||
|
|
repositories in a way git-svn works better than git-svnimport),
|
||
|
|
submit a patch to create a subdirectory of contrib/ and put your
|
||
|
|
stuff there.
|
||
|
|
|
||
|
|
-jc
|
||
|
|
|