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

[RFC] What's the best UI for 'git submodule split'?

From
EKEric Kidd <eric.kidd@gmail.com>
Date
Feb 12, 2009, 21:50 UTC
Message-ID
<431341160902121350x45076c8cj26afab0b7a51cac5@mail.gmail.com>

The problem: At work, we're converting a large git repository to Subversion. This repository contains an optional "streaming/media" directory which we want to split into a submodule. Some constraints:

  1) We want 'git bisect' to work with the converted repository, so
the submodule should exist all throughout the repository's history,
and not just in the HEAD revision.
  2) The submodule has moved around the tree in the past, and it has
occasionally disappeared for a commit or two. For example, it used to
live in "Media", not "streaming/media". We want to hook up these
different historical locations into a single submodule.

The proposed solution: I'm working on a 'git submodule split' script which works as follows:

  git submodule split streaming/media Media
  rm .git/refs/original # or just use --force below
  git submodule split other-binaries

This will create two submodules, one at streaming/media and one at other-binaries. It will rewrite the parent repository's history to create correct submodule links, and update .gitmodules as necessary at each point in the history. The new modules will be placed at their most recent locations in the tree.

Some Q&A:
Q. Why not merge 'submodule split' into the existing 'filter-branch' loop?

A. Internally, 'submodule split' needs to make two separate passes with 'filter-branch': One to create the new submodule, and one to update the parent. If I were to merge 'submodule split' into the existing filter-branch loop, filter-branch would need to keep track of two repositories. Writing 'submodule split' as a wrapper around filter-branch helps keep filter-branch simple.

Q. Why only process one submodule at time?

A. If there were multiple submodules, each with several different historical locations, the data structures in sh would get too tricky for me to implement well. But I'm happy to take patches and UI suggestions.

Q. Why operate on the current directory, and why output the new submodule in place?

A. An earlier version of 'submodule split' took the arguments 'src-repo dst-repo sub-repo sub-repo-dir...'. This required the user to do more typing, and it didn't feel very "git like". Johannes Schindelin suggested the current interface. The new interface feels more natural to me, and it's certainly easier to use in the common cases.

Q. What's the status of the code?

A. I'll have a very basic implementation of this interface shortly--I can already handle simple splits, but I want to add more test cases and add support for directories which move around the tree.

Thank you very much for your feedback! I appreciate the time that the reviewers spent helping to improve my filter-branch patch, and I'd like to make this patch as good as possible.

Cheers, Eric

Next: Eric Kidd
Message 1 of 13 in “[RFC] What's the best UI for 'git submodule split'?”
  1. Eric KiddFeb 12, 2009
  2. [RFC/PATCHv2] git submodule splitEric Kidd, Feb 14, 2009
  3. Junio C HamanoFeb 14, 2009
  4. Eric KiddFeb 14, 2009
  5. Lars HjemliFeb 14, 2009
  6. Johannes SchindelinFeb 14, 2009
  7. Nanako ShiraishiFeb 17, 2009
  8. Lars HjemliFeb 19, 2009
  9. Kyle MoffettFeb 19, 2009
  10. Johannes SchindelinFeb 14, 2009
  11. Eric KiddFeb 14, 2009
  12. Johannes SchindelinFeb 14, 2009
  13. Sverre RabbelierFeb 14, 2009

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.