Re: [PATCH] add: add --bulk to index all objects into a pack file

[Duy Nguyen]

On Thu, Oct 3, 2013 at 1:43 PM, Junio C Hamano  wrote:
> Nguyễn Thái Ngọc Duy   writes:
>
>> The use case is
>>
>> tar -xzf bigproject.tar.gz
>> cd bigproject
>> git init
>> git add .
>> # git grep or something
>
> Two obvious thoughts, and a half.
>
>  (1) This particular invocation of "git add" can easily detect that
>  it is run in a repository with no $GIT_INDEX_FILE yet, which is
>  the most typical case for a big initial import.  It could even
>  ask if the current branch is unborn if you wanted to make the
>  heuristic more specific to this use case.  Perhaps it would
>  make sense to automatically plug the bulk import machinery in
>  such a case without an option?

Yeah! I did not even think of that.

>  (2) Imagine performing a dry-run of update_files_in_cache() using a
>  different diff-files callback that is similar to the
>  update_callback() but that uses the lstat(2) data to see how
>  big an import this really is, instead of calling
>  add_file_to_index(), before actually registering the data to
>  the object database.  If you benchmark to see how expensive it
>  is, you may find that such a scheme might be a workable
>  auto-tuning mechanism to trigger this.  Even if it were
>  moderately expensive, when combined with the heuristics above
>  for (1), it might be a worthwhile thing to do only when it is
>  likely to be an initial import.

We do a lot of lstats nowadays for refreshing index so yeah it's
likely reasonably cheap, but I doubt people do mass update on existing
files often. Adding a large amount of new files (even when .git/index
exists) may be a better indication of an import and we already have
that information from fill_directory().

For the no .git/index case, packing with bulk-checkin probably
produces a reasonably good pack because they don't delta well anyway.
There are no previous versions to delta against. They can delta
against other files but I don't think we'll have good compression with
that. For the case where .git/index exists, we may intefere with "git
gc --auto". We create a less optimal pack, but it's a pack and may
delay gc time longer..

>  (3) Is it always a good idea to send everything to a packfile on a
>  large addition, or are you often better off importing the
>  initial fileset as loose objects?  If the latter, then the
>  option name "--bulk" may give users a wrong hint "if you are
>  doing a bulk-import, you are bettern off using this option".

Hard question. Fewer files are definitely a good thing, for example
when you "rm -rf" the whole thing :-) Disk usage is another. On
gdb-7.3.1, "du -sh" reports .git with loose objects takes 57M, while
the packed one takes 29M. Disk access is slightly faster on packed
.git, at least for "git grep --cached": 0.71s vs 0.83s.

> This is a very logical extension to what was started at 568508e7
> (bulk-checkin: replace fast-import based implementation,
> 2011-10-28), and I like it.  I suspect "--bulk=" might
> be a better alternative than setting the threshold unconditionally
> to zero, though.

The threshold may be better in form of a config setting because I
won't want to specify that every time. But does one really want to
keep some small files around in loose format? I don't see it because
my goal is to keep a clean .git, but maybe loose format has some
advantages..
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Using filter-branch without messing up the working copy

[Dale R. Worley]

I'm working on using "git filter-branch" to remove the history of a
large file from my repository so as to reduce the size of the
repository.  This pattern of use is effective for me:

1. $ git filter-branch --index-filter 'git rm --cached --ignore-unmatch 
core.4563' HEAD

2. edit .git/packed-refs to remove the line
   "c6589bef2c776277407686a3a81c5a76bfe41ba2 refs/original/refs/heads/hobgoblin"
(so that there is no reference to the old HEAD)

3. git gc --quiet --aggressive

The difficulty I am having is that I do not want to disturb the
working copy while doing this.  The working copy is my entire home
directory, because I am using the repository as a historical backup
system for my home directory.  Currently, Git will not execute
filter-branch if there are unstaged changes in the working copy,
despite the fact that "git filter-branch --index-filter" does not
touch the working copy itself.  (In this case, the file to be deleted,
"core.4563", is not now in the working copy.)

