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

Re: git subtree as a solution to partial cloning?

From
AAAsger Ottar Alstrup <asger@area9.dk>
Date
May 25, 2009, 17:35 UTC
Message-ID
<8873ae500905251035v64084e83wa1a89a562d20224a@mail.gmail.com>
In-Reply-To
<32541b130905250850h75f905e0t84287f897600187f@mail.gmail.com>
On Mon, May 25, 2009 at 5:50 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
Show 8 quoted lines
> On Mon, May 25, 2009 at 5:33 AM, Asger Ottar Alstrup <asger@area9.dk> wrote:
>> No, that is unfortunately not so easy. If we could, I suppose we could
>> use submodules instead.
>
> Your only option may be to use git filter-branch then.  It lets you do
> pretty much anything you want, although merging it back together again
> could be entertaining.  (Making it correctly mergeable is by far the
> trickiest part of git-subtree.)

OK, so git subtree is not usable as it is for this. Instead, it seems a new system has to be developed which would be similar to git subtree in spirit, except that it worked at a file-level. Of course, the git merge subtree strategy can not be used, so merging has to be done differently.

So a poor mans system could work like this:
- A reduced repository is defined by a list of paths in a file, I
guess with a format similar to .gitignore
- To extract: A copy of the original repository is made. This copy is
reduced using git filter-branch. Is there some way of turning a
.gitignore syntax file into a concrete list of files? Also, can this
entire step be done in one step without the copy? Having to copy the
entire project first seems excessive. Will filter-branch preserve
and/or prune pack files intelligently?
- To merge from the reduced to the original: The very simple version
is just to copy all the files from the reduced repository into a
checkout of the original repository, and then merge. This would not
support removal (or renaming) of files, but that might be ok in my
setup. If this needs to be more intelligent, the list of files in the
reduced repository could be compared with the list of paths that was
used to reduce it originally. This can be used to detect removals and
additions of files.
- To merge from the original to the reduced: First merge the other
way, and then extract again.
I am new to git, so please excuse me if this design is mentally unsound.

Regards, Asger

Previous: Avery PennarunNext: Avery Pennarun
Message 4 of 8 in “Re: git subtree as a solution to partial cloning?”
  1. Avery PennarunMay 25, 2009
  2. Asger Ottar AlstrupMay 25, 2009
  3. Avery PennarunMay 25, 2009
  4. Asger Ottar AlstrupMay 25, 2009
  5. Avery PennarunMay 25, 2009
  6. Asger Ottar AlstrupMay 25, 2009
  7. Avery PennarunMay 25, 2009
  8. Jakub NarebskiMay 25, 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.