Thread (34 messages) flat view 34 messages, 6 authors, 2016-06-15

Re: GSoC - Some questions on the idea of

From: Bo Chen <hidden>
Date: 2016-06-15 22:53:35

On Thu, Apr 12, 2012 at 3:29 PM, Neal Kreitzinger
[off-list ref] wrote:
On 4/11/2012 4:35 PM, Jeff King wrote:
quoted
On Tue, Apr 10, 2012 at 08:24:48PM -0500, Neal Kreitzinger wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help