A further difficulty is that the repository is "remote", the .git
directory is not in my home directory, and core.worktree is
"/home/worley".

The best set of steps I have found that accomplishes my goals is to
(1) "disconnect" the repository from the working copy by removing the
core.worktree value, (2) use "git checkout -q -f master" to create in
the repository's location an entire copy of my home directory, (3)
perform the above filtering steps, (4) "reconnect" the repository by
adding the core.worktree value, and (5) deleting the temporary working
copy files.

Surely there is a better way than this.

Dale
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

[Antoine Pelisse]

I've not followed the thread so much but, in that
entry.c::checkout_entry,() we do:

memcpy(path, state->base_dir, len);
strcpy(path + len, ce->name);

which can of course result in memory violation if PATH is not long enough.

On Thu, Oct 3, 2013 at 12:26 AM, Wataru Noguchi  wrote:
> Hi,
>
> At last, I foundfollowing Makefile optimization suppression works fine in my
> case.
>
> CFLAGS = -g -O2 -fno-inline-small-functions -Wall
>
> Following optimization option cause crash,
>
> -finline-small-functions
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

[Erik Faye-Lund]

On Thu, Oct 3, 2013 at 7:25 PM, Antoine Pelisse  wrote:
> I've not followed the thread so much but, in that
> entry.c::checkout_entry,() we do:
>
> memcpy(path, state->base_dir, len);
> strcpy(path + len, ce->name);
>
> which can of course result in memory violation if PATH is not long enough.
>

...aaand you're spot on. The following patch illustrates it:

$ /git/git-clone.exe mingw-checkout-crash.git
Cloning into 'mingw-checkout-crash'...
done.
fatal: argh, this won't work!
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

---

diff --git a/entry.c b/entry.c
index acc892f..505638e 100644
--- a/entry.c
+++ b/entry.c
@@ -244,6 +244,9 @@ int checkout_entry(struct cache_entry *ce,
  if (topath)
  return write_entry(ce, topath, state, 1);

+ if (len > PATH_MAX || len + strlen(ce->name) > PATH_MAX)
+ die("argh, this won't work!");
+
  memcpy(path, state->base_dir, len);
  strcpy(path + len, ce->name);
  len += ce_namelen(ce);


> On Thu, Oct 3, 2013 at 12:26 AM, Wataru Noguchi  
> wrote:
>> Hi,
>>
>> At last, I foundfollowing Makefile optimization suppression works fine in my
>> case.
>>
>> CFLAGS = -g -O2 -fno-inline-small-functions -Wall
>>
>> Following optimization option cause crash,
>>
>> -finline-small-functions
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dead links, broken search box, confusing/inconvenient contact

[Stefan Pochmann]

1) The links to Matthew's lists on the bottom of
http://git-scm.com/downloads/guis are dead (I get 404s).

2) Wondering whether TortoiseGit is mentioned anywhere, I typed
tortoisegit into the top right search box, hit enter and got to
http://git-scm.com/search/results?search=tor (note the ending - I did
type the whole word but it got cut off!). I'm not *that* fast at
typing, but apparently I'm still way too fast for the search box, as
it does work when I wait a second or two before I hit enter.

3) Trying to contact you I first looked at the bottom of the page, the
link to https://github.com/github/gitscm-next was the only that made
some sense, and there I don't see contact information, even though
that README does say " contact me first" at some point (and who is
that "me"?).

4) When I found this email address and sent a mail with items 1)-3), I
got a rejection reply saying " The message contains HTML subpart".
Very annoying. I'm trying to help here by pointing out problems, and
you're making it really inconvenient.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dead links, broken search box, confusing/inconvenient contact

[Stefan Beller]

Hi Stefan,

On 10/03/2013 07:50 PM, Stefan Pochmann wrote:
> 1) The links to Matthew's lists on the bottom of
> http://git-scm.com/downloads/guis are dead (I get 404s).
> 

