git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 30, 2008, 19:24 UTC
Message-ID
<7vljw5evj5.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<bd6139dc0810291606o2efe4254me378335b76861340@mail.gmail.com>

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?

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.

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.

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.

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).

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.

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?

Previous: Sverre RabbelierNext: Sverre Rabbelier
Message 7 of 11 in “Pull request for sub-tree merge into /contrib/gitstats”
  1. Sverre RabbelierOct 29, 2008
  2. Shawn O. PearceOct 29, 2008
  3. Sverre RabbelierOct 29, 2008
  4. Nicolas PitreOct 29, 2008
  5. Sverre RabbelierOct 29, 2008
  6. Sverre RabbelierOct 30, 2008
  7. Junio C HamanoOct 30, 2008
  8. Sverre RabbelierNov 2, 2008
  9. Johannes SchindelinNov 3, 2008
  10. David SymondsNov 3, 2008
  11. Sverre RabbelierNov 3, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.