contrib/ area

5 messages, 3 authors, 2016-06-15 · open the first message on its own page

contrib/ area

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:19

As some of you may be aware, I've added contrib/ area to git.git
repository.  Currently there are git-svn from Eric and gitview
from Aneesh.

The intention is to keep interesting tools around git, 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 expecting not to touch them myself that much.  As far as my
day-to-day operation is concerned, contrib/git-svn is owned by
Eric and contrib/gitview by Aneesh.  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 treated gitk, 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.

By the way, I have to admit that merging these two were a bit
painful for me.  They came as text attachments to e-mail
messages, and I ended up hand committing with --author flag,
while fixing up whitespaces in them [*1*].  I do not want to do
that again.  So if you have new things to add to the contrib/
area, please first propose it on the 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), submit a patch to create a subdirectory of contrib/ and
put your stuff there.

One final request to Aneesh.  Could you send a patch to add a
bit of blurb and introductory text in contrib/gitview/README,
please?  As it stands, it would be hard to get as much exposure
as we had hoped by just having it in git.git repository.

[Footnote]

*1* I _am_ picky about whitespaces, and I would encourage people
to enable the pre-commit example hook.

Re: contrib/ area

From: Aneesh Kumar <hidden>
Date: 2016-06-15 22:42:19

On 2/17/06, Junio C Hamano [off-list ref] wrote:

One final request to Aneesh.  Could you send a patch to add a
bit of blurb and introductory text in contrib/gitview/README,
please?  As it stands, it would be hard to get as much exposure
as we had hoped by just having it in git.git repository.

Attaching below the same in the form of patch generated by git format-patch

-aneesh

Re: contrib/ area

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:19

Aneesh Kumar [off-list ref] writes:
Attaching below the same in the form of patch generated by git format-patch
I'll let it pass this time, but you forgot a sign-off and
perhaps forgot to read Documentation/SubmittingPatches ;-).

Re: contrib/ area

From: Aneesh Kumar <hidden>
Date: 2016-06-15 22:42:19

On 2/18/06, Junio C Hamano [off-list ref] wrote:
Aneesh Kumar [off-list ref] writes:
quoted
Attaching below the same in the form of patch generated by git format-patch
I'll let it pass this time, but you forgot a sign-off and
perhaps forgot to read Documentation/SubmittingPatches ;-).
How about sending the patches as attachment below. I am not sure how
to inline patches in gmail.

-aneesh

Re: contrib/ area

From: Ben Clifford <hidden>
Date: 2016-06-15 22:42:19

As some of you may be aware, I've added contrib/ area to git.git
repository.  Currently there are git-svn from Eric and gitview
from Aneesh.

The intention is to keep interesting tools around git, 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 have been keeping some (lazily-maintained) bash completion code at:

http://www.hawaga.org.uk/ben/tech/gitcompletion/

It isn't clear to me whether it should stay there or be merged into 
git/contrib/.

Cogito has the cogito bits of the above already included.

Stg doesn't.

The path of least resistence for me is to keep it at the above 
hawaga.org.uk URL, but it may be that some people would prefer it in the 
main repos.

Ben

-- 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help