git-scm is an open sourced site and hosted on GitHub.
It is providing some information for git, but also on github.
(It was started by the github founder iirc)
Improvements by your own or just filling an issue, would be best at
https://github.com/github/gitscm-next



> 2) Wondering whether TortoiseGit is mentioned anywhere, I typed
> tortoisegit into the top right search box, hit enter and got to
> http://git-scm.com/search/results?search=tor (note the ending - I did
> type the whole word but it got cut off!). I'm not *that* fast at
> typing, but apparently I'm still way too fast for the search box, as
> it does work when I wait a second or two before I hit enter.

Same thing, it's git-scm related, please get in touch there.

> 
> 3) Trying to contact you I first looked at the bottom of the page, the
> link to https://github.com/github/gitscm-next was the only that made
> some sense, and there I don't see contact information, even though
> that README does say " contact me first" at some point (and who is
> that "me"?).

I'd assume the "me" is https://github.com/schacon the founder of github.
The README may be outdated there.
This is the mailing list for the git project, which is run by different
people than the github company.

> 
> 4) When I found this email address and sent a mail with items 1)-3), I
> got a rejection reply saying " The message contains HTML subpart".
> Very annoying. I'm trying to help here by pointing out problems, and
> you're making it really inconvenient.

On this mailing list html is not appreciated as you wouldn't gain much
from it with respect to the development or discussion of git, only
larger emails.

Thanks for writing to the list, but it may be not the best place for
reporting git-scm.com issues.

Thanks,
Stefan



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] git svn: Set default --prefix='origin/' if --prefix is not given

[Eric Wong]

Johan Herland  wrote:
> On Tue, Oct 1, 2013 at 6:07 AM, Eric Wong  wrote:
> > How about we put a big warning of impending change in there for now and
> > wait until git 1.9/2.0 to make the actual change?
> 
> Sounds sensible. What should the warning look like, and where should
> it be placed? I'm thinking that if you run git svn init/clone without
> --prefix, there should be a verbose warning explaining (a) the trouble
> you're likely to encounter when using no prefix, and (b) the upcoming
> change in default prefix. Obviuosly, there should be a corresponding
> note in the git-svn manual page. Any other places in git.git that
> warrants changing? Hopefully this should be sufficient to trigger
> corresponding adjustments in third-party tools + docs ahead of the
> actual change in 1.9/2.0.

Probably, yes.  I don't remember off the top of my head if there's
other places, but init/clone should be a good enough start.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation/Makefile: make AsciiDoc dblatex dir configurable

[John Keeping]

On my system this is in /usr/share/asciidoc/dblatex not
/etc/asciidoc/dblatex.  Extract this portion of the path to a variable
so that is can be set in config.mak.

Signed-off-by: John Keeping 
---
 Documentation/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 0cfdc36..4f13a23 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -103,6 +103,7 @@ MAKEINFO = makeinfo
 INSTALL_INFO = install-info
 DOCBOOK2X_TEXI = docbook2x-texi
 DBLATEX = dblatex
+ASCIIDOC_DBLATEX_DIR = /etc/asciidoc/dblatex
 ifndef PERL_PATH
PERL_PATH = /usr/bin/perl
 endif
@@ -354,7 +355,7 @@ user-manual.texi: user-manual.xml
 
 user-manual.pdf: user-manual.xml
