Re: GSoC - Some questions on the idea of

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google