I have a series of commits that I'd want to push to my remote repository, but I'm using an internet connection that's data capped and I'd like to know how big the commit is to decide whether to push it now or later when I'm on a connection with a larger data cap.
You can see how big a push is when you're in the middle of it, but is there a way to figure out how big it is before actually pushing?
It's kind of possible. Via bash, and assuming origin/master is your target branch:
$ echo $(git merge-base HEAD origin/master)..HEAD | git pack-objects --revs --thin --stdout --all-progress-implied > packfile
Inspecting the size of the resulting packfile will give you an idea of how much data you need to send to make the remote up-to-date.
I took this approach from an older answer, when I was tooling around trying to figure out my upload pack size. It's a bit of a hack, as you need to generate a packfile -- in theory, once you know the range of commits that have changed locally and remotely, you can just ask git for the names of those objects (a recursive problem, as objects may refer to other objects) and tally the sizes of those objects.
(Then again, generating the pack file also packs those objects -- just like git push would do -- so the size is more representative of what would be sent.)
If you have other developers working on the branch you wish to push to, then any estimate is moot, as you will likely have to run git fetch before pushing to the remote, which means transferring an unknown amount of data!
