Re: [RFC PATCH] rev-parse: add --show-superproject-working-tree

Junio C Hamano writes: >> - If our submodule is bound at path sub/dir in the superproject, >>the relative-path thing above would get "dir" and this ls-tree >>ends up asking what is at "dir", but the question you really want >>to ask is what is at "sub/dir", isn't

Re: [RFC PATCH] rev-parse: add --show-superproject-working-tree

Junio C Hamano writes: >> +dirname = relative_path(xgetcwd(), one_up, ); > > So, the idea is we start at the root level of the current project's > working tree, and we go up one level, then we know the last component > of the path our submodule is bound at in the

Re: [RFC PATCH] rev-parse: add --show-superproject-working-tree

Stefan Beller writes: > diff --git a/submodule.c b/submodule.c > index 3b98766a6b..a63aef2c6b 100644 > --- a/submodule.c > +++ b/submodule.c > @@ -1514,3 +1514,90 @@ void absorb_git_dir_into_superproject(const char > *prefix, > strbuf_release(); > } > }

[RFC PATCH] rev-parse: add --show-superproject-working-tree

Signed-off-by: Stefan Beller --- Marking this as RFC as documentation and tests are missing. builtin/rev-parse.c | 7 + submodule.c | 87 + submodule.h | 8 + 3 files changed, 102 insertions(+)

[RFCv7 PATCH 00/18] Checkout aware of Submodules!

previous work: https://public-inbox.org/git/20170302004759.27852-1-sbel...@google.com https://public-inbox.org/git/20161203003022.29797-1-sbel...@google.com/ v7: * addressed Erics comment by fixing the bashism in t/lib-submodule-update.sh diff to v6: diff --git a/t/lib-submodule-update.sh

[PATCH 09/18] update submodules: add a config option to determine if submodules are updated

In later patches we introduce the options and flag for commands that modify the working directory, e.g. git-checkout. Have a central place to store such settings whether we want to update a submodule. Signed-off-by: Stefan Beller --- submodule.c | 6 ++ submodule.h | 1

Re: [PATCH] blame: draft of line format

On Tue, Jan 31, 2017 at 1:41 PM, Jeff King wrote: > On Mon, Jan 30, 2017 at 08:28:30PM -0600, Edmundo Carmona Antoranz wrote: > >> +static void pretty_info(char* revid, struct blame_entry *ent, struct strbuf >> *rev_buffer) >> +{ >> + struct pretty_print_context ctx = {0}; >>

Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)

On Mon, Mar 6, 2017 at 4:08 PM, Junio C Hamano wrote: > Stefan Beller writes: > >>> "tag -s" also has the benefit of being retroactive. You can create >>> commit, think about it for a week and then later tag it. And ask >>> others to also tag the same

Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)

Junio C Hamano writes: > Stefan Beller writes: > >> What is the difference between signed commits and tags? >> (Not from a technical perspective, but for the end user) > ... >> A signed push can certify that a given payload (consisting >> of multiple

[PATCH 06/18] make is_submodule_populated gently

We need the gentle version in a later patch. As we have just one caller, migrate the caller. Signed-off-by: Stefan Beller --- builtin/grep.c | 2 +- submodule.c| 7 ++- submodule.h| 8 +++- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git

Re: [PATCH v5 1/1] config: add conditional include

Being late to the review party here. > +static int include_condition_is_true(const char *cond, size_t cond_len) > +{ ... > + > + error(_("unrecognized include condition: %.*s"), (int)cond_len, cond); > + /* unknown conditionals are always false */ > + return 0; > +} Thanks for

Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)

Jakub Narębski writes: > Also from what I remember signed commits came before mergetags, that > is the result of merging a signed tag (storing the signature of > one of parents of the merge commit to not pollute tag namespace). > > And this workflow, from what I know, is quite

Re: RFC: Another proposed hash function transition plan

On Mon, Mar 06, 2017 at 03:40:30PM -0800, Jonathan Nieder wrote: > David Lang wrote: > > >> Translation table > >> ~ > >> A fast bidirectional mapping between sha1-names and sha256-names of > >> all local objects in the repository is kept on disk. The exact format > >> of that

