Re: GSoC - Some questions on the idea of

[Neal Kreitzinger <nkreitzinger@gmail.com>]

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

v/r,
neal