On Thu, Apr 12, 2012 at 3:29 PM, Neal Kreitzinger <nkreitzinger@xxxxxxxxx> wrote: > On 4/11/2012 4:35 PM, Jeff King wrote: >> >> On Tue, Apr 10, 2012 at 08:24:48PM -0500, Neal Kreitzinger wrote: >> >>> This is all theory to me, but the reality is looming over my head >>> since most of the components I should be tracking are binaries small >>> (large history?) and big (but am not yet because of "big-file" >>> concerns -- I don't want to have to refactor my vast git ecosystem >>> with filter branch later because I slammed binaries into the main >>> project or superproject without proper systems programming (I'm not >>> sure what the c/linux term is for 'systems programming', but in the >>> mainframe world it meant making sure everything was configured for >>> efficient performance)). >> >> So properly implemented, no, you would not have to ever filter-branch to >> >> tweak these settings. You might have to do a repack to see the gains >> (because you want to delete the old non-split representation you have in >> your pack and replace it with a split representation), but that is >> transparent to git's abstract data model. >> > I'm likely going to have to slam graphics files into the main repo in the > very near future. It sounds like once git.git is updated for big-file > optimization I can just upgrade to that git version and repack to get the > benefits. Any idea when that version of git will come out release number > wise and calendar wise? > > (Don't read this next part if you just ate or are eating or drinking. You > may throw-up from nausea or choke from laughing.) > (I am forced to deal with a mandated/micromanaged change control menu design > from the powers-that-be that is based on cvs workflow and to > wipe-your-nose-for-you. It can't even cope with branches much less > submodules so in that context there isn't time to implement the graphics > tracking as a submodule. This change control menu is designed to replace > cvs commands with equivalent-results git-command sequences. While there are > many git users who import from svn into git, do their work in git, and then > export back into svn to get work done, ironically I am probably the only git > user who has to import from git (powers-that-be mandated cvs-style menu > controlled git-repo) into git (separate normal git repo and commandline), do > the work in normal git, and then export it back into git (cvs-style menu > controlled git-repo).) It seems that this is not directly related to the big-file support issue. Maybe it is better to discuss it in a new thread ^-^ > > v/r, > neal -- 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