Re: GSoC - Some questions on the idea of

[Bo Chen <chen@chenirvine.org>]

On Thu, Apr 12, 2012 at 3:29 PM, Neal Kreitzinger
<nkreitzinger@gmail.com> 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