Re: [PATCH] Change type of signed int flags to unsigned

On Thu, Feb 25, 2016 at 8:24 AM, Saurav Sachidanand wrote: > “pattern” and “exclude” are two structs defined in attr.c and dir.h > respectively. Each contains a field named “flags” of type int, that > takes on values from the set of positive integers {1, 4, 8, 16} >

Re: [PATCH v3 4/7] notes copy --stdin: split lines with string_list_split()

On 02/28/2016 07:56 AM, Eric Sunshine wrote: > On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote: >> This patch changes, how the lines are split, when reading them from >> stdin to copy the notes. The advantage of string_list_split() over >> strbuf_split() is that it

Re: [PATCH v3 3/7] clean: read user input with strbuf_getline()

On 02/28/2016 07:36 AM, Eric Sunshine wrote: > On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote: >> The inputs that are read are all answers that are given by the user >> when interacting with git on the commandline. As these answers are >> not supposed to contain a

Re: [PATCH v3 2/7] bisect: read bisect paths with strbuf_getline()

On 02/28/2016 07:33 AM, Eric Sunshine wrote: > On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote: >> The file BISECT_NAMES is written by "git rev-parse --sq-quote" via >> sq_quote_argv() when starting a bisection. It can contain pathspecs >> to narrow down the search. When

Re: [PATCH v3 0/7] replacing strbuf_getline_lf() by strbuf_getline()

On 02/28/2016 07:30 AM, Eric Sunshine wrote: > On Sun, Feb 28, 2016 at 12:07 AM, Moritz Neeb wrote: >> This series deals with strbuf_getline_lf() in certain codepaths: >> Those, where the input that is read, is/was trimmed before doing anything >> that >> could possibly

Re: [PATCH v3 4/7] notes copy --stdin: split lines with string_list_split()

On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote: > This patch changes, how the lines are split, when reading them from > stdin to copy the notes. The advantage of string_list_split() over > strbuf_split() is that it removes the terminator, making trimming > of the left

Re: [PATCH v3 3/7] clean: read user input with strbuf_getline()

On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote: > The inputs that are read are all answers that are given by the user > when interacting with git on the commandline. As these answers are > not supposed to contain a meaningful CR it is safe to > replace

Re: [PATCH v3 2/7] bisect: read bisect paths with strbuf_getline()

On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote: > The file BISECT_NAMES is written by "git rev-parse --sq-quote" via > sq_quote_argv() when starting a bisection. It can contain pathspecs > to narrow down the search. When reading it back, it should be expected that >

Re: [PATCH v3 0/7] replacing strbuf_getline_lf() by strbuf_getline()

On Sun, Feb 28, 2016 at 12:07 AM, Moritz Neeb wrote: > This series deals with strbuf_getline_lf() in certain codepaths: > Those, where the input that is read, is/was trimmed before doing anything that > could possibly expect a CR character. Those places can be assumed to be

[PATCH v3 7/7] wt-status: read rebase todolist with strbuf_getline()

In read_rebase_todolist() the files $GIT_DIR/rebase-merge/done and $GIT_DIR/rebase-merge/git-rebase-todo are read to collect status information. The access to this file should always happen via git rebase, e.g. via "git rebase -i" or "git rebase --edit-todo". We can assume, that this interface

[PATCH v3 5/7] notes copy --stdin: read lines with strbuf_getline()

The format of a line that is expected when copying notes via stdin is "sha1 sha1". As this is text-only, strbuf_getline() can be used instead of strbuf_getline_lf(). When reading with strbuf_getline() the trimming can be removed. It was necessary before to remove potential CRs inserted through a

[PATCH v3 0/7] replacing strbuf_getline_lf() by strbuf_getline()

This series deals with strbuf_getline_lf() in certain codepaths: Those, where the input that is read, is/was trimmed before doing anything that could possibly expect a CR character. Those places can be assumed to be "text" input, where a CR never would be a meaningful control character. The