$(QUIET_DBLATEX)$(RM) $@+ $@ && \
-   $(DBLATEX) -o $@+ -p /etc/asciidoc/dblatex/asciidoc-dblatex.xsl -s 
/etc/asciidoc/dblatex/asciidoc-dblatex.sty $< && \
+   $(DBLATEX) -o $@+ -p $(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.xsl -s 
$(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.sty $< && \
mv $@+ $@
 
 gitman.texi: $(MAN_XML) cat-texi.perl
-- 
1.8.4.566.g73d370b

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/Makefile: make AsciiDoc dblatex dir configurable

[Jonathan Nieder]

John Keeping wrote:

> On my system this is in /usr/share/asciidoc/dblatex not
> /etc/asciidoc/dblatex.  Extract this portion of the path to a variable
> so that is can be set in config.mak.
>
> Signed-off-by: John Keeping 

Thanks.  Looks good.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

book version

[DynV]

Hello,

I haven't subscribed to the mail-list as the beginning of Community 
 hint it's not necessary ; please inform 
me if I need to be in order to get a reply.


I have an old PDF version of Pro Git. In the file, there doesn't seem to 
be a version. Both the local (downloaded) and the on-line file names are 
the same. I'd rather not download the same thing twice. I would have 
hoped there would have been either a version or a check-sum so I'd be 
sure I have the most up-to-date book.


The following are the check-sums of my local book
md5 301c91ac7084bea424e753dec694d9ca
sha1139d593611ed366700abfb291bd90e262e40afe3


Thanks


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: book version

[Fredrik Gustafsson]

On Thu, Oct 03, 2013 at 04:08:57PM -0400, DynV wrote:
> Hello,
> 
> I haven't subscribed to the mail-list as the beginning of Community
>  hint it's not necessary ; please
> inform me if I need to be in order to get a reply.
> 
> I have an old PDF version of Pro Git. In the file, there doesn't
> seem to be a version. Both the local (downloaded) and the on-line
> file names are the same. I'd rather not download the same thing
> twice. I would have hoped there would have been either a version or
> a check-sum so I'd be sure I have the most up-to-date book.
> 
> The following are the check-sums of my local book
> md5   301c91ac7084bea424e753dec694d9ca
> sha1  139d593611ed366700abfb291bd90e262e40afe3
> 
> 
> Thanks
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I looks like you've the latest version. Details:

iveqy@kolya:~$ wget https://github.s3.amazonaws.com/media/progit.en.pdf
--2013-10-03 22:11:58--
https://github.s3.amazonaws.com/media/progit.en.pdf
Slår upp github.s3.amazonaws.com (github.s3.amazonaws.com)...
205.251.242.248
Ansluter till github.s3.amazonaws.com
(github.s3.amazonaws.com)|205.251.242.248|:443... ansluten.
HTTP-begäran skickad, väntar på svar... 200 OK
Längd: 5630471 (5,4M) [application/pdf]
Sparar till: "progit.en.pdf"

100%[==>]
5 630 471144K/s   på 44s 

2013-10-03 22:12:48 (124 KB/s) - "progit.en.pdf" sparades
[5630471/5630471]

iveqy@kolya:~$ md5sum progit.en.pdf 
301c91ac7084bea424e753dec694d9ca  progit.en.pdf
iveqy@kolya:~$ sha1sum progit.en.pdf 
139d593611ed366700abfb291bd90e262e40afe3  progit.en.pdf
iveqy@kolya:~$ 


-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iv...@iveqy.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] push: Enhance unspecified push default warning

[Greg Jacobson]

When the unset push.default warning message is displayed
this may be the first time many users encounter push.default.
Modified the warning message to explain in a compact
manner what push.default is and why it is being changed in
Git 2.0.  Also provided additional information to help users
decide if this change will affect their workflow.

Signed-off-by: Greg Jacobson 
---
 builtin/push.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/builtin/push.c b/builtin/push.c
index 7b1b66c..eb7a721 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -174,6 +174,15 @@ N_("push.default is unset; its implicit value is
changing in\n"
"\n"
"  git config --global push.default simple\n"
"\n"
+   "When push.default is set to matching git will push all local branches\n"
+   "to the remote branches with the same (matching) name.  This will no\n"
+   "longer be the default in Git 2.0 because a branch could be\n"
+   "unintentionally pushed to a remote.\n"
+   "\n"
+   "In Git 2.0 the new push.default of simple will push only the current\n"
+   "branch to the same remote branch used by git pull.   A push will\n"
+   "only succeed if the remote and local branches have the same name.\n"
+   "\n"
"See 'git help config' and search for 'push.default' for further
information.\n"
"(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n"
"'current' instead of 'simple' if you sometimes use older versions
of Git)");
-- 
1.8.4.474.g128a96c.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] push: Enhance unspecified push default warning