RFC v3: Another proposed hash function transition plan

Linus Torvalds wrote: > On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder 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. Thanks

Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)

Stefan Beller writes: >> "tag -s" also has the benefit of being retroactive. You can create >> commit, think about it for a week and then later tag it. And ask >> others to also tag the same one. You cannot do so with "commit -s". > > ok, so there is *no* advantage of

Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)

W dniu 06.03.2017 o 23:13, Junio C Hamano pisze: > Stefan Beller writes: > >> What is the difference between signed commits and tags? >> (Not from a technical perspective, but for the end user) [...] >> Off list I was told gpg-signed commits are a "checkbox feature", >> i.e.

Re: RFC: Another proposed hash function transition plan

David Lang wrote: >> Translation table >> ~ >> A fast bidirectional mapping between sha1-names and sha256-names of >> all local objects in the repository is kept on disk. The exact format >> of that mapping is to be determined. >> >> All operations that make new objects (e.g.,

[RFC PATCH] grep: fix bug when recursing with relative pathspec

When using the --recurse-submodules flag with a relative pathspec which includes "..", an error is produced inside the child process spawned for a submodule. When creating the pathspec struct in the child, the ".." is interpreted to mean "go up a directory" which causes an error stating that the

Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)

On Mon, Mar 6, 2017 at 2:13 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> What is the difference between signed commits and tags? >> (Not from a technical perspective, but for the end user) > > When you "commit -s", you are signing the bytes in the

Re: Server-side hooks on non-bare repository

Hi Junio, Thanks for taking the time to reply. I apologize if there was a misunderstanding in my previous email; I'm relatively new to dealing with some of the more advanced features of git, and did not describe my situation as clearly as possible. I am using the pre-receive hook to determine

Re: [PATCH 03/18] lib-submodule-update: teach test_submodule_content the -C flag

On Wed, Mar 1, 2017 at 6:11 PM, Eric Wong wrote: > Stefan Beller wrote: >> test_submodule_content () { >> + if test "$1" == "-C" > > Use a single '=' for portability in sh. It's also a good idea > to prefix variables with 'x' or some such, since "$1"

Re: What's cooking in git.git (Mar 2017, #02; Fri, 3)

Lars Schneider writes: >> On 04 Mar 2017, at 00:26, Junio C Hamano wrote: >> >> >> * ls/filter-process-delayed (2017-01-08) 1 commit >> . convert: add "status=delayed" to filter process protocol >> >> Ejected, as does not build when merged to

Re: [PATCH 03/18] lib-submodule-update: teach test_submodule_content the -C flag

Stefan Beller writes: > Signed-off-by: Stefan Beller > --- > t/lib-submodule-update.sh | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh > index c0d6325133..00128f28b5 100755 > ---

Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)

Stefan Beller writes: > What is the difference between signed commits and tags? > (Not from a technical perspective, but for the end user) When you "commit -s", you are signing the bytes in the commit object, which means that you are attesting the fact that the tree you

[PATCH 08/18] update submodules: add submodule config parsing

Similar to b33a15b08 (push: add recurseSubmodules config option, 2015-11-17) and 027771fcb1 (submodule: allow erroneous values for the fetchRecurseSubmodules option, 2015-08-17), we add submodule-config code that is later used to parse whether we are interested in updating submodules. We need the

Re: RFC: Another proposed hash function transition plan

Linus Torvalds writes: > So *if* the new object format uses a git header line like > > "blob \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. This is

Re: Server-side hooks on non-bare repository

Mike Lewis writes: > I’m having some issues with using server-side hooks when pushing > to a non-bare repository. In my git config, I have > `receive.denyCurrentBranch` set to `updateInstead`, which behaves > as expected, and updates the current working tree when the current >

[PATCH 18/18] builtin/read-tree: add --recurse-submodules switch

A new known failure mode is introduced[1], which is actually not a failure but a feature in read-tree. Unlike checkout for which the recursive submodule tests were originally written, read-tree does warn about ignored untracked files that would be overwritten. For the sake of keeping the test

[PATCH 05/18] lib-submodule-update.sh: define tests for recursing into submodules

