* [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 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 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 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 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
* 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
* 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
* 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: 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
* 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: 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
* 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: 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: 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: 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: [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: [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: 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: [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 0/4] Shallow clones with on-demand fetch
From: Jonathan Tan @ 2017-03-06 19:16 UTC (permalink / raw)
To: Mark Thomas, git; +Cc: peartben
In-Reply-To: <20170304191901.9622-1-markbt@efaref.net>
On 03/04/2017 11:18 AM, Mark Thomas wrote:
> I was inspired a bit by Microsoft's announcement of their Git VFS. I
> saw that people have talked in the past about making git fetch objects
> from remotes as they are needed, and decided to give it a try.
For reference, one such conversation is [1]. (cc-ing Ben Peart also)
> The patch series adds a "--on-demand" option to git clone, which, when
> used in conjunction with the existing shallow clone operations, clones
> the full history of the repository's commits, but only the files that
> would be included in the shallow clone.
>
> When a file that is missing is required, git requests the file on-demand
> from the remote, via a new 'upload-file' service.
A reachability check (of the blob) might be a good idea. The current Git
implementation already supports fetching a blob (perhaps a bug) but has
problems with reachability calculations that I tried to fix in [2], but
found some bugs that weren't easily fixable.
As I said in [2], I think that proper fetching of blobs on demand is a
prerequisite to any sort of missing object tolerance (like your
on-demand clones), so I haven't thought much about the topics in the
rest of your patch set.
[1] <20170113155253.1644-1-benpeart@microsoft.com> (you can search for
emails by Message ID in online archives like
https://public-inbox.org/git if you don't already have them)
[2] <cover.1487984670.git.jonathantanmy@google.com>
^ permalink raw reply
* [Request for Documentation] Differentiate signed (commits/tags/pushes)
From: Stefan Beller @ 2017-03-06 19:59 UTC (permalink / raw)
To: tom, Matthieu Moy, git@vger.kernel.org, Junio C Hamano
When discussing migrating to a new hashing function, I tried to learn
about the subtleties of the different things that can be gpg-signed in
Git.
What is the difference between signed commits and tags?
(Not from a technical perspective, but for the end user)
Both of them certify that a given tree is the desired
content for your repository, but git-tag seems to be designed for
conveying a trusted state to collaborators, whereas git-commit
is primarily designed to just record a state.
So in which case would I want to use a signed commit?
(which then overlaps with signed pushes)
A signed push can certify that a given payload (consisting
of multiple commits on possibly multiple branches) was transmitted
to a remote, which can be recorded by the remote as e.g. a proof
of work.
The man page of git-commit doesn't discuss gpg signing at all,
git-tag has some discussion on how to properly use tags. Maybe
there we could have a discussion on when not to use tags, but
rather signed commits?
Off list I was told gpg-signed commits are a "checkbox feature",
i.e. no real world workflow would actually use it. (That's a bold
statement, someone has to use it as there was enough interest
to implement it, no?)
Thanks,
Stefan
^ permalink raw reply
* Re: RFC: Another proposed hash function transition plan
From: Brandon Williams @ 2017-03-06 19:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jonathan Tan, Jeff King, Jonathan Nieder, Git Mailing List,
Stefan Beller
In-Reply-To: <CA+55aFxj7Vtwac64RfAz_u=U4tob4Xg+2pDBDFNpJdmgaTCmxA@mail.gmail.com>
On 03/06, Linus Torvalds wrote:
> 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?
I'll agree that the "hash" "nohash" bit isn't my favorite and is really
only there to address the signing of tags/commits in this new non-sha1
world. I'm inclined to take a closer look at Jeff's suggestion which
simply has a signature for the hash that the signer cares about.
I don't know if keeping around the SHA1 for every object buys you all
that much. It would add an additional layer of protection but you would
also need to compute the SHA1 for each object indefinitely (assuming you
include the SHA1 in new objects and not just converted objects). The
hope would be that at some point you could not worry about SHA1 at all.
That may be difficult for projects with long history with commit msgs
which reference SHA1's of other commits (if you wanted to look up the
referenced commit, for example), but projects started in the new
non-sha1 world shouldn't have to ever compute a sha1.
Also, during this transition phase you would still need to maintain the
sha1<->sha256 translation table to make looking up objects by their sha1
name in a sha256 repo fast. Otherwise I think it would take a
non-trivial amount of time to search a sha256 repo for a sha1 name. So
if you do include the sha1 in the new object format then you would end
up with some duplicate information, which isn't the end of the world.
--
Brandon Williams
^ permalink raw reply
* Re: [RFC 0/4] Shallow clones with on-demand fetch
From: Stefan Beller @ 2017-03-06 20:01 UTC (permalink / raw)
To: Jonathan Tan; +Cc: Mark Thomas, git@vger.kernel.org, Ben Peart
In-Reply-To: <c8788f30-263b-c96a-239d-940743b96b53@google.com>
On Mon, Mar 6, 2017 at 11:16 AM, Jonathan Tan <jonathantanmy@google.com> wrote:
> [1] <20170113155253.1644-1-benpeart@microsoft.com> (you can search for
> emails by Message ID in online archives like https://public-inbox.org/git if
> you don't already have them)
Not just search, but the immediate lookup is
https://public-inbox.org/git/<message-id>
so
https://public-inbox.org/git/20170113155253.1644-1-benpeart@microsoft.com
> [2] <cover.1487984670.git.jonathantanmy@google.com>
and
https://public-inbox.org/git/cover.1487984670.git.jonathantanmy@google.com
^ permalink raw reply
* Re: bisect-helper: we do not bisect --objects
From: Junio C Hamano @ 2017-03-06 20:22 UTC (permalink / raw)
To: Philip Oakley; +Cc: git, Christian Couder
In-Reply-To: <5556D465CF3A42C8B117759A170FE3A7@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> The study of human error is quite interesting....
Yes ;-)
^ permalink raw reply
* Re: bisect-helper: we do not bisect --objects
From: Junio C Hamano @ 2017-03-06 20:21 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <CAP8UFD0tzH+QiNM2BMhe9qcKdD0rP9T=Ry94=EPV+=d+7cdLfQ@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> I think I just copy pasted the code from cmd_rev_list() in
> builtin-rev-list.c and probably didn't realize that revs->tree_objects
> would always be false.
>
> Thanks for spotting this and removing the dead code.
Thanks for a quick confirmation. Just FYI I was looking at this code
because I was trying to assess how involved it would be to teach the
code to do a bisection only on the first-parent chain.
^ permalink raw reply
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