* Re: [RFC 0/4] Shallow clones with on-demand fetch
From: Junio C Hamano @ 2017-03-06 19:18 UTC (permalink / raw)
To: Mark Thomas; +Cc: git
In-Reply-To: <20170304191901.9622-1-markbt@efaref.net>
Mark Thomas <markbt@efaref.net> writes:
> This is a proof-of-concept, so it is in no way complete. It contains a
> few hacks to make it work, but these can be ironed out with a bit more
> work. What I have so far is sufficient to try out the idea.
Two things that immediately come to mind (which may or may not be
real issues) are
(1) What (if any) security model you have in mind.
From object-confidentiality's point of view, this needs to be
enabled only on a host that allows
uploadpack.allowAnySHA1InWant but even riskier.
From DoS point of view, you can make a short 40-byte request to
cause the other side emit megabytes of stuff. I do not think
it is a new problem (anybody can repeatedly request a clone of
large stuff), but there may be new ramifications.
(2) If the interface to ask just one object kills the whole idea
due to roundtrip latency.
You may want to be able to say "I want all objects reachable
from this tree; please give me a packfile of needed objects
assuming that I have all objects reachable from this other tree
(or these other trees)".
^ permalink raw reply
* Re: RFC: Another proposed hash function transition plan
From: Linus Torvalds @ 2017-03-06 19:22 UTC (permalink / raw)
To: Jonathan Tan
Cc: Jeff King, Jonathan Nieder, Git Mailing List, Stefan Beller,
bmwill
In-Reply-To: <cdd7779a-acdb-99fd-a685-89b36df65393@google.com>
On Mon, Mar 6, 2017 at 10:39 AM, Jonathan Tan <jonathantanmy@google.com> wrote:
>
> I think "nohash" can be explained in 2 points:
I do think that that was my least favorite part of the suggestion. Not
just "nohash", but all the special "hash" lines too.
I would honestly hope that the design should not be about "other
hashes". If you plan your expectations around the new hash being
broken, something is wrong to begin with.
I do wonder if things wouldn't be simpler if the new format just
included the SHA1 object name in the new object. Put it in the
"header" line of the object, so that every time you look up an object,
you just _see_ the SHA1 of that object. You can even think of it as an
additional protection.
Btw, the multi-collision attack referenced earlier does _not_ work for
an iterated hash that has a bigger internal state than the final hash.
Which is actually a real argument against sha-256: the internal state
of sha-256 is 256 bits, so if an attack can find collisions due to
some weakness, you really can then generate exponential collisions by
chaining a linear collision search together.
But for sha3-256 or blake2, the internal hash state is larger than the
final hash, so now you need to generate collisions not in the 256
bits, but in the much larger search space of the internal hash space
if you want to generate those exponential collisions.
So *if* the new object format uses a git header line like
"blob <size> <sha1>\0"
then it would inherently contain that mapping from 256-bit hash to the
SHA1, but it would actually also protect against attacks on the new
hash. In fact, in particular for objects with internal format that
differs between the two hashing models (ie trees and commits which to
some degree are higher-value targets), it would make attacks really
quite complicated, I suspect.
And you wouldn't need those "hash" or "nohash" things at all. The old
SHA1 would simply always be there, and cheap to look up (ie you
wouldn't have to unpack the whole object).
Hmm?
Linus
^ permalink raw reply
* Re: [PATCH v3] Travis: also test on 32-bit Linux
From: Junio C Hamano @ 2017-03-06 19:21 UTC (permalink / raw)
To: Lars Schneider; +Cc: git, Johannes.Schindelin, ramsay, christian.couder
In-Reply-To: <20170305182519.98925-1-larsxschneider@gmail.com>
Lars Schneider <larsxschneider@gmail.com> writes:
> when I looked into the 32-bit/line-log issue [1], I realized that my
> proposed docker setup is not ideal for local debugging. Here is an
> approach that I think is better. I changed the following:
> - disable sudo as it is not required for the Travis job
> - keep all docker commands in the .travis.yml
> - add option to run commands inside docker with the same UID as the
> host user to make output files accessible
> - pass environment variables directly to the docker container
>
> Sorry for the back and forth.
Anything that makes further diag easier when a problem is spotted by
the automated machinery is a very welcome change.
Will replace; let's see what others think.
Thanks.
^ permalink raw reply
* Re: [PATCH 01/10] submodule: decouple url and submodule existence
From: Brandon Williams @ 2017-03-06 18:50 UTC (permalink / raw)
To: Stefan Beller; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <CAGZ79kb9Fhb0z5AbygBx9wNyLr-ovb-74xeaD8p+C5Xz9Dekcw@mail.gmail.com>
On 03/01, Stefan Beller wrote:
Sorry I've been slow at rerolling this. I'll send out a reroll today.
> IIRC most of the series is actually refactoring, i.e.
> providing a central function that answers
> "is this submodule active/initialized?" and then making use of this
> function.
>
> Maybe it would be easier to reroll these refactorings first without adding
> in the change of behavior.
I agree, when I resend out the series I can drop the first patch so that
the series as a whole just moves to using a standardized function to
check that a submodule is active. I can then resend out the first patch
in the series on its own so that we can more easily discuss the best
route to take.
>
> Off the list we talked about different models how to indicate that
> a submodule is active.
>
> Current situation:
> submodule.<name>.URL is used as a boolean flag
>
> Possible future A:
> 1) If submodule.active exists use that
> 2) otherwise go be individual .URL configs
>
> submodule.active is a config that contains a pathspec,
> i.e. specifies the group of submodules instead of marking
> each submodule individually.
>
> How to get to future A:
> * apply this patch series
>
> Possible future B:
> 1) the boolean submodule.<name>.exists is used
> if existent
> 2) If that boolean is missing we'd respect a grouping
> feature such as submodule.active
> 3) fallback to the .URL as a boolean indicator.
Thinking on this, and to maintain simplicity and uniformity, we could
have the per-submodule boolean flag to be "submodule.<name>.active"
while the general pathspec based config option would be
"submodule.active".
>
> How to get to future B:
> 1) possibly take the refactoring part from this series
> 2) implement the .exists flag (that can solve the worktree
> problem, as then we don't have to abuse the .URL
> as a boolean indicator any more.)
> 3) implement the grouping feature that takes precedence
> over .URL, but yields precedence to the .exists flag.
> (This would solve the grouping problem)
>
> By having two different series (2) and (3) we'd solve
> just one thing at a time with each series, such that
> this seems easier to understand and review.
>
> The question is if this future B is also easier to use for
> users and I think it would be, despite being technically more
> complex.
>
> Most users only have a few submodules. Also the assumption
> is to have either interest in very few specific submodules
> or all of them. For both of these cases the .exists is a good idea
> as it is very explicit, but verbose.
>
> The grouping feature would help in the case of lots of
> submodules, e.g. to select all of them you would just give
> an easy pathspec "." and that would help going forward
> as by such a submodule spec all new submodules would
> be "auto-on".
And if you wanted all but one you could have submodule.active="." while
submodule.dontwant.active=false instead of having a multi value
submodule.active with an exclusion pathspec. Both work but one may be
easier for a user to understand.
>
> Possible future C:
> Similar to B, but with branch specific configuration.
> submodule.<branchname>.active would work as a
> grouping feature. I wonder how it would work with
> the .exists flag.
>
> Stefan
--
Brandon Williams
^ permalink raw reply
* Re: RFC: Another proposed hash function transition plan
From: Jonathan Tan @ 2017-03-06 18:39 UTC (permalink / raw)
To: Jeff King, Jonathan Nieder; +Cc: git, sbeller, bmwill, Linus Torvalds
In-Reply-To: <20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net>
On 03/06/2017 12:43 AM, Jeff King wrote:
> Overall the basics of the conversion seem sound to me. The "nohash"
> things seems more complicated than I think it ought to be, which
> probably just means I'm missing something. I left a few related
> comments on the google doc, so I won't repeat them here.
I think "nohash" can be explained in 2 points:
1. When creating signed objects, "nohash" is almost never written. Just
create the object as usual and add "hash" lines for every other hash
function that you want the signature to cover.
2. When converting from function A to function B, add "nohash B" if
there were no "hash B" lines in the original object.
The "nohash" thing was in the hope of requiring only one signature to
sign all the hashes (in all the functions) that the user wants, while
preserving round-tripping ability.
Maybe some examples would help to address the apparent complexity. These
examples are the same as those in the document. I'll also show future
compatibility with a hypothetical NEW hash function, and extend the rule
about signing/verification to 'sign in the earliest supported hash
function in ({object's hash function} + {functions in "hash" lines} -
{function in "nohash" line})'.
Example 1 (existing signed commit)
<sha-1 object stuff> <sha256 object stuff> <NEW object stuff>
nohash sha256 nohash new
hash sha1 ... hash sha1 ...
This object was probably created in a SHA-1 repository with no knowledge
that we were going to transition to SHA256 (but there is nothing
preventing us from creating the middle or right object and then
translating it to the other functions).
Example 2 (recommended way to sign a commit in a SHA256 repo)
<sha-1 object stuff> <sha256 object stuff> <NEW object stuff>
hash sha256 ... hash sha1 ... nohash new
hash sha1 ...
hash sha256 ...
This is the recommended way to create a SHA256 object in a SHA256 repo.
The rule about signing/verification (as stated above) is to sign in
SHA-1, so when signing or verifying, we convert the object to SHA-1 and
use that as the payload. Note that the signature covers both the SHA-1
and SHA256 hashes, and that existing Git implementations can verify the
signature.
Example 3 (a signer that does not care about SHA-1 anymore)
<sha-1 object stuff> <sha256 object stuff> <NEW object stuff>
nohash sha1 nohash new
hash sha256 ... hash sha256 ...
If we were to create a SHA256 object without any mentions of SHA-1, the
rule about signing/verification (as stated above) states that the
signature payload is the SHA256 object. This means that existing Git
implementations cannot verify the signature, but we can still round-trip
to SHA-1 and back without losing any information (as far as I can tell).
^ permalink raw reply
* Re: RFC: Another proposed hash function transition plan
From: Junio C Hamano @ 2017-03-06 18:43 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, git, sbeller, bmwill, jonathantanmy,
Linus Torvalds
In-Reply-To: <20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> You can use the doc URL
>>
>> https://goo.gl/gh2Mzc
>
> I'd encourage anybody following along to follow that link. I almost
> didn't, but there are a ton of comments there (I'm not sure how I feel
> about splitting the discussion off the list, though).
I am sure how I feel about it---we should really discourage it,
unless it is an effort to help polishing an early draft for wider
distribution and discussion.
> I don't think we do this right now, but you can actually find the entry
> (and exit) points of a pack during the index-pack step. Basically:
We have code to do the "entry point" computation in index-pack
already, I think, in 81a04b01 ("index-pack: --clone-bundle option",
2016-03-03).
> I don't think using the "want"s as the entry points is unreasonable,
> though. The server _shouldn't_ generally be sending us other cruft.
That's true.
^ permalink raw reply
* Re: RFC: Another proposed hash function transition plan
From: Brandon Williams @ 2017-03-06 18:24 UTC (permalink / raw)
To: brian m. carlson, Linus Torvalds, Jonathan Nieder,
Git Mailing List, Stefan Beller, jonathantanmy, Jeff King
In-Reply-To: <20170306002642.xlatomtcrhxwshzn@genre.crustytoothpaste.net>
On 03/06, brian m. carlson wrote:
> On Sat, Mar 04, 2017 at 06:35:38PM -0800, Linus Torvalds wrote:
> > On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > >
> > > This document is still in flux but I thought it best to send it out
> > > early to start getting feedback.
> >
> > This actually looks very reasonable if you can implement it cleanly
> > enough. In many ways the "convert entirely to a new 256-bit hash" is
> > the cleanest model, and interoperability was at least my personal
> > concern. Maybe your model solves it (devil in the details), in which
> > case I really like it.
>
> If you think you can do it, I'm all for it.
>
> > Btw, I do think the particular choice of hash should still be on the
> > table. sha-256 may be the obvious first choice, but there are
> > definitely a few reasons to consider alternatives, especially if it's
> > a complete switch-over like this.
> >
> > One is large-file behavior - a parallel (or tree) mode could improve
> > on that noticeably. BLAKE2 does have special support for that, for
> > example. And SHA-256 does have known attacks compared to SHA-3-256 or
> > BLAKE2 - whether that is due to age or due to more effort, I can't
> > really judge. But if we're switching away from SHA1 due to known
> > attacks, it does feel like we should be careful.
>
> I agree with Linus on this. SHA-256 is the slowest option, and it's the
> one with the most advanced cryptanalysis. SHA-3-256 is faster on 64-bit
> machines (which, as we've seen on the list, is the overwhelming majority
> of machines using Git), and even BLAKE2b-256 is stronger.
>
> Doing this all over again in another couple years should also be a
> non-goal.
I agree that when we decide to move to a new algorithm that we should
select one which we plan on using for as long as possible (much longer
than a couple years). While writing the document we simply used
"sha256" because it was more tangible and easier to reference.
> --
> brian m. carlson / brian with sandals: Houston, Texas, US
> +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
> OpenPGP: https://keybase.io/bk2204
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH v2] http: inform about alternates-as-redirects behavior
From: Brandon Williams @ 2017-03-06 18:03 UTC (permalink / raw)
To: Jeff King
Cc: Eric Wong, Junio C Hamano, Jann Horn, git, sbeller, bburky,
jrnieder
In-Reply-To: <20170304084547.4mg4beudseznaw72@sigill.intra.peff.net>
On 03/04, Jeff King wrote:
> On Sat, Mar 04, 2017 at 08:36:45AM +0000, Eric Wong wrote:
>
> > I also think the security implications for relative alternates
> > on the same host would not matter, since the smart HTTP will
> > take them into account on the server side.
>
> It depends on the host whether all of the repos on it have the same
> security domain or not. A site like github.com hosts both public and
> private repositories, and you do not want a public repo redirecting to
> the private one to get objects.
>
> Of course, that depends on untrusted users being able to configure
> server-side alternates, which GitHub certainly would not let you do. I
> would hope other multi-user hosting sites behave similarly (most hosting
> sites do not seem to allow dumb http at all).
>
> > Perhaps we give http_follow_config ORable flags:
> >
> > HTTP_FOLLOW_NONE = 0,
> > HTTP_FOLLOW_INITIAL = 0x1,
> > HTTP_FOLLOW_RELATIVE = 0x2,
> > HTTP_FOLLOW_ABSOLUTE = 0x4,
> > HTTP_FOLLOW_ALWAYS = 0x7,
> >
> > With the default would being: HTTP_FOLLOW_INITIAL|HTTP_FOLLOW_RELATIVE
> > (but I suppose that's a patch for another time)
>
> I don't have a real problem with breaking it down that way, if somebody
> wants to make a patch. Mostly the reason I didn't do so is that I don't
> think http-alternates are in common use these days, since smart-http is
> much more powerful.
>
> > ----------8<-----------
> > From: Eric Wong <e@80x24.org>
> > Subject: [PATCH] http: inform about alternates-as-redirects behavior
>
> This v2 looks fine to me.
>
> -Peff
I know I'm a little late to the party but v2 looks good to me too. I
like the change from v1 that only mentions the config option as opposed
to listing a value it should be set to.
--
Brandon Williams
^ permalink raw reply
* Re: git init --separate-git-dir does not update symbolic .git links for submodules
From: Stefan Beller @ 2017-03-06 16:40 UTC (permalink / raw)
To: Valery Tolstov; +Cc: sven, git@vger.kernel.org, Junio C Hamano
In-Reply-To: <1488636950.25023.2@smtp.yandex.ru>
On Sat, Mar 4, 2017 at 6:15 AM, Valery Tolstov <me@vtolstov.org> wrote:
> Looking for microproject ideas for GSoC.
> Would this issue be suitable as the microproject?
It would be a good project, but not as 'micro' I would assume. ;)
Why it is not a micro project:
To fix this issue we'd want to fix the .git link files recursively, i.e.
nested submodules would also need fixing. And to recurse into
submodules we normally spawn a child process.
So maybe the plan is as follow:
1) Add the functionality to builtin/submodule--helper.c
it fixes just one submodule, given by name.
2) add an externally visible command in the same file
See e.g. module_name (the function and the table
at the very end of the file)
(1) needs to call this command (see clone_submodule() in
that file how to call further commands)
2) "git init --separate-git-dir ../test" would call the function
in (1), which then recursively uses (2) to call (1) in nested
submodules.
After thinking about it, it may be good for a micro project,
as it is smaller than originally assumed.
Specifically if you plan to look into submodules later on.
Thanks,
Stefan
^ permalink raw reply
* fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |
From: Zenobiusz Kunegunda @ 2017-03-06 16:10 UTC (permalink / raw)
To: git
OS: FreeBSD 10.3-STABLE
Story:
I was trying to install openproject using this manual
https://www.openproject.org/open-source/download/manual-installation-guide/
Everything was fine till command
$ bundle install --deployment --without postgres sqlite development test therubyracer docker
works witg git version:
1.9.5 ( branch from repo )
does not work with git version:
2.10 ( branch from from repo )
2.11 ( both from FreeBSD and from git repository)
2.12 ( branch from repo )
On another server that passed but there was npm problem.
This is error for
$ bundle install --deployment --without postgres sqlite development test therubyracer docker
=== output begin ===
Error message (this is from git 2.11; 2.10 and 2.12 report same error):
$ bundle install --deployment --without postgres sqlite development test therubyracer docker
The git source `git://github.com/oliverguenther/omniauth.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/finnlabs/awesome_nested_set.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/why-el/svg-graph.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/opf/rails-angular-xss.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/goodwill/capybara-select2.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/omniauth/omniauth-saml.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
Fetching gem metadata from https://rubygems.org/.......
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
fatal: Could not get current working directory: Permission denied
Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` due to error (2/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2 has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'fatal: Could not get current working directory: Permission denied
Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` due to error (3/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2 has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'fatal: Could not get current working directory: Permission denied
Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` due to error (4/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2 has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'fatal: Could not get current working directory: Permission denied
Git error: command `git fetch --force --quiet --tags
"/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7"`
in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2 has
failed.
If this error persists you could try removing the cache directory
'/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7'
=== output end ===
removing cache directory did not help
My own debuging( git 2.12 ):
diff --git a/Makefile b/Makefile
index 9ec6065cc..391d765e7 100644
--- a/Makefile
+++ b/Makefile
@@ -405,7 +405,7 @@ DEVELOPER_CFLAGS = -Werror \
-Wstrict-prototypes \
-Wunused \
-Wvla
-LDFLAGS =
+LDFLAGS = -lexecinfo
ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
@@ -1437,6 +1437,7 @@ ifdef RUNTIME_PREFIX
COMPAT_CFLAGS += -DRUNTIME_PREFIX
endif
+#define NO_PTHREADS 1
ifdef NO_PTHREADS
BASIC_CFLAGS += -DNO_PTHREADS
else
diff --git a/setup.c b/setup.c
index 967f289f1..0879b755f 100644
--- a/setup.c
+++ b/setup.c
@@ -848,6 +848,7 @@ static const char *setup_git_directory_gently_1(int *nongit_ok)
if (nongit_ok)
*nongit_ok = 0;
+ fprintf(stderr,"*** DBG ***\n");
if (strbuf_getcwd(&cwd))
die_errno(_("Unable to read current working directory"));
offset = cwd.len;
diff --git a/strbuf.c b/strbuf.c
index 8fec6579f..bd598e440 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -442,13 +442,25 @@ int strbuf_getcwd(struct strbuf *sb)
{
size_t oldalloc = sb->alloc;
size_t guessed_len = 128;
+char *USER_diag;
+int USER_i=0;
+
+ struct timespec spec;
+
+ clock_gettime(CLOCK_REALTIME, &spec);
+
+
+ fprintf(stderr,"PID:%d DBG[strbuf_getcwd()]\n",getpid());
for (;; guessed_len *= 2) {
strbuf_grow(sb, guessed_len);
- if (getcwd(sb->buf, sb->alloc)) {
+ fprintf(stderr,"PID:%d TIME:%ld DBG<BEFORE getcwd()> sb->buf[%s]length(%lu) sb->alloc[%lu]\n",getpid(),spec.tv_nsec,sb->buf,strlen(sb->buf),sb->alloc);
...skipping...
diff --git a/Makefile b/Makefile
diff --git a/Makefile b/Makefile
index 9ec6065cc..391d765e7 100644
--- a/Makefile
+++ b/Makefile
@@ -405,7 +405,7 @@ DEVELOPER_CFLAGS = -Werror \
-Wstrict-prototypes \
-Wunused \
-Wvla
-LDFLAGS =
+LDFLAGS = -lexecinfo
ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
@@ -1437,6 +1437,7 @@ ifdef RUNTIME_PREFIX
COMPAT_CFLAGS += -DRUNTIME_PREFIX
endif
+#define NO_PTHREADS 1
ifdef NO_PTHREADS
BASIC_CFLAGS += -DNO_PTHREADS
else
diff --git a/setup.c b/setup.c
index 967f289f1..0879b755f 100644
--- a/setup.c
+++ b/setup.c
@@ -848,6 +848,7 @@ static const char *setup_git_directory_gently_1(int *nongit_ok)
if (nongit_ok)
*nongit_ok = 0;
+ fprintf(stderr,"*** DBG ***\n");
if (strbuf_getcwd(&cwd))
die_errno(_("Unable to read current working directory"));
offset = cwd.len;
diff --git a/strbuf.c b/strbuf.c
index 8fec6579f..bd598e440 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -442,13 +442,25 @@ int strbuf_getcwd(struct strbuf *sb)
{
size_t oldalloc = sb->alloc;
size_t guessed_len = 128;
+char *USER_diag;
+int USER_i=0;
+
+ struct timespec spec;
+
+ clock_gettime(CLOCK_REALTIME, &spec);
+
+
+ fprintf(stderr,"PID:%d DBG[strbuf_getcwd()]\n",getpid());
for (;; guessed_len *= 2) {
strbuf_grow(sb, guessed_len);
- if (getcwd(sb->buf, sb->alloc)) {
+ fprintf(stderr,"PID:%d TIME:%ld DBG<BEFORE getcwd()> sb->buf[%s]length(%lu) sb->alloc[%lu]\n",getpid(),spec.tv_nsec,sb->buf,strlen(sb->buf),sb->alloc);
+ if (USER_diag=getcwd(sb->buf, sb->alloc)) {
+ USER_i++;
+ fprintf(stderr,"PID:%d getcwd success? Result [%s] loop step number %d\n",getpid(),USER_diag,USER_i);
strbuf_setlen(sb, strlen(sb->buf));
return 0;
- }
+ }else{fprintf(stderr,"PID: %d >>DBG<< not expected value!\n",getpid());}
if (errno != ERANGE)
break;
}
diff --git a/usage.c b/usage.c
index ad6d2910f..989403829 100644
--- a/usage.c
+++ b/usage.c
@@ -6,6 +6,8 @@
#include "git-compat-util.h"
#include "cache.h"
+#include <execinfo.h>
+
static FILE *error_handle;
void vreportf(const char *prefix, const char *err, va_list params)
@@ -30,7 +32,21 @@ static NORETURN void usage_builtin(const char *err, va_list params)
static NORETURN void die_builtin(const char *err, va_list params)
{
- vreportf("fatal: ", err, params);
+ void *btlist[30];
+ size_t size, i;
+ char **strings;
+
+ size=backtrace(btlist,30);
+ strings=backtrace_symbols(btlist,size);
+
+ fprintf(stderr,"\n-----[DBG] PID:%d -----\n",getpid());
+ for (i = 0; i < size; i++)
+ fprintf (stderr,"%s\n", strings[i]);
+
+ free (strings);
+
+ vreportf("DBG fatal: ", err, params);
+ fprintf(stderr,"\n----------------\n");
exit(128);
}
After installation of altered git:
$bundle install --deployment --without postgres sqlite development test therubyracer docker
=== DEBUG OUTPUT BEGIN ===
The git source `git://github.com/oliverguenther/omniauth.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/finnlabs/awesome_nested_set.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/why-el/svg-graph.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/opf/rails-angular-xss.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/goodwill/capybara-select2.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
The git source `git://github.com/omniauth/omniauth-saml.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
Fetching gem metadata from https://rubygems.org/.......
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
*** DBG ***
PID:94818 DBG[strbuf_getcwd()]
PID:94818 TIME:319762826 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94818 >>DBG<< not expected value!
PID:94818 TIME:319762826 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94818 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7] loop step number 1
PID:94818 DBG[strbuf_getcwd()]
PID:94818 TIME:323757205 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94818 >>DBG<< not expected value!
PID:94818 TIME:323757205 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94818 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7] loop step number 1
*** DBG ***
PID:94819 DBG[strbuf_getcwd()]
PID:94819 TIME:335244142 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94819 >>DBG<< not expected value!
PID:94819 TIME:335244142 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94819 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94819 DBG[strbuf_getcwd()]
PID:94819 TIME:338873233 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94819 >>DBG<< not expected value!
PID:94819 TIME:338873233 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94819 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94819 DBG[strbuf_getcwd()]
PID:94819 TIME:343362594 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94819 >>DBG<< not expected value!
PID:94819 TIME:343362594 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94819 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94820 DBG[strbuf_getcwd()]
PID:94820 TIME:353434903 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94820 >>DBG<< not expected value!
PID:94820 TIME:353434903 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94820 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/awesome_nested_set-209215f38dc7f6765d32201897f8688e973f4de7] loop step number 1
*** DBG ***
PID:94822 DBG[strbuf_getcwd()]
PID:94822 TIME:371149025 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94822 >>DBG<< not expected value!
PID:94822 TIME:371149025 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94822 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94822 DBG[strbuf_getcwd()]
PID:94822 TIME:374747601 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94822 >>DBG<< not expected value!
PID:94822 TIME:374747601 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94822 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94822 DBG[strbuf_getcwd()]
PID:94822 TIME:378719206 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94822 >>DBG<< not expected value!
PID:94822 TIME:378719206 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94822 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94823 DBG[strbuf_getcwd()]
PID:94823 TIME:389423303 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94823 >>DBG<< not expected value!
PID:94823 TIME:389423303 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94823 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94823 DBG[strbuf_getcwd()]
PID:94823 TIME:392901921 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94823 >>DBG<< not expected value!
PID:94823 TIME:392901921 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94823 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94823 DBG[strbuf_getcwd()]
PID:94823 TIME:396779140 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94823 >>DBG<< not expected value!
PID:94823 TIME:396779140 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94823 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:405767954 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:405767954 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:409104219 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:409104219 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:413360941 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:413360941 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:416863094 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:416863094 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:420124766 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:420124766 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:425145306 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:425145306 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:428797180 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:428797180 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94824 DBG[strbuf_getcwd()]
PID:94824 TIME:432288523 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94824 >>DBG<< not expected value!
PID:94824 TIME:432288523 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94824 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94841 DBG[strbuf_getcwd()]
PID:94841 TIME:473033293 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94841 >>DBG<< not expected value!
PID:94841 TIME:473033293 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94841 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94841 DBG[strbuf_getcwd()]
PID:94841 TIME:476443996 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94841 >>DBG<< not expected value!
PID:94841 TIME:476443996 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94841 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94843 DBG[strbuf_getcwd()]
PID:94843 TIME:483572829 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94843 >>DBG<< not expected value!
PID:94843 TIME:483572829 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94843 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94843 DBG[strbuf_getcwd()]
PID:94843 TIME:487028828 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94843 >>DBG<< not expected value!
PID:94843 TIME:487028828 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94843 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94844 DBG[strbuf_getcwd()]
PID:94844 TIME:493903306 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94844 >>DBG<< not expected value!
PID:94844 TIME:493903306 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94844 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94844 DBG[strbuf_getcwd()]
PID:94844 TIME:497394735 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94844 >>DBG<< not expected value!
PID:94844 TIME:497394735 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94844 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94846 DBG[strbuf_getcwd()]
PID:94846 TIME:509674151 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94846 >>DBG<< not expected value!
PID:94846 TIME:509674151 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94846 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94846 DBG[strbuf_getcwd()]
PID:94846 TIME:512716769 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94846 >>DBG<< not expected value!
PID:94846 TIME:512716769 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94846 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94847 DBG[strbuf_getcwd()]
PID:94847 TIME:520195459 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94847 >>DBG<< not expected value!
PID:94847 TIME:520195459 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94847 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94847 DBG[strbuf_getcwd()]
PID:94847 TIME:523205769 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94847 >>DBG<< not expected value!
PID:94847 TIME:523205769 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94847 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94850 DBG[strbuf_getcwd()]
PID:94850 TIME:531746240 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94850 >>DBG<< not expected value!
PID:94850 TIME:531746240 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94850 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
PID:94850 DBG[strbuf_getcwd()]
PID:94850 TIME:534777909 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94850 >>DBG<< not expected value!
PID:94850 TIME:534777909 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94850 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/awesome_nested_set-7bd473e845e2] loop step number 1
*** DBG ***
PID:94853 DBG[strbuf_getcwd()]
PID:94853 TIME:584052480 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94853 >>DBG<< not expected value!
PID:94853 TIME:584052480 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94853 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2] loop step number 1
PID:94853 DBG[strbuf_getcwd()]
PID:94853 TIME:587643433 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94853 >>DBG<< not expected value!
PID:94853 TIME:587643433 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[257]
PID:94853 getcwd success? Result [/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2] loop step number 1
*** DBG ***
PID:94854 DBG[strbuf_getcwd()]
PID:94854 TIME:598012950 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94854 >>DBG<< not expected value!
-----[DBG] PID:94854 -----
0x550612 <die_builtin+0x32> at /home/USER/bin/git
0x5500d9 <die_errno+0xc9> at /home/USER/bin/git
0x526f67 <setup_git_directory_gently+0x677> at /home/USER/bin/git
0x405635 <handle_builtin+0x145> at /home/USER/bin/git
0x404fcd <cmd_main+0xfd> at /home/USER/bin/git
0x47f779 <main+0x69> at /home/USER/bin/git
0x404d8f <_start+0x16f> at /home/USER/bin/git
DBG fatal: Unable to read current working directory: Permission denied
----------------
Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` due to error (2/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/omniauth-8385bc0da47e has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2'*** DBG ***
PID:94855 DBG[strbuf_getcwd()]
PID:94855 TIME:617961661 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94855 >>DBG<< not expected value!
-----[DBG] PID:94855 -----
0x550612 <die_builtin+0x32> at /home/USER/bin/git
0x5500d9 <die_errno+0xc9> at /home/USER/bin/git
0x526f67 <setup_git_directory_gently+0x677> at /home/USER/bin/git
0x405635 <handle_builtin+0x145> at /home/USER/bin/git
0x404fcd <cmd_main+0xfd> at /home/USER/bin/git
0x47f779 <main+0x69> at /home/USER/bin/git
0x404d8f <_start+0x16f> at /home/USER/bin/git
DBG fatal: Unable to read current working directory: Permission denied
----------------
Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` due to error (3/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/omniauth-8385bc0da47e has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2'*** DBG ***
PID:94856 DBG[strbuf_getcwd()]
PID:94856 TIME:649649505 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94856 >>DBG<< not expected value!
-----[DBG] PID:94856 -----
0x550612 <die_builtin+0x32> at /home/USER/bin/git
0x5500d9 <die_errno+0xc9> at /home/USER/bin/git
0x526f67 <setup_git_directory_gently+0x677> at /home/USER/bin/git
0x405635 <handle_builtin+0x145> at /home/USER/bin/git
0x404fcd <cmd_main+0xfd> at /home/USER/bin/git
0x47f779 <main+0x69> at /home/USER/bin/git
0x404d8f <_start+0x16f> at /home/USER/bin/git
DBG fatal: Unable to read current working directory: Permission denied
----------------
Retrying `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` due to error (4/4): Bundler::Source::Git::GitCommandError Git error: command `git fetch --force --quiet --tags "/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"` in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/omniauth-8385bc0da47e has failed.
If this error persists you could try removing the cache directory '/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2'*** DBG ***
PID:94859 DBG[strbuf_getcwd()]
PID:94859 TIME:672228216 DBG<BEFORE getcwd()> sb->buf[]length(0) sb->alloc[129]
PID: 94859 >>DBG<< not expected value!
-----[DBG] PID:94859 -----
0x550612 <die_builtin+0x32> at /home/USER/bin/git
0x5500d9 <die_errno+0xc9> at /home/USER/bin/git
0x526f67 <setup_git_directory_gently+0x677> at /home/USER/bin/git
0x405635 <handle_builtin+0x145> at /home/USER/bin/git
0x404fcd <cmd_main+0xfd> at /home/USER/bin/git
0x47f779 <main+0x69> at /home/USER/bin/git
0x404d8f <_start+0x16f> at /home/USER/bin/git
DBG fatal: Unable to read current working directory: Permission denied
----------------
Git error: command `git fetch --force --quiet --tags
"/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2"`
in directory /usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/bundler/gems/omniauth-8385bc0da47e has failed.
If this error persists you could try removing the cache directory
'/usr/home/USER/openproject/vendor/bundle/ruby/2.2.0/cache/bundler/git/omniauth-9b858eeaf5d57cfe59f1c1084cdc9eb1ee6989b2'
=== DEBUG OUTPUT END ===
Debug meassages have time stamps with time in nanoseconds and PIDs printed.
On another server with same OS configuration there was problem with:
$ npm install
> openproject@0.1.0 postinstall /usr/home/USER/openproject
> cd frontend && npm install
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/opf/angular-context-menu.git /home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc: Cloning into bare repository '/home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc'...
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/opf/angular-context-menu.git /home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc: fatal: Could not get current working directory: Permission denied
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/finnlabs/angular-modal.git /home/USER/.npm/_git-remotes/git-github-com-finnlabs-angular-modal-git-d45eb9ceb720b8785613ba89ba0f14f8ab197569-619b970d: Cloning into bare repository '/home/USER/.npm/_git-remotes/git-github-com-finnlabs-angular-modal-git-d45eb9ceb720b8785613ba89ba0f14f8ab197569-619b970d'...
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/finnlabs/angular-modal.git /home/USER/.npm/_git-remotes/git-github-com-finnlabs-angular-modal-git-d45eb9ceb720b8785613ba89ba0f14f8ab197569-619b970d: fatal: Could not get current working directory: Permission denied
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/sparkalow/angular-truncate.git /home/USER/.npm/_git-remotes/git-github-com-sparkalow-angular-truncate-git-fdf60fda265042d12e9414b5354b2cc52f1419de-3ed663f6: Cloning into bare repository '/home/USER/.npm/_git-remotes/git-github-com-sparkalow-angular-truncate-git-fdf60fda265042d12e9414b5354b2cc52f1419de-3ed663f6'...
npm ERR! git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/sparkalow/angular-truncate.git /home/USER/.npm/_git-remotes/git-github-com-sparkalow-angular-truncate-git-fdf60fda265042d12e9414b5354b2cc52f1419de-3ed663f6: fatal: Could not get current working directory: Permission denied
npm ERR! FreeBSD 10.3-STABLE
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v4.7.2
npm ERR! npm v4.0.5
npm ERR! code 128
npm ERR! Command failed: git clone --template=/home/USER/.npm/_git-remotes/_templates --mirror git://github.com/opf/angular-context-menu.git /home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc
npm ERR! Cloning into bare repository '/home/USER/.npm/_git-remotes/git-github-com-opf-angular-context-menu-git-a908eccaec323cd66973d58af4965694bdff16a1-d8746dcc'...
npm ERR! fatal: Could not get current working directory: Permission denied
npm ERR!
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR! <https://github.com/npm/npm/issues>
npm ERR! Please include the following file with any support request:
npm ERR! /usr/home/USER/openproject/frontend/npm-debug.log
npm ERR! FreeBSD 10.3-STABLE
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v4.7.2
npm ERR! npm v4.0.5
npm ERR! code ELIFECYCLE
npm ERR! openproject@0.1.0 postinstall: `cd frontend && npm install`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the openproject@0.1.0 postinstall script 'cd frontend && npm install'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the openproject package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! cd frontend && npm install
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs openproject
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls openproject
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! /usr/home/USER/openproject/npm-debug.log
^ permalink raw reply related
* Re: Fwd: HTTP Dumb Push?
From: Jeff King @ 2017-03-06 15:45 UTC (permalink / raw)
To: Christian7573; +Cc: git
In-Reply-To: <CAOJpByWFKbWE=HtNVpqDgfoqo1ajNttstNpRaUHT7a5AjObuJg@mail.gmail.com>
On Mon, Mar 06, 2017 at 09:38:33AM -0600, Christian7573 wrote:
> Is there a way for git to push to a server using the dumb protocol?
> Perhaps using the PUT method to upload files?
> Just wondering cause I just set up a dumb server and pushing to it
> doesn't work.
Git dumb-http push protocol goes over DAV. There are instructions in
Documentation/howto/setup-git-server-over-http.txt of the git
repository. They're quite old now, and I have no idea if they've
bit-rotted over the years. Hardly anybody uses that solution these days
(and it's much less efficient than the smart protocol).
> If that isn't an option, where can I get a smart server?
The CGI ships with the rest of git. Try "git help http-backend", which
has some sample config for Apache and lighttpd.
-Peff
^ permalink raw reply
* Fwd: HTTP Dumb Push?
From: Christian7573 @ 2017-03-06 15:38 UTC (permalink / raw)
To: git
In-Reply-To: <CAOJpByWRg1V85CJsX2akuvbKuqFBoGJO+XJu01Kq0KNwuM-YFA@mail.gmail.com>
Is there a way for git to push to a server using the dumb protocol?
Perhaps using the PUT method to upload files?
Just wondering cause I just set up a dumb server and pushing to it
doesn't work. If that isn't an option, where can I get a smart server?
^ permalink raw reply
* Re: Delta compression not so effective
From: Marius Storm-Olsen @ 2017-03-06 13:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <CA+55aFw=U4PbfvVzeyuWk2VOsgicZRRKZRkrGp7jr_ppvgP3ng@mail.gmail.com>
On 3/5/2017 19:14, Linus Torvalds wrote:
> On Sat, Mar 4, 2017 at 12:27 AM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
> I guess you could do the printout a bit earlier (on the
> "to_pack.objects[]" array - to_pack.nr_objects is the count there).
> That should show all of them. But the small objects shouldn't matter.
>
> But if you have a file like
>
> extern/win/FlammableV3/x64/lib/FlameProxyLibD.lib
>
> I would have assumed that it has a size that is > 50. Unless those
> "extern" things are placeholders?
No placeholders, the FlameProxyLibD.lib is a debug lib, and probably the
largest in the whole repo (with a replace count > 5).
> I do wonder if your dll data just simply is absolutely horrible for
> xdelta. We've also limited the delta finding a bit, simply because it
> had some O(m*n) behavior that gets very expensive on some patterns.
> Maybe your blobs trigger some of those case.
Ok, but given that the SVN delta compression, which forward-linear only,
is ~45% better, perhaps that particular search could be done fairly
cheap? Although, I bet time(stamps) are out of the loop at that point,
so it's not a factor anymore. Even if it where, I'm not sure it would
solve anything, if there's other factors also limiting deltafication.
> The diff-delta work all goes back to 2005 and 2006, so it's a long time ago.
>
> What I'd ask you to do is try to find if you could make a reposity of
> just one of the bigger DLL's with its history, particularly if you can
> find some that you don't think is _that_ sensitive.
>
> Looking at it, for example, I see that you have that file
>
> extern/redhat-5/FlammableV3/x64/plugins/libFlameCUDA-3.0.703.so
>
> that seems to have changed several times, and is a largish blob. Could
> you try creating a repository with git fast-import that *only*
> contains that file (or pick another one), and see if that delta's
> well?
I'll filter-branch to extern/ only, however the whole FlammableV3 needs
to go too, I'm afaid (extern for that project, but internal to $WORK).
I'll do some rewrites and see what comes up.
> And if you find some case that doesn't xdelta well, and that you feel
> you could make available outside, we could have a test-case...
I'll try with this repo first, if not, I'll see if I can construct one.
Thanks!
--
.marius
^ permalink raw reply
* Re: [PATCH v5 23/24] t1405: some basic tests on main ref store
From: Duy Nguyen @ 2017-03-06 12:30 UTC (permalink / raw)
To: Michael Haggerty
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin,
Ramsay Jones, Stefan Beller, David Turner
In-Reply-To: <7769af97-3dc7-f23b-c7c1-1d6b227a2f83@alum.mit.edu>
On Fri, Mar 3, 2017 at 11:43 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> It's notable that these tests grep around the filesystem, so they won't
> be applicable to future refs backends. Of course, "pack-refs" is
> intrinsically only applicable to the files backend, so for this test
> it's not surprising. But some tests could conceivably be written in a
> generic way, so that they should pass for any refs backend.
>
> Just food for thought; no need to change anything now.
I'm a bit on the fence about this. On one hand I think there is room
to backend-specific tests (and this one is more about files backend,
we just don't have any direct way of getting the backend except
through get_main_ref_store()).
On the other hand, I can see a need for verifying refs behavior across
backends. Submodule backend is unfortunately a bad fit (and probably
worktree backend too in early phase) because it cannot fully replace
files backend. lmdb does. I guess these tests will have some more
restructuring when lmdb joins the party.
I imagine we could have something like "ref_expect_success
[backend,[backend..]] <title> <body>", which makes it easier to
exercise a new backend with the same test, or we could add
backend-specific tests as well. Not sure how to do it yet (the devil
will be in the body, I think, like dealing with "git -C sub" for
submodules). Probably won't do in this series anyway.
>> +test_expect_success 'rename_refs(master, new-master)' '
>> + git rev-parse master >expected &&
>> + $RUN rename-ref refs/heads/master refs/heads/new-master &&
>> + git rev-parse new-master >actual &&
>> + test_cmp expected actual &&
>> + test_commit recreate-master
>> +'
>
> Isn't HEAD set to `refs/heads/master` prior to this test? If so, then I
> think it should become detached when you rename `refs/heads/master`. Or
> maybe it should be changed to point at `refs/heads/new-master`, I can't
> remember. In either case, it might be useful for the test to check that
> the behavior matches the status quo, so we notice if the behavior ever
> changes inadvertently.
You had me worried a bit there, that I broke something. Yes we rename
HEAD too. No it's not the backend's job. It's done separately by
builtin/branch.c. Probably a good thing because I don't the backend
should know about HEAD's special semantics. Front-end might though.
>> +test_expect_success 'delete_ref(refs/heads/foo)' '
>> + SHA1=`git rev-parse foo` &&
>> + git checkout --detach &&
>> + $RUN delete-ref refs/heads/foo $SHA1 0 &&
>> + test_must_fail git rev-parse refs/heads/foo --
>> +'
>
> The last two tests have the same name.
>
> You might also want to test these functions when the old oid is
> incorrect or when the reference is missing.
I will. But you probably noticed that I didn't cover refs behavior
extensively. I don't know this area well enough to write a conformant
test suite. But I think that's ok. We have something to start
improving now.
--
Duy
^ permalink raw reply
* [PATCH v5 03/22] config: add git_config_get_split_index()
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
This new function will be used in a following commit to know
if we want to use the split index feature or not.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
cache.h | 1 +
config.c | 10 ++++++++++
2 files changed, 11 insertions(+)
diff --git a/cache.h b/cache.h
index 80b6372cf7..03de80daae 100644
--- a/cache.h
+++ b/cache.h
@@ -1926,6 +1926,7 @@ extern int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest);
extern int git_config_get_maybe_bool(const char *key, int *dest);
extern int git_config_get_pathname(const char *key, const char **dest);
extern int git_config_get_untracked_cache(void);
+extern int git_config_get_split_index(void);
/*
* This is a hack for test programs like test-dump-untracked-cache to
diff --git a/config.c b/config.c
index 2ac1aa19b0..2a97696be7 100644
--- a/config.c
+++ b/config.c
@@ -1736,6 +1736,16 @@ int git_config_get_untracked_cache(void)
return -1; /* default value */
}
+int git_config_get_split_index(void)
+{
+ int val;
+
+ if (!git_config_get_maybe_bool("core.splitindex", &val))
+ return val;
+
+ return -1; /* default value */
+}
+
NORETURN
void git_die_config_linenr(const char *key, const char *filename, int linenr)
{
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
* [PATCH v5 01/22] config: mark an error message up for translation
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index c6b874a7bf..2ac1aa19b0 100644
--- a/config.c
+++ b/config.c
@@ -1728,8 +1728,8 @@ int git_config_get_untracked_cache(void)
if (!strcasecmp(v, "keep"))
return -1;
- error("unknown core.untrackedCache value '%s'; "
- "using 'keep' default value", v);
+ error(_("unknown core.untrackedCache value '%s'; "
+ "using 'keep' default value"), v);
return -1;
}
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
* [PATCH v5 00/22] Add configuration options for split-index
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
Goal
~~~~
We want to make it possible to use the split-index feature
automatically by just setting a new "core.splitIndex" configuration
variable to true.
This can be valuable as split-index can help significantly speed up
`git rebase` especially along with the work to libify `git apply`
that has been merged to master
(see https://github.com/git/git/commit/81358dc238372793b1590efa149cc1581d1fbd98)
and is now in v2.11.
Design
~~~~~~
The design is similar as the previous work that introduced
"core.untrackedCache".
The new "core.splitIndex" configuration option can be either true,
false or undefined which is the default.
When it is true, the split index is created, if it does not already
exists, when the index is read. When it is false, the split index is
removed if it exists, when the index is read. Otherwise it is left as
is.
Along with this new configuration variable, the two following options
are also introduced:
- splitIndex.maxPercentChange
This is to avoid having too many changes accumulating in the split
index while in split index mode. The git-update-index
documentation says:
If split-index mode is already enabled and `--split-index` is
given again, all changes in $GIT_DIR/index are pushed back to
the shared index file.
but it is probably better to not expect the user to think about it
and to have a mechanism that pushes back all changes to the shared
index file automatically when some threshold is reached.
The default threshold is when the number of entries in the split
index file reaches 20% of the number of entries in the shared
index file. The new "splitIndex.maxPercentChange" config option
lets people tweak this value.
- splitIndex.sharedIndexExpire
To make sure that old sharedindex files are eventually removed
when a new one has been created, we "touch" the shared index file
every time a split index file using the shared index file is
either created or read from. Then we can delete shared indexes
with an mtime older than two weeks (by default), when we create a
new shared index file. The new "splitIndex.sharedIndexExpire"
config option lets people tweak this grace period.
This idea was suggested by Duy in:
https://public-inbox.org/git/CACsJy8BqMFASHf5kJgUh+bd7XG98CafNydE964VJyPXz-emEvA@mail.gmail.com/
and after some experiments, I agree that it is much simpler than
what I thought could be done during our discussion.
Junio also thinks that we have to do "time-based GC" in:
https://public-inbox.org/git/xmqqeg33ccjj.fsf@gitster.mtv.corp.google.com/
Note that this patch series doesn't address a leak when removing a
split-index, but Duy wrote that he has a patch to fix this leak:
https://public-inbox.org/git/CACsJy8AisF2ZVs7JdnVFp5wdskkbVQQQ=DBq5UzE1MOsCfBMtQ@mail.gmail.com/
Highlevel view of the patches in the series
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are very few and very small differences between this patch
series and the v4 patch series sent a few weeks ago. The small
differences are all in patches 15/22 and 17/22. The other patches are
the same as in v4.
Except for patch 1/22 and 2/22, there are 3 big steps, one for each
new configuration variable introduced.
- Patch 1/22 marks a message for translation and can be applied
separately.
- Patch 2/22 improves the existing indentation style of t1700 by
using different here document style.
Step 1 is:
- Patches 3/22 to 6/22 introduce the functions that are reading
the "core.splitIndex" configuration variable and tweaking the
split index depending on its value.
- Patch 7/22 adds a few tests for the new feature.
- Patches 8/22 and 9/22 add some documentation for the new
feature.
Step 2 is:
- Patches 10/22 and 11/22 introduce the functions that are reading
the "splitIndex.maxPercentChange" configuration variable and
regenerating a new shared index file depending on its value.
- Patch 12/22 adds a few tests for the new feature.
- Patch 13/22 add some documentation for the new feature.
Step 3 is:
- Patches 14/22 to 17/22 introduce the functions that are reading
the "splitIndex.sharedIndexExpire" configuration variable and
expiring old shared index files depending on its value.
In patch 15/22 a warning message starts with "could" instead of
"Could" as suggested by Junio.
In patch 17/22, can_delete_shared_index() has been renamed
should_delete_shared_index() and error_errno() has been changed
to warning_errno() as suggested by Junio.
- Patch 18/22 adds a few tests for the new feature.
- Patches 19/22 and 20/22 update the mtime of the shared index
file when a split index based on the shared index file is read
from. 19/22 is a refactoring to make the actual change in 20/22
easier.
- Patches 21/22 and 22/22 add some documentation for the new
feature.
Links
~~~~~
This patch series is also available here:
https://github.com/chriscool/git/commits/config-split-index
The previous versions were:
RFC: https://github.com/chriscool/git/commits/config-split-index7
v1: https://github.com/chriscool/git/commits/config-split-index72
v2: https://github.com/chriscool/git/commits/config-split-index99
v3: https://github.com/chriscool/git/commits/config-split-index102
v4: https://github.com/chriscool/git/commits/config-split-index121
On the mailing list the related patch series and discussions were:
RFC: https://public-inbox.org/git/20160711172254.13439-1-chriscool@tuxfamily.org/
v1: https://public-inbox.org/git/20161023092648.12086-1-chriscool@tuxfamily.org/
v2: https://public-inbox.org/git/20161217145547.11748-1-chriscool@tuxfamily.org/
v3: https://public-inbox.org/git/20161226102222.17150-1-chriscool@tuxfamily.org/
v4: https://public-inbox.org/git/20170227180019.18666-1-chriscool@tuxfamily.org/
Christian Couder (22):
config: mark an error message up for translation
t1700: change here document style
config: add git_config_get_split_index()
split-index: add {add,remove}_split_index() functions
read-cache: add and then use tweak_split_index()
update-index: warn in case of split-index incoherency
t1700: add tests for core.splitIndex
Documentation/config: add information for core.splitIndex
Documentation/git-update-index: talk about core.splitIndex config var
config: add git_config_get_max_percent_split_change()
read-cache: regenerate shared index if necessary
t1700: add tests for splitIndex.maxPercentChange
Documentation/config: add splitIndex.maxPercentChange
sha1_file: make check_and_freshen_file() non static
read-cache: touch shared index files when used
config: add git_config_get_expiry() from gc.c
read-cache: unlink old sharedindex files
t1700: test shared index file expiration
read-cache: refactor read_index_from()
read-cache: use freshen_shared_index() in read_index_from()
Documentation/config: add splitIndex.sharedIndexExpire
Documentation/git-update-index: explain splitIndex.*
Documentation/config.txt | 29 ++++
Documentation/git-update-index.txt | 43 ++++-
builtin/gc.c | 18 +--
builtin/update-index.c | 25 +--
cache.h | 8 +
config.c | 42 ++++-
read-cache.c | 157 ++++++++++++++++--
sha1_file.c | 2 +-
split-index.c | 22 +++
split-index.h | 2 +
t/t1700-split-index.sh | 324 +++++++++++++++++++++++++++----------
11 files changed, 540 insertions(+), 132 deletions(-)
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply
* [PATCH v5 05/22] read-cache: add and then use tweak_split_index()
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
This will make us use the split-index feature or not depending
on the value of the "core.splitIndex" config variable.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
read-cache.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index 9054369dd0..99bc274b8d 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1558,10 +1558,27 @@ static void tweak_untracked_cache(struct index_state *istate)
}
}
+static void tweak_split_index(struct index_state *istate)
+{
+ switch (git_config_get_split_index()) {
+ case -1: /* unset: do nothing */
+ break;
+ case 0: /* false */
+ remove_split_index(istate);
+ break;
+ case 1: /* true */
+ add_split_index(istate);
+ break;
+ default: /* unknown value: do nothing */
+ break;
+ }
+}
+
static void post_read_index_from(struct index_state *istate)
{
check_ce_order(istate);
tweak_untracked_cache(istate);
+ tweak_split_index(istate);
}
/* remember to discard_cache() before reading a different cache! */
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
* [PATCH v5 08/22] Documentation/config: add information for core.splitIndex
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/config.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 47603f5484..f102879261 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -334,6 +334,10 @@ core.trustctime::
crawlers and some backup systems).
See linkgit:git-update-index[1]. True by default.
+core.splitIndex::
+ If true, the split-index feature of the index will be used.
+ See linkgit:git-update-index[1]. False by default.
+
core.untrackedCache::
Determines what to do about the untracked cache feature of the
index. It will be kept, if this variable is unset or set to
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
* [PATCH v5 02/22] t1700: change here document style
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
This improves test indentation by getting rid of the outdated
here document style.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t1700-split-index.sh | 170 ++++++++++++++++++++++++-------------------------
1 file changed, 85 insertions(+), 85 deletions(-)
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index 6096f2c630..5ea227e6a1 100755
--- a/t/t1700-split-index.sh
+++ b/t/t1700-split-index.sh
@@ -19,12 +19,12 @@ test_expect_success 'enable split index' '
own=8299b0bcd1ac364e5f1d7768efb62fa2da79a339
base=39d890139ee5356c7ef572216cebcd27aa41f9df
fi &&
- cat >expect <<EOF &&
-own $own
-base $base
-replacements:
-deletions:
-EOF
+ cat >expect <<-EOF &&
+ own $own
+ base $base
+ replacements:
+ deletions:
+ EOF
test_cmp expect actual
'
@@ -32,51 +32,51 @@ test_expect_success 'add one file' '
: >one &&
git update-index --add one &&
git ls-files --stage >ls-files.actual &&
- cat >ls-files.expect <<EOF &&
-100644 $EMPTY_BLOB 0 one
-EOF
+ cat >ls-files.expect <<-EOF &&
+ 100644 $EMPTY_BLOB 0 one
+ EOF
test_cmp ls-files.expect ls-files.actual &&
test-dump-split-index .git/index | sed "/^own/d" >actual &&
- cat >expect <<EOF &&
-base $base
-100644 $EMPTY_BLOB 0 one
-replacements:
-deletions:
-EOF
+ cat >expect <<-EOF &&
+ base $base
+ 100644 $EMPTY_BLOB 0 one
+ replacements:
+ deletions:
+ EOF
test_cmp expect actual
'
test_expect_success 'disable split index' '
git update-index --no-split-index &&
git ls-files --stage >ls-files.actual &&
- cat >ls-files.expect <<EOF &&
-100644 $EMPTY_BLOB 0 one
-EOF
+ cat >ls-files.expect <<-EOF &&
+ 100644 $EMPTY_BLOB 0 one
+ EOF
test_cmp ls-files.expect ls-files.actual &&
BASE=$(test-dump-split-index .git/index | grep "^own" | sed "s/own/base/") &&
test-dump-split-index .git/index | sed "/^own/d" >actual &&
- cat >expect <<EOF &&
-not a split index
-EOF
+ cat >expect <<-EOF &&
+ not a split index
+ EOF
test_cmp expect actual
'
test_expect_success 'enable split index again, "one" now belongs to base index"' '
git update-index --split-index &&
git ls-files --stage >ls-files.actual &&
- cat >ls-files.expect <<EOF &&
-100644 $EMPTY_BLOB 0 one
-EOF
+ cat >ls-files.expect <<-EOF &&
+ 100644 $EMPTY_BLOB 0 one
+ EOF
test_cmp ls-files.expect ls-files.actual &&
test-dump-split-index .git/index | sed "/^own/d" >actual &&
- cat >expect <<EOF &&
-$BASE
-replacements:
-deletions:
-EOF
+ cat >expect <<-EOF &&
+ $BASE
+ replacements:
+ deletions:
+ EOF
test_cmp expect actual
'
@@ -84,18 +84,18 @@ test_expect_success 'modify original file, base index untouched' '
echo modified >one &&
git update-index one &&
git ls-files --stage >ls-files.actual &&
- cat >ls-files.expect <<EOF &&
-100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0 one
-EOF
+ cat >ls-files.expect <<-EOF &&
+ 100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0 one
+ EOF
test_cmp ls-files.expect ls-files.actual &&
test-dump-split-index .git/index | sed "/^own/d" >actual &&
- q_to_tab >expect <<EOF &&
-$BASE
-100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0Q
-replacements: 0
-deletions:
-EOF
+ q_to_tab >expect <<-EOF &&
+ $BASE
+ 100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0Q
+ replacements: 0
+ deletions:
+ EOF
test_cmp expect actual
'
@@ -103,54 +103,54 @@ test_expect_success 'add another file, which stays index' '
: >two &&
git update-index --add two &&
git ls-files --stage >ls-files.actual &&
- cat >ls-files.expect <<EOF &&
-100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0 one
-100644 $EMPTY_BLOB 0 two
-EOF
+ cat >ls-files.expect <<-EOF &&
+ 100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0 one
+ 100644 $EMPTY_BLOB 0 two
+ EOF
test_cmp ls-files.expect ls-files.actual &&
test-dump-split-index .git/index | sed "/^own/d" >actual &&
- q_to_tab >expect <<EOF &&
-$BASE
-100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0Q
-100644 $EMPTY_BLOB 0 two
-replacements: 0
-deletions:
-EOF
+ q_to_tab >expect <<-EOF &&
+ $BASE
+ 100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0Q
+ 100644 $EMPTY_BLOB 0 two
+ replacements: 0
+ deletions:
+ EOF
test_cmp expect actual
'
test_expect_success 'remove file not in base index' '
git update-index --force-remove two &&
git ls-files --stage >ls-files.actual &&
- cat >ls-files.expect <<EOF &&
-100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0 one
-EOF
+ cat >ls-files.expect <<-EOF &&
+ 100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0 one
+ EOF
test_cmp ls-files.expect ls-files.actual &&
test-dump-split-index .git/index | sed "/^own/d" >actual &&
- q_to_tab >expect <<EOF &&
-$BASE
-100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0Q
-replacements: 0
-deletions:
-EOF
+ q_to_tab >expect <<-EOF &&
+ $BASE
+ 100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0Q
+ replacements: 0
+ deletions:
+ EOF
test_cmp expect actual
'
test_expect_success 'remove file in base index' '
git update-index --force-remove one &&
git ls-files --stage >ls-files.actual &&
- cat >ls-files.expect <<EOF &&
-EOF
+ cat >ls-files.expect <<-EOF &&
+ EOF
test_cmp ls-files.expect ls-files.actual &&
test-dump-split-index .git/index | sed "/^own/d" >actual &&
- cat >expect <<EOF &&
-$BASE
-replacements:
-deletions: 0
-EOF
+ cat >expect <<-EOF &&
+ $BASE
+ replacements:
+ deletions: 0
+ EOF
test_cmp expect actual
'
@@ -158,18 +158,18 @@ test_expect_success 'add original file back' '
: >one &&
git update-index --add one &&
git ls-files --stage >ls-files.actual &&
- cat >ls-files.expect <<EOF &&
-100644 $EMPTY_BLOB 0 one
-EOF
+ cat >ls-files.expect <<-EOF &&
+ 100644 $EMPTY_BLOB 0 one
+ EOF
test_cmp ls-files.expect ls-files.actual &&
test-dump-split-index .git/index | sed "/^own/d" >actual &&
- cat >expect <<EOF &&
-$BASE
-100644 $EMPTY_BLOB 0 one
-replacements:
-deletions: 0
-EOF
+ cat >expect <<-EOF &&
+ $BASE
+ 100644 $EMPTY_BLOB 0 one
+ replacements:
+ deletions: 0
+ EOF
test_cmp expect actual
'
@@ -177,26 +177,26 @@ test_expect_success 'add new file' '
: >two &&
git update-index --add two &&
git ls-files --stage >actual &&
- cat >expect <<EOF &&
-100644 $EMPTY_BLOB 0 one
-100644 $EMPTY_BLOB 0 two
-EOF
+ cat >expect <<-EOF &&
+ 100644 $EMPTY_BLOB 0 one
+ 100644 $EMPTY_BLOB 0 two
+ EOF
test_cmp expect actual
'
test_expect_success 'unify index, two files remain' '
git update-index --no-split-index &&
git ls-files --stage >ls-files.actual &&
- cat >ls-files.expect <<EOF &&
-100644 $EMPTY_BLOB 0 one
-100644 $EMPTY_BLOB 0 two
-EOF
+ cat >ls-files.expect <<-EOF &&
+ 100644 $EMPTY_BLOB 0 one
+ 100644 $EMPTY_BLOB 0 two
+ EOF
test_cmp ls-files.expect ls-files.actual &&
test-dump-split-index .git/index | sed "/^own/d" >actual &&
- cat >expect <<EOF &&
-not a split index
-EOF
+ cat >expect <<-EOF &&
+ not a split index
+ EOF
test_cmp expect actual
'
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
* [PATCH v5 21/22] Documentation/config: add splitIndex.sharedIndexExpire
From: Christian Couder @ 2017-03-06 9:42 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/config.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b64aa7db2d..2afd5d982b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2864,6 +2864,18 @@ splitIndex.maxPercentChange::
than 20 percent of the total number of entries.
See linkgit:git-update-index[1].
+splitIndex.sharedIndexExpire::
+ When the split index feature is used, shared index files that
+ were not modified since the time this variable specifies will
+ be removed when a new shared index file is created. The value
+ "now" expires all entries immediately, and "never" suppresses
+ expiration altogether.
+ The default value is "2.weeks.ago".
+ Note that a shared index file is considered modified (for the
+ purpose of expiration) each time a new split-index file is
+ created based on it.
+ See linkgit:git-update-index[1].
+
status.relativePaths::
By default, linkgit:git-status[1] shows paths relative to the
current directory. Setting this variable to `false` shows paths
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
* [PATCH v5 04/22] split-index: add {add,remove}_split_index() functions
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
Also use the functions in cmd_update_index() in
builtin/update-index.c.
These functions will be used in a following commit to tweak
our use of the split-index feature depending on the setting
of a configuration variable.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin/update-index.c | 18 ++++++------------
split-index.c | 22 ++++++++++++++++++++++
split-index.h | 2 ++
3 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index d530e89368..24fdadfa4b 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1099,18 +1099,12 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
}
if (split_index > 0) {
- init_split_index(&the_index);
- the_index.cache_changed |= SPLIT_INDEX_ORDERED;
- } else if (!split_index && the_index.split_index) {
- /*
- * can't discard_split_index(&the_index); because that
- * will destroy split_index->base->cache[], which may
- * be shared with the_index.cache[]. So yeah we're
- * leaking a bit here.
- */
- the_index.split_index = NULL;
- the_index.cache_changed |= SOMETHING_CHANGED;
- }
+ if (the_index.split_index)
+ the_index.cache_changed |= SPLIT_INDEX_ORDERED;
+ else
+ add_split_index(&the_index);
+ } else if (!split_index)
+ remove_split_index(&the_index);
switch (untracked_cache) {
case UC_UNSPECIFIED:
diff --git a/split-index.c b/split-index.c
index 615f4cac05..f519e60f87 100644
--- a/split-index.c
+++ b/split-index.c
@@ -317,3 +317,25 @@ void replace_index_entry_in_base(struct index_state *istate,
istate->split_index->base->cache[new->index - 1] = new;
}
}
+
+void add_split_index(struct index_state *istate)
+{
+ if (!istate->split_index) {
+ init_split_index(istate);
+ istate->cache_changed |= SPLIT_INDEX_ORDERED;
+ }
+}
+
+void remove_split_index(struct index_state *istate)
+{
+ if (istate->split_index) {
+ /*
+ * can't discard_split_index(&the_index); because that
+ * will destroy split_index->base->cache[], which may
+ * be shared with the_index.cache[]. So yeah we're
+ * leaking a bit here.
+ */
+ istate->split_index = NULL;
+ istate->cache_changed |= SOMETHING_CHANGED;
+ }
+}
diff --git a/split-index.h b/split-index.h
index c1324f521a..df91c1bda8 100644
--- a/split-index.h
+++ b/split-index.h
@@ -31,5 +31,7 @@ void merge_base_index(struct index_state *istate);
void prepare_to_write_split_index(struct index_state *istate);
void finish_writing_split_index(struct index_state *istate);
void discard_split_index(struct index_state *istate);
+void add_split_index(struct index_state *istate);
+void remove_split_index(struct index_state *istate);
#endif
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
* [PATCH v5 12/22] t1700: add tests for splitIndex.maxPercentChange
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t1700-split-index.sh | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index 9d7c01c3e1..00a64bed97 100755
--- a/t/t1700-split-index.sh
+++ b/t/t1700-split-index.sh
@@ -254,4 +254,76 @@ test_expect_success 'set core.splitIndex config variable to false' '
test_cmp expect actual
'
+test_expect_success 'set core.splitIndex config variable to true' '
+ git config core.splitIndex true &&
+ : >three &&
+ git update-index --add three &&
+ BASE=$(test-dump-split-index .git/index | grep "^base") &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<-EOF &&
+ $BASE
+ replacements:
+ deletions:
+ EOF
+ test_cmp expect actual &&
+ : >four &&
+ git update-index --add four &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<-EOF &&
+ $BASE
+ 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 four
+ replacements:
+ deletions:
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'check behavior with splitIndex.maxPercentChange unset' '
+ git config --unset splitIndex.maxPercentChange &&
+ : >five &&
+ git update-index --add five &&
+ BASE=$(test-dump-split-index .git/index | grep "^base") &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<-EOF &&
+ $BASE
+ replacements:
+ deletions:
+ EOF
+ test_cmp expect actual &&
+ : >six &&
+ git update-index --add six &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<-EOF &&
+ $BASE
+ 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 six
+ replacements:
+ deletions:
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'check splitIndex.maxPercentChange set to 0' '
+ git config splitIndex.maxPercentChange 0 &&
+ : >seven &&
+ git update-index --add seven &&
+ BASE=$(test-dump-split-index .git/index | grep "^base") &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<-EOF &&
+ $BASE
+ replacements:
+ deletions:
+ EOF
+ test_cmp expect actual &&
+ : >eight &&
+ git update-index --add eight &&
+ BASE=$(test-dump-split-index .git/index | grep "^base") &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<-EOF &&
+ $BASE
+ replacements:
+ deletions:
+ EOF
+ test_cmp expect actual
+'
+
test_done
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
* [PATCH v5 16/22] config: add git_config_get_expiry() from gc.c
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
This function will be used in a following commit to get the expiration
time of the shared index files from the config, and it is generic
enough to be put in "config.c".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin/gc.c | 18 +++---------------
cache.h | 3 +++
config.c | 13 +++++++++++++
3 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index a2b9e8924e..56ab74f6ba 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -64,17 +64,6 @@ static void report_pack_garbage(unsigned seen_bits, const char *path)
string_list_append(&pack_garbage, path);
}
-static void git_config_date_string(const char *key, const char **output)
-{
- if (git_config_get_string_const(key, output))
- return;
- if (strcmp(*output, "now")) {
- unsigned long now = approxidate("now");
- if (approxidate(*output) >= now)
- git_die_config(key, _("Invalid %s: '%s'"), key, *output);
- }
-}
-
static void process_log_file(void)
{
struct stat st;
@@ -131,10 +120,9 @@ static void gc_config(void)
git_config_get_int("gc.auto", &gc_auto_threshold);
git_config_get_int("gc.autopacklimit", &gc_auto_pack_limit);
git_config_get_bool("gc.autodetach", &detach_auto);
- git_config_date_string("gc.pruneexpire", &prune_expire);
- git_config_date_string("gc.worktreepruneexpire", &prune_worktrees_expire);
- git_config_date_string("gc.logexpiry", &gc_log_expire);
-
+ git_config_get_expiry("gc.pruneexpire", &prune_expire);
+ git_config_get_expiry("gc.worktreepruneexpire", &prune_worktrees_expire);
+ git_config_get_expiry("gc.logexpiry", &gc_log_expire);
git_config(git_default_config, NULL);
}
diff --git a/cache.h b/cache.h
index a35e9d5187..65ab507a76 100644
--- a/cache.h
+++ b/cache.h
@@ -1932,6 +1932,9 @@ extern int git_config_get_untracked_cache(void);
extern int git_config_get_split_index(void);
extern int git_config_get_max_percent_split_change(void);
+/* This dies if the configured or default date is in the future */
+extern int git_config_get_expiry(const char *key, const char **output);
+
/*
* This is a hack for test programs like test-dump-untracked-cache to
* ensure that they do not modify the untracked cache when reading it.
diff --git a/config.c b/config.c
index 35b6f02960..f20d7d88f7 100644
--- a/config.c
+++ b/config.c
@@ -1712,6 +1712,19 @@ int git_config_get_pathname(const char *key, const char **dest)
return ret;
}
+int git_config_get_expiry(const char *key, const char **output)
+{
+ int ret = git_config_get_string_const(key, output);
+ if (ret)
+ return ret;
+ if (strcmp(*output, "now")) {
+ unsigned long now = approxidate("now");
+ if (approxidate(*output) >= now)
+ git_die_config(key, _("Invalid %s: '%s'"), key, *output);
+ }
+ return ret;
+}
+
int git_config_get_untracked_cache(void)
{
int val = -1;
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
* [PATCH v5 07/22] t1700: add tests for core.splitIndex
From: Christian Couder @ 2017-03-06 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Ramsay Jones, Jeff King,
Christian Couder
In-Reply-To: <20170306094203.28250-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t1700-split-index.sh | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index 5ea227e6a1..aa2aff1778 100755
--- a/t/t1700-split-index.sh
+++ b/t/t1700-split-index.sh
@@ -216,4 +216,41 @@ test_expect_success 'rev-parse --shared-index-path' '
)
'
+test_expect_success 'set core.splitIndex config variable to true' '
+ git config core.splitIndex true &&
+ : >three &&
+ git update-index --add three &&
+ git ls-files --stage >ls-files.actual &&
+ cat >ls-files.expect <<-EOF &&
+ 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 one
+ 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 three
+ 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 two
+ EOF
+ test_cmp ls-files.expect ls-files.actual &&
+ BASE=$(test-dump-split-index .git/index | grep "^base") &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<-EOF &&
+ $BASE
+ replacements:
+ deletions:
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'set core.splitIndex config variable to false' '
+ git config core.splitIndex false &&
+ git update-index --force-remove three &&
+ git ls-files --stage >ls-files.actual &&
+ cat >ls-files.expect <<-EOF &&
+ 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 one
+ 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 two
+ EOF
+ test_cmp ls-files.expect ls-files.actual &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<-EOF &&
+ not a split index
+ EOF
+ test_cmp expect actual
+'
+
test_done
--
2.12.0.206.g74921e51d6.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox