Re: git-subtree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> David Greene <dag@xxxxxxxx> writes:
>
>> How does the git community want the patch presented?  Right now it's one
>> monolithic thing.  I understand that isn't ideal but I don't think
>> incorporating the entire GitHub master history is necessarily the best
>> idea either.
>
> It depends on the longer term vision of how the result of this submission
> will evolve and more importantly, where you fit in the piture.

This is a very fair question.  I'll try to answer it as best I can.  I
think it mostly jibes with your suggested possible answer.

I've been using git-subtree for about six months now and as an
enthusiastic user who wants to introduce this too into my daily
corporate work environment, I'd like to see it incorporated as an
officially-supported git tool to make that introduction easier.

So my intention is to make git-subtree an integral part of the core git
suite and take on further maintenance and development along with Avery
and the other git-subtree developers.

I have not previously been a contributor to git-subtree and don't know
the code at all but I am a quick learner.  The actual git-subtree code
itself is not overwhelmingly large and strikes me as a tractable
learning project.

I approached Avery about submitting git-subtree to become part of the
core git suite.  He responded positively but indicated he does not have
the cycles to do it at this time.  He asked whether I could take on the
job and I agreed.

He mentioned that he'd talked to some developers at GitTogether and got
a positive reponse there.  I don't know whether you were part of those
discussions.  My impression is that the GitTogether discussions went
well and there was general agreement that git-subtree would be a
valuable addition to the core git suite.

I am perfectly happy to put this in contrib/ first if it eases the
introduction.  I would like to move it to the subcommand area after
getting everything in tip-top shape.  What I don't want is for it to
languish forever in contrib/.  That means I'll need some guideline of
the changes/standards necessary to qualify it for transition from
contrib/ to an official subcommand.  I expect we'll develop that as we
go along but I hope the git community has some institutional knowledge
gathered from previous experience.

I have asked Avery how he wants to do maintenance going forward.  I
haven't heard back from him yet so I can't speak to whether the existing
GitHub project will continue or not.  I'll pass along his thoughts when
I get them.

> Your answer might differ, of course, but the point is that we would need
> to weigh pros and cons between inclusion of it in the git repository and
> keeping it in Avery's repository and have him and his contributors
> maintain, enhance and distribute it from there, and it largely depends on
> the nature of the submission. Is it a "throw it over the wall" dump of a
> large code of unknown quality that we need to clean up first without
> knowing the vision of how "git subtree" should evolve by original author
> and/or people who have been actively developing it?

I certainly don't want this to be an "over the wall" operation.  I
intend to participate in maintenance of git-subtree in the official git
repository.

So I'll go ahead and work on adding this to contrib/.  Once I get a
response from Avery about his long-term vision I'll pass that along and
we can have further discussion.  I may start sending patches to the
mailing list for review before hearing back from him, however.

Sound good?

                             -Dave
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]