Try this? git add -i u 1-$max a 1-$max q git commit -m ...
(where $max is the maximum number printed in the list it just gave you prior) On 13 December 2013 18:26, Tim Connors <[email protected]> wrote: > git beginner here, so forgive me. > > As part of change management of a couple hundred servers, we do a regular > 'git add .' on a central repository of half a million files, followed by a > bit of munging, then a 'git commit -a -m ...' (rhel5, so 'git -a' is 'git > -A' elsewhere). > > 'git add .' is very very slow at finding the additions and modifications > (we don't care about the '-u' deletions at this stage, because of the > future munging required) and staging them. I suspect it's actually > staging every single file rather than just changes. > > 'git status -s' on a freshly changed repository prior to doing any git add > is really quite quick (no, it's not a cold or undersized cache issue), and > finds all additions, deletions and modifications. We could simply pipe > that rather small output to 'git add' and it would be much much quicker at > staging them (er, I think; but also, a bit of a kludge). Any known reason > why git-add would appear to be recursing through the entire tree staging > even unchanged files, and not just acting on the changed files that > git-status obviously can find very quickly? Any missing bit of git magic > I could be applying? > > -- > Tim Connors > _______________________________________________ > luv-main mailing list > [email protected] > http://lists.luv.asn.au/listinfo/luv-main -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