[Philip Oakley]

From: "Greg Jacobson" 

When the unset push.default warning message is displayed
this may be the first time many users encounter push.default.
Modified the warning message to explain in a compact
manner what push.default is and why it is being changed in
Git 2.0.  Also provided additional information to help users
decide if this change will affect their workflow.

Signed-off-by: Greg Jacobson 
---
builtin/push.c | 9 +
1 file changed, 9 insertions(+)

diff --git a/builtin/push.c b/builtin/push.c
index 7b1b66c..eb7a721 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -174,6 +174,15 @@ N_("push.default is unset; its implicit value is
changing in\n"
   "\n"
   "  git config --global push.default simple\n"
   "\n"


Should 'matching' and 'simple' be quoted below for additional clarity?

+   "When push.default is set to matching git will push all local 
branches\n"
"When push.default is set to 'matching', git will push all local 
branches\n"


+   "to the remote branches with the same (matching) name.  This will 
no\n"

+   "longer be the default in Git 2.0 because a branch could be\n"
+   "unintentionally pushed to a remote.\n"
+   "\n"
+   "In Git 2.0 the new push.default of simple will push only the 
current\n"
"In Git 2.0 the new push.default of 'simple' will push only the 
current\n"


+   "branch to the same remote branch used by git pull.   A push 
will\n"
+   "only succeed if the remote and local branches have the same 
name.\n"

+   "\n"
   "See 'git help config' and search for 'push.default' for further
information.\n"
   "(the 'simple' mode was introduced in Git 1.7.11. Use the similar 
mode\n"

   "'current' instead of 'simple' if you sometimes use older versions
of Git)");
--
Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

PLEASE I NEED YOUR HELP

[Foots, Alisha]

I am Mrs, Nancy Butler. I have a foundation/Estate uncompleted {worth sum of 
USD 4,142,728.00 Dollars} and need somebody to help me finish it because of my 
health. Contact me with this email ( 
nancybutler...@yahoo.co.uk ).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/Makefile: make AsciiDoc dblatex dir configurable

[Miklos Vajna]

On Thu, Oct 03, 2013 at 08:17:32PM +0100, John Keeping  
wrote:
> On my system this is in /usr/share/asciidoc/dblatex not
> /etc/asciidoc/dblatex.  Extract this portion of the path to a variable
> so that is can be set in config.mak.

Sure, makes sense.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dead links, broken search box, confusing/inconvenient contact

[Tay Ray Chuan]

On Fri, Oct 4, 2013 at 1:50 AM, Stefan Pochmann
 wrote:
> 4) When I found this email address and sent a mail with items 1)-3), I
> got a rejection reply saying " The message contains HTML subpart".
> Very annoying. I'm trying to help here by pointing out problems, and
> you're making it really inconvenient.

Majordomo, the software that runs this mailing list (and many others)
considers HTML to be a mark of spam:

  Usage of HTML in email -- even as an alternate format -- is
considered to be signature characteristics of SPAM.

source: http://vger.kernel.org/majordomo-info.html

Just want to point out it's not "us".

-- 
Cheers,
Ray Chuan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[no subject]

[jerryfunds1]

Do You Need A Loan? Email Us Now At jerryfund...@rediffmail.com With Amount 
Needed As Loan And Phone Number.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] add: add --bulk to index all objects into a pack file

[Nguyễn Thái Ngọc Duy]

The use case is

tar -xzf bigproject.tar.gz
cd bigproject
git init
git add .
# git grep or something

The first add will generate a bunch of loose objects. With --bulk, all
of them are forced into a single pack instead, less clutter on disk
and maybe faster object access.

On gdb-7.5.1 source directory, the loose .git directory takes 66M
according to `du` while the packed one takes 32M. Timing of
"git grep --cached":

  loose packed
real0m1.671s   0m1.372s
user0m1.542s   0m1.313s
sys 0m0.126s   0m0.056s

