[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@xxxxxxxxx> 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 -- 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