Currently lib-submodule-update.sh provides 2 functions test_submodule_switch and test_submodule_forced_switch that are used by a variety of tests to ensure that submodules behave as expected. The current expected behavior is that submodules are not touched at all (see 42639d2317a for the exact

[PATCH 14/18] unpack-trees: check if we can perform the operation for submodules

Signed-off-by: Stefan Beller --- unpack-trees.c | 131 + unpack-trees.h | 1 + 2 files changed, 123 insertions(+), 9 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index 616a0ae4b2..8333da2cc9 100644 ---

[PATCH 04/18] lib-submodule-update.sh: replace sha1 by hash

Cleaning up code by generalising it. Currently the mailing list discusses yet again how to migrate away from sha1. Signed-off-by: Stefan Beller --- t/lib-submodule-update.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/lib-submodule-update.sh

[PATCH 11/18] update submodules: move up prepare_submodule_repo_env

In a later patch we need to prepare the submodule environment with another git directory, so split up the function. Also move it up in the file such that we do not need to declare the function later before using it. Signed-off-by: Stefan Beller --- submodule.c | 29

[PATCH 16/18] entry.c: update submodules when interesting

Signed-off-by: Stefan Beller --- entry.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/entry.c b/entry.c index c6eea240b6..d2b512da90 100644 --- a/entry.c +++ b/entry.c @@ -2,6 +2,7 @@ #include "blob.h" #include "dir.h" #include

[PATCH 12/18] update submodules: add submodule_move_head

In later patches we introduce the options and flag for commands that modify the working directory, e.g. git-checkout. This piece of code will be used universally for all these working tree modifications as it * supports dry run to answer the question: "Is it safe to change the submodule to this

[PATCH 15/18] read-cache, remove_marked_cache_entries: wipe selected submodules.

Signed-off-by: Stefan Beller --- read-cache.c | 27 +-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/read-cache.c b/read-cache.c index 9054369dd0..9a2abacf7a 100644 --- a/read-cache.c +++ b/read-cache.c @@ -18,6 +18,8 @@ #include

[PATCH 02/18] lib-submodule-update.sh: do not use ./. as submodule remote

Adding the repository itself as a submodule does not make sense in the real world. In our test suite we used to do that out of convenience in some tests as the current repository has easiest access for setting up 'just a submodule'. However this doesn't quite test the real world, so let's do not

[PATCH 13/18] unpack-trees: pass old oid to verify_clean_submodule

The check (which uses the old oid) is yet to be implemented, but this part is just a refactor, so it can go separately first. Signed-off-by: Stefan Beller --- unpack-trees.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/unpack-trees.c

[PATCH 17/18] builtin/checkout: add --recurse-submodules switch

This exposes a flag to recurse into submodules in builtin/checkout making use of the code implemented in prior patches. A new failure mode is introduced in the submodule update library, as the directory/submodule conflict is not solved in prior patches. Signed-off-by: Stefan Beller

[PATCH 01/18] lib-submodule-update.sh: reorder create_lib_submodule_repo

Redraw the ASCII art describing the setup using more space, such that it is easier to understand. The leaf commits are now ordered the same way the actual code is ordered. Add empty lines to the setup code separating each of the leaf commits, each starting with a "checkout -b". Signed-off-by:

[PATCH 07/18] connect_work_tree_and_git_dir: safely create leading directories

In a later patch we'll use connect_work_tree_and_git_dir when the directory for the gitlink file doesn't exist yet. This patch makes connect_work_tree_and_git_dir safe to use for both cases of either the git dir or the working dir missing. To do so, we need to call

[PATCH 03/18] lib-submodule-update: teach test_submodule_content the -C flag

Signed-off-by: Stefan Beller --- t/lib-submodule-update.sh | 5 + 1 file changed, 5 insertions(+) diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh index c0d6325133..00128f28b5 100755 --- a/t/lib-submodule-update.sh +++ b/t/lib-submodule-update.sh @@

[PATCH 10/18] submodules: introduce check to see whether to touch a submodule

In later patches we introduce the --recurse-submodule flag for commands that modify the working directory, e.g. git-checkout. It is potentially expensive to check if a submodule needs an update, because a common theme to interact with submodules is to spawn a child process for each interaction.

Re: [PATCH 03/18] lib-submodule-update: teach test_submodule_content the -C flag

On Mon, Mar 6, 2017 at 12:30 PM, Stefan Beller wrote: > > as well as another fix in git-submodule.sh > I spoke too early, that seems like a false positive.

Re: bisect-helper: we do not bisect --objects

"Philip Oakley" writes: > The study of human error is quite interesting Yes ;-)

