From: "Konstantin Khomoutov" <>
On Thu, 7 May 2015 13:45:29 -0700 (PDT)
Roger Mendes <> wrote:

This seems like a fairly simple feature to add, I'm not sure why no
one has done this or thought of it given the number of complaints,
questions... with large file handling.

We can ignore by file name attribute, why not by file size?

Yes, I know I can add pre-commit scripts... to workaround this issue,
but there should be a better way (or maybe I'm missing something?).

I humbly think this proposition is ill-concieved in fact.
The problem you're trying to solve using technical tools is, in fact,
social / political: if people are unable/unwilling to properly review
what they commit, they have to be educated, and then possibly penalized
on repeated faults.

The same argument could just as easily be extended to all of .gitignore, so I don't see it as a valid argument.

I can understand why github has this setting in place: they provide
free hosting for hundreds of thousand throwaway repositories, and
obviously have to combat goofs like accidentially committing junk.
In "real" environments, like private / corporate repos, such goofs are
way easier to fix: you just tell the person to amend a commit and
force-push, or let a user with more rights do that, if required,
while explaining why things gone bad and how to avoid that in the
future.  IOW, it's possible to provide an educational hands-holding in
such a case.

Having seen the variability of users in a typical multi-function corporate environment (including my personal use of some tools!), the more that configurable safeties can be provided the better. Spikes on steering wheels don't make for a better driver ;-)

On the other hand, ignoring files by name is useful for everyone as the
most common application of a VCS is managing the source code of a
program, and so you want to ignore backup files made by text editor,
IDE- or toolchain-generated crap, binary files which are the result of
compiling the source code etc.

I certainly would like a size based limit available to prevent mistakes, and to support sparse checkouts, and even, perhaps in the future, Narrow clones.

The one big 'however' is what the magic coding should be?, given the possibility of confusion with real pathspecs (including existing .gitignore's, of which Github will list many!). Perhaps steal a magic pathspec which then defines a size - perhaps Roger could suggest something to get the discussion started.
You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to