[PATCH v3 6/7] remote: read $GIT_DIR/branches/* with strbuf_getline()

The line read from the branch file is directly trimmed after reading with strbuf_trim(). There is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- remote.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v3 3/7] clean: read user input with strbuf_getline()

The inputs that are read are all answers that are given by the user when interacting with git on the commandline. As these answers are not supposed to contain a meaningful CR it is safe to replace strbuf_getline_lf() can be replaced by strbuf_getline(). In the subsequent codepath, the input is

[PATCH v3 1/7] quote: remove leading space in sq_dequote_step

Because sq_quote_argv adds a leading space (which is expected in trace.c), sq_dequote_step should remove this space again, such that the operations of quoting and dequoting are inverse of each other. This patch is preparing the way to remove some excessive trimming operation in bisect in the

[PATCH v3 2/7] bisect: read bisect paths with strbuf_getline()

The file BISECT_NAMES is written by "git rev-parse --sq-quote" via sq_quote_argv() when starting a bisection. It can contain pathspecs to narrow down the search. When reading it back, it should be expected that sq_dequote_to_argv_array() is able to parse this file. In fact, the previous commit

[PATCH v3 4/7] notes copy --stdin: split lines with string_list_split()

This patch changes, how the lines are split, when reading them from stdin to copy the notes. The advantage of string_list_split() over strbuf_split() is that it removes the terminator, making trimming of the left part unneccesary. The strbuf is now rtrimmed before splitting. This is still

Re: Fwd: git clone does not respect command line options

On Sun, Feb 28, 2016 at 09:03:43AM +0530, Guilherme wrote: > What is the current situation if credential.helper is set twice in the same > config file. > > Either > [credential] > helper = first > helper = second > > or with > [credential] > helper = first > > [credenital] > helper =

Re: [PATCH 1/1] t9115: Skip pathnameencoding=cp932 under HFS

tbo...@web.de wrote: > --- a/t/t9115-git-svn-dcommit-funky-renames.sh > +++ b/t/t9115-git-svn-dcommit-funky-renames.sh > @@ -93,7 +93,7 @@ test_expect_success 'git svn rebase works inside a > fresh-cloned repository' ' > # > to special UNICODE characters in the range 0xf000 to 0xf0ff (the > # >

git config --get-urlmatch does not set exit code 1 when no match is found

Hello, My current woes are with multi-valued configuration values. More specifically credential.helper The documentation of git config says that when a value is not matched it should return 1. To reproduce make sure that credential.helper is not set. git config --get-urlmatch credential.helper

Re: [PATCH] git-p4.py: Make submit working on bare repository

On 23 February 2016 at 20:56, Amadeusz Żołnowski wrote: > > To simplify things, why not just update ref during submit from bare > repository? As you have pointed out, if user invokes submit in this > context he/she actually wants to submit from bare repo and probably > knows

Re: Fwd: git clone does not respect command line options

What is the current situation if credential.helper is set twice in the same config file. Either [credential] helper = first helper = second or with [credential] helper = first [credenital] helper = second Will both be used by git clone? How do i remove these from the command line? I

Re: [PATCH 2/2] Revert "rev-parse: remove restrictions on some options"

On Fri, Feb 26, 2016 at 6:29 PM, Jeff King wrote: > This reverts commit 68889b416d5b6a5cf7d280a428281d635fe9b292. > > That commit bumped some rev-parse options into the main > option-parsing loop, which meant that they no longer had to > come at the very beginning of the option

Re: [PATCH 00/22] Mark more strings for translation

On Sun, Feb 28, 2016 at 12:34 AM, Junio C Hamano wrote: > We'd still want the fixes to apply on top of relevant topics if we > could, as the fix to the topic itself (with or without i18n fixes), > when we discover that it has a huge flaw not desirable in v2.8.0, > might be to

Re: Bug#813084: Background git gc fails, telling me to run git prune, which doesn't help

Control: forwarded -1 git@vger.kernel.org On Fri, 2016-01-29 at 21:05 +0700, Duy Nguyen wrote: > On Fri, Jan 29, 2016 at 8:35 PM, Ben Hutchings wrote: > > git keeps trying to do a background gc on my linux repository, but > > fails, reporting this in .git/gc.log: > > > >

Re: [PATCH] fetch-pack: fix object_id of exact sha1

On Sat, Feb 27, 2016 at 7:12 PM, Jeff King wrote: > On Sat, Feb 27, 2016 at 05:32:54PM -0300, Gabriel Souza Franco wrote: > >> Commit 58f2ed0 (remote-curl: pass ref SHA-1 to fetch-pack as well, >> 2013-12-05) added support for specifying a SHA-1 as well as a ref name. >> Add

Re: [PATCH] fetch-pack: fix object_id of exact sha1

On Sat, Feb 27, 2016 at 05:32:54PM -0300, Gabriel Souza Franco wrote: > Commit 58f2ed0 (remote-curl: pass ref SHA-1 to fetch-pack as well, > 2013-12-05) added support for specifying a SHA-1 as well as a ref name. > Add support for specifying just a SHA-1 and set the ref name to the same > value

Re: [PATCH] fetch-pack: fix unadvertised requests validation

On Sat, Feb 27, 2016 at 05:28:55PM -0300, Gabriel Souza Franco wrote: > On Sat, Feb 27, 2016 at 4:19 PM, Jeff King wrote: > > On Sat, Feb 27, 2016 at 02:07:12PM -0500, Jeff King wrote: > > > >> We expect whoever creates the "sought" list to fill in the name and sha1 > >> as

[PATCH] fetch-pack: fix object_id of exact sha1

Commit 58f2ed0 (remote-curl: pass ref SHA-1 to fetch-pack as well, 2013-12-05) added support for specifying a SHA-1 as well as a ref name. Add support for specifying just a SHA-1 and set the ref name to the same value in this case. Signed-off-by: Gabriel Souza Franco

Re: [PATCH] fetch-pack: fix unadvertised requests validation

On Sat, Feb 27, 2016 at 4:19 PM, Jeff King wrote: > On Sat, Feb 27, 2016 at 02:07:12PM -0500, Jeff King wrote: > >> We expect whoever creates the "sought" list to fill in the name and sha1 >> as appropriate. If that is not happening in some code path, then yeah, >> filter_refs()

[PATCH] environment.c: introduce DECLARE_GIT_GETTER helper macro

The environment.c contans a couple of functions which are consist from the following pattern: if (!env) setup_git_env(); return env; Let's move declaration of these functions to the DECLARE_GIT_GETTER helper macro to prevent code duplication. Signed-off-by:

Re: [PATCH 01/16] bisect: write about `bisect next` in documentation

Hi, On 02/27/2016 07:03 PM, Junio C Hamano wrote: > Stephan Beyer writes: > >> This command is also handy when you accidentally checked out another >> commit during a bisection. It computes the commit for the bisection >> and checks it out again. >> >> -->8-->8-->8-- >> >> Is

Re: [PATCH v2 1/2] pull --rebase: add --[no-]autostash flag

Mehul Jain writes: > git pull --rebase understands --[no-]autostash flag. > > This flag overrides config variable "rebase.autoStash" > if set (default is false). Is that a statement of a fact? If so, is it true before this patch is applied, or after? Each project

Re: [PATCH] fetch-pack: fix unadvertised requests validation

On Sat, Feb 27, 2016 at 02:07:12PM -0500, Jeff King wrote: > We expect whoever creates the "sought" list to fill in the name and sha1 > as appropriate. If that is not happening in some code path, then yeah, > filter_refs() will not work as intended. But I think the solution there > would be to

Re: [PATCH] environment.c: introduce SETUP_GIT_ENV helper macro

Hello Junio, On Sun, Feb 28, 2016 at 12:50 AM, Junio C Hamano wrote: > Junio C Hamano writes: > > >> Please don't. A macro that hides "return" makes things harder to >> follow, not easier. I will consider it next time. > Having said that, I do think a

Re: [PATCH] fetch-pack: fix unadvertised requests validation

On Sat, Feb 27, 2016 at 10:25:40AM -0800, Junio C Hamano wrote: > Gabriel Souza Franco writes: > > > Check was introduced in b791642 (filter_ref: avoid overwriting > > ref->old_sha1 with garbage, 2015-03-19), but was always false because > > ref->old_oid.hash is

Re: [PATCH 00/22] Mark more strings for translation

Junio C Hamano writes: > Thanks. "A new string we added since v2.7.0 that is not marked for > i18n" is a new i18n bug and "a string that used to be marked is not > marked when the code was rewritten since v2.7.0" is an i18n > regression, and we would want to "fix" both post

Re: [PATCH] environment.c: introduce SETUP_GIT_ENV helper macro

Junio C Hamano writes: > Alexander Kuleshov writes: > >> Let's move this to the SETUP_GIT_ENV helper macro to prevent >> code duplication in these functions. > > Please don't. A macro that hides "return" makes things harder to > follow, not easier. >>

Re: [PATCH] fetch-pack: fix unadvertised requests validation

Junio C Hamano writes: > Nah, I think you just misspelt hashcpy() as hashcmp(). The original > wanted to get the binary representation of the hex in old_sha1 when > it continued, and you wanted to delay the touching of old_sha1 until > we make sure that the input is valid

Re: [PATCH] fetch-pack: fix unadvertised requests validation

Junio C Hamano writes: > Gabriel Souza Franco writes: > >> Check was introduced in b791642 (filter_ref: avoid overwriting >> ref->old_sha1 with garbage, 2015-03-19), but was always false because >> ref->old_oid.hash is empty in this case. Instead

Re: [PATCH/RFC] builtin/tag: Changes argument format for verify

On Sat, Feb 27, 2016 at 12:45:24PM -0500, Santiago Torres wrote: > > A much more interesting change in this area, I think, would be to skip > > verify-tag entirely. Once upon a time it had a lot of logic itself, but > > these days it is a thin wrapper over run_gpg_verify(), and we could > >

[PATCH 1/1] t9115: Skip pathnameencoding=cp932 under HFS

From: Torsten Bögershausen HFS+ under Mac OS X doesn't allow file names like "\201\207", so skip the tests using cp932. Signed-off-by: Torsten Bögershausen --- t/t9115-git-svn-dcommit-funky-renames.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

Re: [PATCH 4/3] sha1_file.c: mark strings for translation

On Sat, Feb 27, 2016 at 09:41:09AM -0800, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > > > Signed-off-by: Nguyễn Thái Ngọc Duy > > --- > > Since jk/pack-idx-corruption-safety is already in 'next', can we add > > this patch on top? Surrounding

Re: [PATCH] fetch-pack: fix unadvertised requests validation

Gabriel Souza Franco writes: > Check was introduced in b791642 (filter_ref: avoid overwriting > ref->old_sha1 with garbage, 2015-03-19), but was always false because > ref->old_oid.hash is empty in this case. Instead copy sha1 from ref->name. > > Signed-off-by:

Re: [PATCH 01/16] bisect: write about `bisect next` in documentation

Stephan Beyer writes: > I rephrase it as follows to not encourage checking out another branch > (or commit ;]) but to mention that it works to get back if someone > accidentally did it. > > --8<--8<--8<-- > > Bisect next > ~~~ > > In case you have marked a commit as bad

Re: [PATCH] environment.c: introduce SETUP_GIT_ENV helper macro

Alexander Kuleshov writes: > The environment.c contans a couple of functions which are > consist from the following pattern: > > if (!env) > setup_git_env(); > return env; > > Let's move this to the SETUP_GIT_ENV helper macro to prevent >

Re: [ANNOUNCE] Git v2.8.0-rc0

Christian Couder writes: > On Sat, Feb 27, 2016 at 12:41 AM, Junio C Hamano wrote: >> >> Git 2.8 Release Notes (draft) >> = >> >> Backward compatibility note >> --- >> >> The rsync:// transport

Re: [PATCH/RFC] builtin/tag: Changes argument format for verify

Hello Jeff, thanks for going through the patch. > > diff --git a/builtin/tag.c b/builtin/tag.c > > index 1705c94..5de1161 100644 > > --- a/builtin/tag.c > > +++ b/builtin/tag.c > > @@ -105,8 +105,7 @@ static int verify_tag(const char *name, const char *ref, > > const

Re: What's cooking in git.git (Feb 2016, #08; Fri, 26)

Stefan Beller writes: > On Fri, Feb 26, 2016 at 3:41 PM, Junio C Hamano wrote: > >> * sb/submodule-parallel-update (2016-02-25) 11 commits >> - clone: allow an explicit argument for parallel submodule clones >> - submodule update: expose parallelism to

[PATCH v2 2/2] Documentation/git-pull.txt: teach 'git pull --rebase' the --[no-]autostash option.

git pull --rebase understands --[no-]autostash flag. This flag overrides config variable "rebase.autoStash" if set (default is false). When calling "git pull --rebase" with "--autostash", pull passes the "--autostash" option to rebase, which then runs rebase on a dirty worktree. With

[PATCH v2 1/2] pull --rebase: add --[no-]autostash flag

git pull --rebase understands --[no-]autostash flag. This flag overrides config variable "rebase.autoStash" if set (default is false). When calling "git pull --rebase" with "--autostash", pull passes the "--autostash" option to rebase, which then runs rebase on a dirty worktree. With

Re: [PATCH 4/3] sha1_file.c: mark strings for translation

Nguyễn Thái Ngọc Duy writes: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > Since jk/pack-idx-corruption-safety is already in 'next', can we add > this patch on top? Surrounding strings are handled separately [1] by > another series. > > [1] >

Re: What's cooking in git.git (Feb 2016, #07; Thu, 25)

How about something like this as a workaround ? (I can send a proper patch, if this is the way forward) commit dcd7d5551d6931e47829c7febbee0877340eb17f Author: Torsten Bögershausen Date: Sat Feb 27 15:18:28 2016 +0100 config.mak.uname: Darwin: Use clang for Mac OS X 10.6

Re: [PATCH 00/22] Mark more strings for translation

Nguyễn Thái Ngọc Duy writes: > On Sat, Feb 27, 2016 at 6:41 AM, Junio C Hamano wrote: >> In previous cycles, I often left many topics in 'next' when tagging >> this zero-th preview, but eventually merged them before the final. >> I decided to do things a

[PATCH] environment.c: introduce SETUP_GIT_ENV helper macro

The environment.c contans a couple of functions which are consist from the following pattern: if (!env) setup_git_env(); return env; Let's move this to the SETUP_GIT_ENV helper macro to prevent code duplication in these functions. Signed-off-by: Alexander

Re: GSoC 2016 Microproject

Sidhant Sharma writes: >> There's already work in progress on this project, see the mailing list >> the last few days. >> > > Okay, in that case, I'd like to try is the one titled "Make upload-pack > and receive-pack use the parse-options api". In that, I can take up > the

Re: GSoC 2016 Microproject

> There's already work in progress on this project, see the mailing list > the last few days. > Okay, in that case, I'd like to try is the one titled "Make upload-pack and receive-pack use the parse-options api". In that, I can take up the `builtin/receive-pack.c` file. Would that be okay?

RE: Consulting for implementation

Hi Jose, In my $DAYJOB, I do a lot of process and requirements work often involving git - so I'm more of an advocate than a representative. Although I cannot speak on behalf of the community as a whole, I would be happy to have a preliminary discussion with you on the type of guidance you might

Vr headset,vr box,Vr glasses,from the original factory

Dear Happy 2016, Hottest VR box,for mobile phone,Watch 3D movie and vr video,Play vr games Price only $6/pc now,only from the arcpeaks factory Alibaba link,http://arcpeaks.en.alibaba.com/product/60401287002-802634136/2016_hottest_product_virtual_reality_3d_games_and_video_3d_vr_glasses.html

Re: [PATCH 01/16] bisect: write about `bisect next` in documentation

Hi, On 02/26/2016 07:47 PM, Junio C Hamano wrote: > But I wonder if it is safe and sane to encourage "checking out other > branches during a bisect session." as you cannot tell what other > crazy things they will do while on "other branches". I do not think > we even try to (and I do not think

Re: GSoC 2016 Microproject

Sidhant Sharma writes: > Hi everyone, > > > I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute > to Git in general as well). I read up the pages relating to participation > in GSoC and selected the microproject "Add configuration options for

GSoC 2016 Microproject

Hi everyone, I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute to Git in general as well). I read up the pages relating to participation in GSoC and selected the microproject "Add configuration options for some commonly used command-line options". I have some

[PATCH] fetch-pack: fix unadvertised requests validation

Check was introduced in b791642 (filter_ref: avoid overwriting ref->old_sha1 with garbage, 2015-03-19), but was always false because ref->old_oid.hash is empty in this case. Instead copy sha1 from ref->name. Signed-off-by: Gabriel Souza Franco --- fetch-pack.c | 4

Re: [PATCH 02/16] bisect: add test for the bisect algorithm

Christian Couder writes: > Hi Stephan, > > On Fri, Feb 26, 2016 at 10:38 PM, Stephan Beyer wrote: >> Hi Christian, >> >> On 02/26/2016 07:53 AM, Christian Couder wrote: +test_expect_success 'bisect algorithm works in linear history with an odd

Re: [PATCH 2/2] Revert "rev-parse: remove restrictions on some options"

On Fri, Feb 26, 2016 at 06:29:57PM -0500, Jeff King wrote: > This reverts commit 68889b416d5b6a5cf7d280a428281d635fe9b292. [snip] > The original patch was not spurred by an actual bug report, > but by an observation[1] that was essentially "eh, this > looks unnecessarily restrictive". It _is_

Re: [PATCH 02/16] bisect: add test for the bisect algorithm

Hi Stephan, On Fri, Feb 26, 2016 at 10:38 PM, Stephan Beyer wrote: > Hi Christian, > > On 02/26/2016 07:53 AM, Christian Couder wrote: >>> +test_expect_success 'bisect algorithm works in linear history with an odd >>> number of commits' ' >>> + git bisect start A7 && >>>

Re: [ANNOUNCE] Git v2.8.0-rc0

On Sat, Feb 27, 2016 at 12:41 AM, Junio C Hamano wrote: > > Git 2.8 Release Notes (draft) > = > > Backward compatibility note > --- > > The rsync:// transport has been removed. We may want to add something about untracked

[PATCH] README.md: don't take 'commandname' literally

The link to Documentation/git-commandname.txt was obviously broken. Remove the link and make it clear that it is not a literal path name by using *italics* in makdown. Signed-off-by: Matthieu Moy --- Sorry for the overeager change in the previous patch :-(. README.md | 7

Re: Trouble Cloning Git remote repository

On Sat, Feb 27, 2016 at 6:03 AM, Fred's Personal wrote: > $ git clone -v ssh://user1@Host2/srv/centralrepo > Cloning into 'centralrepo'... Lines from $HOME/.bashrc > + export > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games >

Re: [PATCHv19 09/11] git submodule update: have a dedicated helper for cloning

On Fri, Feb 26, 2016 at 6:48 AM, Stefan Beller wrote: > +static int prepare_to_clone_next_submodule(const struct cache_entry *ce, > + struct child_process *child, > + struct

Kind regards! Dear Sir or Madam! - please help our school site - пожалуйста, помогите нашему школьному сайту - будь ласка, допоможіть нашому шкільному сайту http://40030ssch2.pp.ua/

Kind regards! Dear Sir or Madam! please at the top of any page of site click once on the advertising banner, so that we could pay for hosting our school site, Thank you ad...@40030ssch2.pp.ua http://40030ssch2.pp.ua/ добрий день, просимо на будь-якій сторінці вгорі один раз натиснути на

Re: [PATCHv4 2/2] submodule: port init from shell to C

On Thu, Jan 28, 2016 at 9:30 AM, Stefan Beller wrote: > diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c > index 13583d9..689c354 100644 > --- a/builtin/submodule--helper.c > +++ b/builtin/submodule--helper.c > +static int module_init(int argc, const char

Re: [PATCH 1/2] submodule: port resolve_relative_url from shell to C

On Fri, Feb 12, 2016 at 03:39:15PM -0800, Stefan Beller wrote: > Later on we want to automatically call `git submodule init` from > other commands, such that the users don't have to initialize the > submodule themselves. As these other commands are written in C > already, we'd need the init