Re: bisect-helper: we do not bisect --objects

Christian Couder 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

Re: [RFC 0/4] Shallow clones with on-demand fetch

On Mon, Mar 6, 2017 at 11:16 AM, Jonathan Tan wrote: > [1] <20170113155253.1644-1-benpe...@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

Re: RFC: Another proposed hash function transition plan

On 03/06, Linus Torvalds wrote: > On Mon, Mar 6, 2017 at 10:39 AM, Jonathan Tan > 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

[Request for Documentation] Differentiate signed (commits/tags/pushes)

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

Re: [RFC 0/4] Shallow clones with on-demand fetch

Mark Thomas 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

Re: [RFC 0/4] Shallow clones with on-demand fetch

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].

Re: RFC: Another proposed hash function transition plan

On Mon, Mar 6, 2017 at 10:39 AM, Jonathan Tan 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

Re: [PATCH v3] Travis: also test on 32-bit Linux

Lars Schneider 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

Re: [PATCH 01/10] submodule: decouple url and submodule existence

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

Re: RFC: Another proposed hash function transition plan

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.

Re: RFC: Another proposed hash function transition plan

Jeff King 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

Re: RFC: Another proposed hash function transition plan

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 wrote: > > > > > > This document is still in flux but I thought it best to send it out > > > early to start getting feedback.

Re: [PATCH v2] http: inform about alternates-as-redirects behavior

On 03/04, Jeff King wrote: > On Sat, Mar 04, 2017 at 08:36:45AM +, 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

Re: git init --separate-git-dir does not update symbolic .git links for submodules

On Sat, Mar 4, 2017 at 6:15 AM, Valery Tolstov 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

fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

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

Re: Fwd: HTTP Dumb Push?

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

Fwd: HTTP Dumb Push?

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?

Re: Delta compression not so effective

On 3/5/2017 19:14, Linus Torvalds wrote: On Sat, Mar 4, 2017 at 12:27 AM, Marius Storm-Olsen 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

Re: [PATCH v5 23/24] t1405: some basic tests on main ref store

On Fri, Mar 3, 2017 at 11:43 PM, Michael Haggerty 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

[PATCH v5 03/22] config: add git_config_get_split_index()

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 --- cache.h | 1 + config.c | 10 ++ 2 files changed, 11 insertions(+) diff --git a/cache.h b/cache.h index

[PATCH v5 01/22] config: mark an error message up for translation

Signed-off-by: Christian Couder --- 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)

[PATCH v5 00/22] Add configuration options for split-index

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

[PATCH v5 05/22] read-cache: add and then use tweak_split_index()

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 --- read-cache.c | 17 + 1 file changed, 17 insertions(+) diff --git a/read-cache.c b/read-cache.c

[PATCH v5 12/22] t1700: add tests for splitIndex.maxPercentChange

Signed-off-by: Christian Couder --- 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 ---

[PATCH v5 16/22] config: add git_config_get_expiry() from gc.c

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 --- builtin/gc.c | 18 +++--- cache.h | 3 +++

[PATCH v5 07/22] t1700: add tests for core.splitIndex

Signed-off-by: Christian Couder --- 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 +++

[PATCH v5 08/22] Documentation/config: add information for core.splitIndex

Signed-off-by: Christian Couder --- 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 @@

[PATCH v5 21/22] Documentation/config: add splitIndex.sharedIndexExpire

Signed-off-by: Christian Couder --- 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 +++

[PATCH v5 02/22] t1700: change here document style

This improves test indentation by getting rid of the outdated here document style. Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 170 - 1 file changed, 85 insertions(+), 85 deletions(-) diff --git

