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

[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 [off-list ref] 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.

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.

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