From: "Konstantin Khomoutov" <[email protected]>
On Thu, 7 May 2015 13:45:29 -0700 (PDT)
Roger Mendes <[email protected]> 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.
--
Philip
--
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
to [email protected].
For more options, visit https://groups.google.com/d/optout.