[PATCH v5 04/22] split-index: add {add,remove}_split_index() functions

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 ---

[PATCH v5 15/22] read-cache: touch shared index files when used

When a split-index file is created, let's update the mtime of the shared index file that the split-index file is referencing. In a following commit we will make shared index file expire depending on their mtime, so updating the mtime makes sure that the shared index file will not be deleted soon.

[PATCH v5 06/22] update-index: warn in case of split-index incoherency

When users are using `git update-index --(no-)split-index`, they may expect the split-index feature to be used or not according to the option they just used, but this might not be the case if the new "core.splitIndex" config variable has been set. In this case let's warn about what will happen and

[PATCH v5 18/22] t1700: test shared index file expiration

Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 44 1 file changed, 44 insertions(+) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index 00a64bed97..f5a95a6c28 100755 --- a/t/t1700-split-index.sh

[PATCH v5 20/22] read-cache: use freshen_shared_index() in read_index_from()

This way a share index file will not be garbage collected if we still read from an index it is based from. As we need to read the current index before creating a new one, the tests have to be adjusted, so that we don't expect an old shared index file to be deleted right away when we create a new

[PATCH v5 19/22] read-cache: refactor read_index_from()

It looks better and is simpler to review when we don't compute the same things many times in the function. It will also help make the following commit simpler. Signed-off-by: Christian Couder --- read-cache.c | 14 -- 1 file changed, 8 insertions(+), 6

[PATCH v5 10/22] config: add git_config_get_max_percent_split_change()

This new function will be used in a following commit to get the value of the "splitIndex.maxPercentChange" config variable. Signed-off-by: Christian Couder --- cache.h | 1 + config.c | 15 +++ 2 files changed, 16 insertions(+) diff --git a/cache.h

[PATCH v5 13/22] Documentation/config: add splitIndex.maxPercentChange

Signed-off-by: Christian Couder --- Documentation/config.txt | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index f102879261..b64aa7db2d 100644 --- a/Documentation/config.txt +++

[PATCH v5 09/22] Documentation/git-update-index: talk about core.splitIndex config var

Signed-off-by: Christian Couder --- Documentation/git-update-index.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index 7386c93162..e091b2a409 100644 ---

[PATCH v5 17/22] read-cache: unlink old sharedindex files

Everytime split index is turned on, it creates a "sharedindex." file in the git directory. This change makes sure that shared index files that haven't been used for a long time are removed when a new shared index file is created. The new "splitIndex.sharedIndexExpire" config variable is

[PATCH v5 22/22] Documentation/git-update-index: explain splitIndex.*

Signed-off-by: Christian Couder --- Documentation/config.txt | 2 +- Documentation/git-update-index.txt | 37 + 2 files changed, 30 insertions(+), 9 deletions(-) diff --git a/Documentation/config.txt

[PATCH v5 14/22] sha1_file: make check_and_freshen_file() non static

This function will be used in a commit soon, so let's make it available globally. Signed-off-by: Christian Couder --- cache.h | 3 +++ sha1_file.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/cache.h b/cache.h index 0bb9adcd31..a35e9d5187

[PATCH v5 11/22] read-cache: regenerate shared index if necessary

When writing a new split-index and there is a big number of cache entries in the split-index compared to the shared index, it is a good idea to regenerate the shared index. By default when the ratio reaches 20%, we will push back all the entries from the split-index into a new shared index file

Re: RFC: Another proposed hash function transition plan

On Mon, Mar 06, 2017 at 10:29:33AM +0100, ankostis wrote: > On 5 March 2017 at 12:02, David Lang wrote: > >> Translation table > >> ~ > >> A fast bidirectional mapping between sha1-names and sha256-names of > >> all local objects in the repository is kept on disk.

Re: RFC: Another proposed hash function transition plan

On Fri, Mar 03, 2017 at 05:12:51PM -0800, Jonathan Nieder wrote: > This past week we came up with this idea for what a transition to a new > hash function for Git would look like. I'd be interested in your > thoughts (especially if you can make them as comments on the document, > which makes it