Re: Pull request for sub-tree merge into /contrib/gitstats

From: Sverre Rabbelier <alturin@gmail.com>
Date: Nov 2, 2008, 19:24 UTC
Message-ID: <bd6139dc0811021124q5ba22d6bm6655f735aaeb379b@mail.gmail.com>
In-Reply-To: <7vljw5evj5.fsf@gitster.siamese.dyndns.org>

[Sorry for the late reply, have been travelling, sleeping, and catching up with family in the past few days]

On Thu, Oct 30, 2008 at 20:24, Junio C Hamano <gitster@pobox.com> wrote:

> I have a mixed feeling about this.  From a longer-term perspective, do you
> really want this to be a part of git.git repository?

My main reason for wanting to have it in git.git is getting additional exposure, being in /contrib seems like a good way to do that.

> I do not mind having notes to endorse and advocate "stats" as one of the
> "Third party packages that may make your git life more pleasuable", just
> like tig, stgit, guilt and topgit, but I cannot convince myself that
> merging it as a subtree is the right thing to do at this point.

Heh, blame Johannes for that one; the main reason for not doing something like this earlier was my uncertaincy as to -what- to do. Dscho suggested to request-pull a subtree merge, which is what I did.

Show 7 quoted lines

> The "stats" tool, at least at the conceptual level, shares one important
> property with tools like gitk and gitweb: it could be useful to people
> whose sources are not in git repositories but in say Hg or Bzr, with some
> effort.  The code may need refactoring to make it easier to plug in
> different backends and writing actual backends (aka "porting"), but that
> is something you can expect people with different backends to help you
> with.

This is true, it uses a python wrapper around git, but with some work it could be make to use a more abstract wrapper instead, that allows the use of different backends.

> However, it would be awkward for the contrib/ area in git.git to carry a
> lot of code that are only needed to produce stat data from non-git
> repositories, once such a porting effort begins.

I reckon it would not be a lot of code, but I agree, that would be awkward.

Show 9 quoted lines

> It's perfectly fine if you are not interested in any of the other
> backends, and tell the people that they are welcome to fork it never to
> merge back.  But if this were my brainchild, I'd imagine I'd be wishing to
> be able to buy back the improvements to the "core stats" parts that are
> done by people with other backends.  I would imagine binding the current
> code as part of git.git would make such improvements harder to manage,
> both for you (who wants to buy back the changes made by others on
> different backends) and for others on different backends (who want to
> merge the changes made by you to their forks).

This is true, if there is indeed interest from other backends to use this kind of functionality, I would welcome the patches. In such a case being in git.git/contrib might not be a good thing.

> Perhaps pointing at your tree as a submodule would be the right thing to
> do; then git.git proper will be just one of the users of "stats" tool.

Would a subdir in git.git for such submodules be a good idea? That way we don't have to worry about a conflict between (for example) git-gui as a subdir, and git-gui as a submodule.

> How about making that as a mid-to-longer term goal?  When we eject git-gui
> and gitk from git.git and make them a submodule (wasn't that supposed to
> happen in 1.8 or 2.0 timeframe?), we may also add "stats" as a submodule?

I didn't know there was a timeframe for this, I thought your suggestion tree to eject-and-make-into-submodule was somewhat ignored; if there are indeed plans for this, I would be ok with having git-stats as a submodule instead.

-- 
Cheers,

Sverre Rabbelier