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 <tconnors@rather.puzzling.org> 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 luv-main@luv.asn.au 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