{"thread":{"id":"25391","subject":"Alternate .gitignore","startedAt":"2010-10-08T12:31:32Z","lastAt":"2010-10-08T21:45:58Z","messageCount":4,"participants":["Maaartin","Ævar Arnfjörð Bjarmason","Kevin Ballard"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"152972","messageId":"loom.20101008T141929-221@post.gmane.org","threadId":"25391","inReplyTo":null,"subject":"Alternate .gitignore","fromName":"Maaartin","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-10-08T12:31:32Z","receivedAt":"2010-10-08T12:31:32Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"I'm using git for a project, where I'd like to store not only the sources but \nsome quite large generated files, too. However, I'd like to keep them separated, \nso my source depository doesn't grow too much. The problem could be solved \nnicely if there was a possibility to use .gitignore for the source tree and let \nsay .gitignore2 for the extended tree. I'd use two depositories: .git and .git2.\n\nThe content if .gitignore2 could be a subset of the content of .gitignore, so \nthe extended tree would contain the sources as well, which is not really a \nproblem. Or maybe I could make the depositories disjoint, I'm not sure now.\n\nIs something like this possible or is it too strange requirement?\n"},{"id":"152973","messageId":"AANLkTimG188_8qg-DTtJtvX-wkpotgp7+f8Bu4b4ayMn@mail.gmail.com","threadId":"25391","inReplyTo":"loom.20101008T141929-221@post.gmane.org","subject":"Re: Alternate .gitignore","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-10-08T12:45:55Z","receivedAt":"2010-10-08T12:45:55Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Oct 8, 2010 at 12:31, Maaartin <grajcar1@seznam.cz> wrote:\n> I'm using git for a project, where I'd like to store not only the sources but\n> some quite large generated files, too. However, I'd like to keep them separated,\n> so my source depository doesn't grow too much. The problem could be solved\n> nicely if there was a possibility to use .gitignore for the source tree and let\n> say .gitignore2 for the extended tree. I'd use two depositories: .git and .git2.\n>\n> The content if .gitignore2 could be a subset of the content of .gitignore, so\n> the extended tree would contain the sources as well, which is not really a\n> problem. Or maybe I could make the depositories disjoint, I'm not sure now.\n>\n> Is something like this possible or is it too strange requirement?\n\nHave you looked into storing your binaries in a git-submodule(1) ?\n"},{"id":"153015","messageId":"loom.20101008T225637-152@post.gmane.org","threadId":"25391","inReplyTo":"AANLkTimG188_8qg-DTtJtvX-wkpotgp7+f8Bu4b4ayMn@mail.gmail.com","subject":"Re: Alternate .gitignore","fromName":"Maaartin","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-10-08T21:39:01Z","receivedAt":"2010-10-08T21:39:01Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"Ævar Arnfjörð Bjarmason <avarab <at> gmail.com> writes:\n\n> Have you looked into storing your binaries in a git-submodule(1) ?\n\nI've look at it just now and it doesn't seem to be the thing I need. According \nto my very basis understanding submodules seem to be useful for embedding other \nprojects, but I'm working with a single project only. I'm speaking about a \nsingle project and need to store it in different repositories at different \n\"ignorance levels\".\n\nTo make it clear, just imagine that compilation would be many thousand times \nslower. In such a case you could prefer to store the history of the *.o files as \nwell, but you'd still want to avoid the pollution of the source tree. So you'd \nmaybe use .git for the sources as usually and .git2 (or whatever) for the object \nfiles (maybe together with the sources). This comes very close to my situation.\n\nI could switch to using .git2 using $GIT_DIR, but with \"*.o\" in my .gitignore I \nsee no way how to include the ignored files. Maybe I could use $GIT_DIR/info/\nexclude somehow instead of .gitignore, but this could be quite cumbersome.\n"},{"id":"153016","messageId":"6FF71159-7AB3-46D2-A417-77ED61458D4A@sb.org","threadId":"25391","inReplyTo":"loom.20101008T225637-152@post.gmane.org","subject":"Re: Alternate .gitignore","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-10-08T21:45:58Z","receivedAt":"2010-10-08T21:45:58Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Oct 8, 2010, at 2:39 PM, Maaartin wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab <at> gmail.com> writes:\n> \n>> Have you looked into storing your binaries in a git-submodule(1) ?\n> \n> I've look at it just now and it doesn't seem to be the thing I need. According \n> to my very basis understanding submodules seem to be useful for embedding other \n> projects, but I'm working with a single project only. I'm speaking about a \n> single project and need to store it in different repositories at different \n> \"ignorance levels\".\n> \n> To make it clear, just imagine that compilation would be many thousand times \n> slower. In such a case you could prefer to store the history of the *.o files as \n> well, but you'd still want to avoid the pollution of the source tree. So you'd \n> maybe use .git for the sources as usually and .git2 (or whatever) for the object \n> files (maybe together with the sources). This comes very close to my situation.\n> \n> I could switch to using .git2 using $GIT_DIR, but with \"*.o\" in my .gitignore I \n> see no way how to include the ignored files. Maybe I could use $GIT_DIR/info/\n> exclude somehow instead of .gitignore, but this could be quite cumbersome.\n\nSubmodules are usually used to embed other projects, but they can also be used for this \"ignorance levels\" thing you want. Make the core repo have what everyone wants, and each \"ignorance level\" should go into another submodule. Lots of binary files that only some people need? Make it a submodule. People can then init the submodules they care about and update just those ones and ignore the others. You'll probably want to have some sort of documentation telling people what the different submodules are, so they don't just blindly `git submodule update --init --recursive`, but with just a little bit of effort it can work pretty well.\n\n-Kevin Ballard"}]}