It's not an all-win situation though. --bulk is slower than --no-bulk
because:

 - Triple hashing: we need to calculate both object SHA-1s _and_ pack
   SHA-1. At the end we have to fix up the pack, which means rehashing
   the entire pack again. --no-bulk only cares about object SHA-1s.

 - We write duplicate objects to the pack then truncate it, because we
   don't know if it's a duplicate until we're done writing, and cannot
   keep it in core because it's potentially big. So extra I/O (but
   hopefully not too much because duplicate objects should not happen
   often).

 - Sort and write .idx file.

 - (For the future) --no-bulk could benefit from multithreading
   because this is CPU bound operation. --bulk could not.

But again this comparison is not fair, --bulk is closer to:

git add . &&
git ls-files --stage | awk '{print $2;}'| \
git pack-objects .git/objects/pack-

except that it does not deltifies nor sort objects.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 v2 examines pros and cons of --bulk and I'm not sure if turning it on
 automatically (with heuristics) is a good idea anymore.

 Oh and it fixes not packing empty files.

 Documentation/git-add.txt | 10 ++
 builtin/add.c | 10 +-
 sha1_file.c   |  3 ++-
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 48754cb..147d191 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -160,6 +160,16 @@ today's "git add ...", ignoring removed files.
be ignored, no matter if they are already present in the work
tree or not.
 
+--bulk::
+   Normally new objects are indexed and stored in loose format,
+   one file per new object in "$GIT_DIR/objects". This option
+   forces putting all objects into a single new pack. This may
+   be useful when you need to add a lot of files initially.
++
+This option is equivalent to running `git -c core.bigFileThreshold=0 add`.
+If you want to only pack files larger than a size threshold, use the
+long form.
+
 \--::
This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken
diff --git a/builtin/add.c b/builtin/add.c
index 226f758..40cbb71 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -336,7 +336,7 @@ static struct lock_file lock_file;
 static const char ignore_error[] =
 N_("The following paths are ignored by one of your .gitignore files:\n");
 
-static int verbose, show_only, ignored_too, refresh_only;
+static int verbose, show_only, ignored_too, refresh_only, bulk_index;
 static int ignore_add_errors, intent_to_add, ignore_missing;
 
 #define ADDREMOVE_DEFAULT 0 /* Change to 1 in Git 2.0 */
@@ -368,6 +368,7 @@ static struct option builtin_add_options[] = {
OPT_BOOL( 0 , "refresh", &refresh_only, N_("don't add, only refresh the 
index")),
OPT_BOOL( 0 , "ignore-errors", &ignore_add_errors, N_("just skip files 
which cannot be added because of errors")),
OPT_BOOL( 0 , "ignore-missing", &ignore_missing, N_("check if - even 
missing - files are ignored in dry run")),
+   OPT_BOOL( 0 , "bulk", &bulk_index, N_("pack all objects instead of 
creating loose ones")),
OPT_END(),
 };
 
@@ -560,6 +561,13 @@ int cmd_add(int argc, const char **argv, const char 
*prefix)
free(seen);
}
 
+   if (bulk_index)
+   /*
+* Pretend all blobs are "large" files, forcing them
+* all into a pack
+*/
+   big_file_threshold = 0;
+
plug_bulk_checkin();
 
if ((flags & ADD_CACHE_IMPLICIT_DOT) && prefix) {
diff --git a/sha1_file.c b/sha1_file.c
index f80bbe4..8b66840 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -3137,7 +3137,8 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st,
 
if (!S_ISREG(st->st_mode))
ret = index_pipe(sha1, fd, type, path, flags);
-   else if (size <= big_file_threshold || type != OBJ_BLOB ||
+   else if ((big_file_threshold && size <= big_file_threshold) ||
+type != OBJ_BLOB ||
 (path && would_convert_to_git(path, NULL, 0, 0)))
ret = index_core(sha1, fd, size, type, path, flags);
else
-- 
1.8.2.82.gc24b958

--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod