Re: [PATCH] receive-pack: simplify run_update_post_hook()

arfe <l@web.de> > --- > builtin/receive-pack.c | 13 + > 1 file changed, 5 insertions(+), 8 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH] run-command: fix segfault when cleaning forked async process

Jeff King wrote: > Reported-by: Brandon Williams <bmw...@google.com> > Signed-off-by: Jeff King <p...@peff.net> Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [PATCH 2/2] grep: fix builds with with no thread support

; is available. [...] > Reported-by: Rahul Bedarkar <rahul.bedar...@imgtec.com> > Signed-off-by: Brandon Williams <bmw...@google.com> > --- > builtin/grep.c | 21 + > 1 file changed, 9 insertions(+), 12 deletions(-) With or without that commit message tweak, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

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

Hi, Stefan Beller wrote: > Add the flag --show-superproject-working-tree to git-rev-parse > to make it easy to find out if there is a superproject. When no > superproject exists, the output will be empty. I'm a little late for this, but think it's better to comment late than never. After this

Re: Bug with .gitignore and branch switching

Junio C Hamano wrote: > There is no "untracked but precious" vs "untracked and expendable" > difference in the current system. An untracked file that matches > patterns listed in .gitignore is treated as the latter. [...] > We've discussed the lack of "untracked but precious" class a few > times

Re: Bug with .gitignore and branch switching

Hi Nevada, Nevada Sanchez wrote: > # Commit a file that will end up in .gitignore > echo 'original settings' > mine.conf > git add mine.conf > git commit -m "Unknowingly committed my settings." > > echo '*.conf' > .gitignore > git add .gitignore > git commit -m "Users shouldn't commit their

Re: why patch to the gitk no replay?

Hi, yanke131415 wrote: > I send a patch to gitk > project(git://ozlabs.org/~paulus/gitk)with the target email address > pau...@ozlabs.org. But several days later No replay of this patch i > receive, is the email address i send patch wrong? Anyone who knows? Sending to this mailing list

Re: [PATCH v2] short status: improve reporting for submodule changes

Stefan Beller wrote: > Jonathan Nieder wrote: >> Is it important to avoid clutter by showing the submodule only once? >> What would you think of showing whatever subset of those three >> statuses apply to a given submodule as separate lines instead, to >> match the info

Re: [PATCH] wt-status.c: improve readability for wt_shortstatus_print

ger counter. > Signed-off-by: Stefan Beller <sbel...@google.com> > --- > wt-status.c | 20 +--- > 1 file changed, 5 insertions(+), 15 deletions(-) I like the diffstat. :) With or without a clarified commit message, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH v2] short status: improve reporting for submodule changes

Hi, Yay, I like the change this makes. So I'll nitpick in the hope that that makes the patch more likely to stick. Stefan Beller wrote: > While we already have a porcelain2 layer for git-status, that is accurate > for submodules, users still like the way they are are used to of > 'status -s'.

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

Jeff King wrote: > On Tue, Mar 14, 2017 at 11:41:26AM -0700, Jonathan Nieder wrote: >> brian m. carlson wrote: >>> --- a/cache.h >>> +++ b/cache.h >>> @@ -10,8 +10,8 @@ >>> #include "trace.h" >>> #include "string-list.h"

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

toothpaste.net> > Signed-off-by: Junio C Hamano <gits...@pobox.com> Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks for taking care of it.

Re: [RFC PATCH] Move SHA-1 implementation selection into a header file

ink). Conditional #includes are a pretty normal thing so I am fine with this more straightforward change. So Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> That said, if someone is excited about one of the other approaches then I don't object to them. Thanks, Jonathan

Re: RFC: Another proposed hash function transition plan

Hi, The Keccak Team wrote: > We have read your transition plan to move away from SHA-1 and noticed > your intent to use SHA3-256 as the new hash function in the new Git > repository format and protocol. Although this is a valid choice, we > think that the new SHA-3 standard proposes alternatives

Re: [GSoC] Move ~/.git-credential-cache to ~/.cache/git

(+cc: npostavs) Hi Devin, Devin Lehmacher wrote: > I started working on this microproject and am not quite sure what is > necessary for backwards compatibility. Since the socket is recreated > whenever the credential daemon exits backwards compatibility > shouldn’t really be a concern with

Re: RFC v3: Another proposed hash function transition plan

Jeff King wrote: > On Thu, Mar 09, 2017 at 12:24:08PM -0800, Jonathan Nieder wrote: >>> SHA-1 to SHA-3: lookup SHA-1 in .msha1, reverse .idx, find offset to >>> read the SHA-3. >>> SHA-3 to SHA-1: lookup SHA-3 in .idx, and reverse the .msha1 file to >>>

Re: [RFC PATCH] help: add optional instructions for reporting bugs

Hi, Stefan Beller wrote: > When reporting bugs, users will usually look at the output of > 'git --version' at one point to write a quality bug report. > So that is a good spot to provide additional information to the user > about e.g. additional the organizational quirks how to report a bug. > >

Re: RFC v3: Another proposed hash function transition plan

Hi, Shawn Pearce wrote: > On Mon, Mar 6, 2017 at 4:17 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: >> Alongside the packfile, a sha3 repository stores a bidirectional >> mapping between sha3 and sha1 object names. The mapping is generated >> locally and can

RFC v3: Another proposed hash function transition plan

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

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: Another proposed hash function transition plan

Hi, 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 easier to address them and update the document). This document is

[PATCH v2] remote helpers: avoid blind fall-back to ".git" when setting GIT_DIR

t it, add some tests for other variables in the environment of commands run by git-remote-ext. Helped-by: Jeff King <p...@peff.net> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- Jeff King wrote: > So yeah, I think this is the extent of the change needed. Thanks. Here's the pat

Re: [PATCH 7/7] setup_git_env: avoid blind fall-back to ".git"

Hi, Jeff King wrote: > This passes the test suite (after the adjustments in the > previous patches), but there's a risk of regression for any > cases where the fallback usually works fine but the code > isn't exercised by the test suite. So by itself, this > commit is a potential step backward,

Re: [PATCH] transport: add core.allowProtocol config option

(+peff and bburky, who introduced GIT_ALLOW_PROTOCOL) Brandon Williams wrote: > Add configuration option 'core.allowProtocol' to allow users to create a > whitelist of allowed protocols for fetch/push/clone in their gitconfig. Ooh. This would be especially useful at $DAYJOB, where there is a

Re: [PATCH v5 0/3] handle empty spec-compliant remote repos correctly

ns(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thank you, Jonathan

Re: [PATCH v4 3/3] connect: advertized capability is not a ref

Jonathan Tan wrote: > --- a/connect.c > +++ b/connect.c > @@ -172,8 +173,24 @@ struct ref **get_remote_heads(int in, char *src_buf, > size_t src_len, > continue; > } > > + if (!strcmp(name, "capabilities^{}")) { > + if

Re: [PATCH] connect: tighten check for unexpected early hang up (Re: [PATCH v3 2/2] connect: advertized capability is not a ref)

Jonathan Nieder wrote: > Subject: connect: tighten check for unexpected early hang up [...] > @@ -131,7 +131,7 @@ struct ref **get_remote_heads(int in, char *src_buf, > size_t src_len, > PACKET_READ_G

Re: [PATCH] connect: tighten check for unexpected early hang up (Re: [PATCH v3 2/2] connect: advertized capability is not a ref)

Jonathan Nieder wrote: > Change-Id: I3cec2c160eb6c6f3efdce7dab38a4c78592f6c7f Gah --- sorry about that. Please remove this line if applying (or I'll be happy to resend without it after review). Jonathan

[PATCH] connect: tighten check for unexpected early hang up (Re: [PATCH v3 2/2] connect: advertized capability is not a ref)

(+cc: Heiko) Jonathan Nieder wrote: > 'die_initial_contact' uses got_at_least_one_head to determine whether > it was on the first line but code paths added later that use > 'continue' don't populate it properly (see b06dcd7d, 40c155ff, and > 1a7141ff). We could do > >

Re: [PATCH v3 2/2] connect: advertized capability is not a ref

Jonathan Tan wrote: > Git advertises the same capabilities^{} ref in its ref advertisement for push > but since it never remembered to do so for fetch, the client forgot to handle > this case. Handle it. The comment in the previous review was that this doesn't describe the history correctly. It

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Junio C Hamano wrote: > Jonathan Tan writes: >> diff --git a/connect.c b/connect.c >> index 722dc3f..0c2221e 100644 >> --- a/connect.c >> +++ b/connect.c >> @@ -165,6 +165,9 @@ struct ref **get_remote_heads(int in, char *src_buf, >> size_t src_len, >>

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Stefan Beller wrote: > On Fri, Sep 2, 2016 at 4:35 PM, Jeff King wrote: >> I'd be more interested in the pain of this transition if there was a >> concrete use case for "hide literally all refs, but still allow >> fetches". Is that a thing that people do? [...] > Not to derail the

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Jeff King wrote: > On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote: > But combining hideRefs with > allowTipSHA1InWant could trigger this case. Yes. [...] > I'd be more interested in the pain of this transition if there was a > concrete use case for

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Jonathan Tan wrote: > Signed-off-by: Jonathan Tan <jonathanta...@google.com> > --- > connect.c| 3 +++ > t/t5512-ls-remote.sh | 39 +++ > 2 files changed, 42 insertions(+) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [PATCH 2/2] connect: know that zero-ID is not a ref

Hi, Jonathan Tan wrote: > connect.c, when processing packfiles, treats a zero ID (with > `capabilities^{}` in place of the refname) as an actual ref instead of a > placeholder for a capability declaration, contrary to the specification > in Reference Discovery in

Re: [PATCH] checkout: do not mention detach advice for explicit --detach option

Stefan Beller wrote: > When a user asked for a detached HEAD specifically with `--detach`, > we do not need to give advice on what a detached HEAD state entails as > we can assume they know what they're getting into as they asked for it. Example? Tests? > Signed-off-by: Stefan Beller

Re: [PATCH] submodule: do no re-read name in shell script

Stefan Beller wrote: > Instead of making another call to a submodule helper (name), just > propagate the value when we know it (in the update-clone helper) already. > > Signed-off-by: Stefan Beller > --- > builtin/submodule--helper.c | 4 ++-- > git-submodule.sh|

Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially

Junio C Hamano wrote: > Even if it is conservative, I wonder if it is truly a good idea to > make it exponentially grow forever from that point of view. Would > it give essentially the same result to you if we discard the patch > in question and just raise LARGE_FLUSH to 10k instead? I don't

Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially

Jonathan Tan wrote: > Signed-off-by: Jonathan Tan <jonathanta...@google.com> > --- > fetch-pack.c | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks again. -- To unsubscribe from

Re: Git and SHA-1 security (again)

Junio C Hamano wrote: > Continuing this thought process, I do not see a good way to allow us > to wean ourselves off of the old hash, unless we _break_ the pack > stream format so that each object in the pack carries not just the > data but also the hash algorithm to be used to _name_ it, so that

Re: [PATCH] fetch-pack: grow stateless RPC windows exponentially

Jonathan Tan wrote: > On Mon, Jul 18, 2016 at 12:10 PM, Junio C Hamano wrote: >> I'd understand if it were more like "aggressive exponential -> >> conservative exponential" without linear phase when stateless_rpc is >> in use, though. I just do not quite understand the

Re: [PATCH] fetch-pack: grow stateless RPC windows exponentially

usage is already something we'd want to address separately to handle hostile servers. All in all, this looks likely to allow negotiation to finish in fewer rounds, speeding up fetch, without much downside, so for what it's worth, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> I'd expect

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

Hi, Junio C Hamano wrote: > Stefan Beller writes: >>> More importantly, if we plan to make this configurable and not make >>> the limit a hardwired constant of the wire protocol, it may be >>> better to advertise push-options capability with the limit, e.g. >>>

[PATCH v2] doc: git-htmldocs.googlecode.com is no more

http://git-htmldocs.googlecode.com/git/git.html says There was no service found for the uri requested. Link to the rendered documentation on Jekyll instead. Reported-by: Andrea Stacchiotti <andreastacchio...@gmail.com> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- Ju

[PATCH] doc: git-htmldocs.googlecode.com is no more

hio...@gmail.com> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- Hi Andrea, Andrea Stacchiotti wrote[1]: > In the git manual (`man git`), the documentation link: > > http://git-htmldocs.googlecode.com/git/git.html > is broken. Thanks for reporting. How about this patc

Re: [PATCHv5] submodule deinit: require '--all' instead of '.' for all submodules

to check for the corner case of an empty repository. [...] > Signed-off-by: Stefan Beller <sbel...@google.com> Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to major

Re: [PATCHv4] submodule deinit: require '--all' instead of '.' for all submodules

Junio C Hamano wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> I mean low level as in implementation detail. The human user would >> wonder "what is incompatible about them? Why are you stopping me from >> what I am trying to do?" > > May

Re: [PATCHv4] submodule deinit: require '--all' instead of '.' for all submodules

Stefan Beller wrote: > On Wed, May 4, 2016 at 4:26 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: >> I think this paragraph could be removed. --all is explained lower >> down and the error message points it out to users who need it. > > When we want to keep supp

Re: [PATCHv4] submodule deinit: require '--all' instead of '.' for all submodules

Hi, Stefan Beller wrote: > Signed-off-by: Stefan Beller > --- > * reworded commit message slightly (realize, pathspec) > * reworded the documentation Yay, thanks for your work on this. [...] > +++ b/Documentation/git-submodule.txt > @@ -13,7 +13,7 @@ SYNOPSIS >

Re: [PATCHv2] submodule deinit: require '--all' instead of '.' for all submodules

Stefan Beller wrote: [...] >>$ rungit v2.6.6 submodule deinit . >>error: pathspec '.' did not match any file(s) known to git. >>Did you forget to 'git add'? >>$ >file && git add file >>$ rungit v2.6.6 submodule deinit . >>$ echo $? >>0 > >

Re: [RFD/PATCH] submodule doc: describe where we can configure them

Stefan Beller wrote: > This is similar to the gitignore document, but doesn't mirror > the current situation. It is rather meant to start a discussion for > the right approach for mirroring repositories with submodules. Ooh. [...] > --- a/Documentation/git-submodule.txt > +++

Re: [PATCH] send-email: do not load Data::Dumper

off-by: Eric Wong <normalper...@yhbt.net> > --- > While I'm in the area... > > git-send-email.perl | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks. -- To unsubscribe from this list: send the line "unsubscribe git

Re: [PATCH 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

Junio C Hamano wrote: > Both sounds sensible. Should we squash this in, then? > > t/t1300-repo-config.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks. -- To unsubscribe from this list: send the lin

Re: [PATCH] git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS

the unparseable value and fail. > > We can easily fix it by catching this case on the generating > side. While we're adding a test, let's also check that > multiple layers of "git -c" work, which was previously not > tested at all. > > Reported-by: Jonathan Nieder

Re: [PATCH v6 7/7] git: submodule honor -c credential.* from command line

Hi, Jacob Keller wrote: > Due to the way that the git-submodule code works, it clears all local > git environment variables before entering submodules. This is normally > a good thing since we want to clear settings such as GIT_WORKTREE and > other variables which would affect the operation of

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

impler and works now. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

Johannes Schindelin wrote: > --- a/t/t1300-repo-config.sh > +++ b/t/t1300-repo-config.sh > @@ -699,17 +699,13 @@ test_expect_success 'invalid unit' ' > echo 1auto >expect && > git config aninvalid.unit >actual && > test_cmp expect actual && > - cat >expect <<-\EOF && > -

Re: [PATCHv20 00/12] Expose submodule parallelism to the user

Stefan Beller wrote: > I added your suggestions as amending and as a new patch. I think we're at the point where patches on top would work better. I admit I was a little scared to see another reroll. [...] > --- a/builtin/submodule--helper.c > +++ b/builtin/submodule--helper.c > @@ -299,10

Re: [PATCHv19 00/11] Expose submodule parallelism to the user

Stefan Beller wrote: > Thanks Jonathan (and all the other cc'd reviewers) for bearing > yet another revision! Thanks. This one looks good. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body

Re: [PATCHv18 00/11] Expose

Stefan Beller wrote: > On Thu, Feb 25, 2016 at 3:19 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > > Now that I look around more, it seems that other submodule--helper > > subcommands > > have the same strange behavior of overwriting the 'prefix' var. So I

Re: [PATCHv18 00/11] Expose

Stefan Beller wrote: > Interdiff to v17: Except for the bit about 'prefix', Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at htt

Re: [PATCHv18 00/11] Expose

Stefan Beller wrote: > --- a/builtin/submodule--helper.c > +++ b/builtin/submodule--helper.c > @@ -465,14 +465,14 @@ static int update_clone(int argc, const char **argv, > const char *prefix) > NULL > }; > > - argc = parse_options(argc, argv, prefix,

Re: [PATCHv16 0/7] Expose submodule parallelism to the user

Stefan Beller wrote: > This build on top of 163b9b1f919c762a4bfb693b3aa05ef1aa627fee > (origin/sb/submodule-parallel-update~5) and replace the series from there on. Except for the comments in patch 3, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks for writing it and sorr

Re: [PATCH 3/7] run_processes_parallel: rename parameters for the callbacks

Stefan Beller wrote: > +++ b/run-command.h > @@ -159,7 +159,7 @@ typedef int (*get_next_task_fn)(struct child_process *cp, > * the negative signal number. > */ > typedef int (*start_failure_fn)(struct child_process *cp, > - struct strbuf *err, > +

Re: [PATCHv15 2/5] run_processes_parallel: add LF when caller is sloppy

Stefan Beller wrote: > On Wed, Feb 24, 2016 at 1:19 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > > Stefan Beller wrote: >>> When the callers of parallel processing machine are sloppy with their >>> messages, make sure the output is terminated with LF after

Re: [PATCHv15 2/5] run_processes_parallel: add LF when caller is sloppy

Stefan Beller wrote: > When the callers of parallel processing machine are sloppy with their > messages, make sure the output is terminated with LF after one child > process is handled. Why not always add \n here? That would make callers simpler and would make it easier for callers to know what

Re: [PATCHv14 5/7] git submodule update: have a dedicated helper for cloning

Stefan Beller wrote: > On Fri, Feb 19, 2016 at 3:07 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: [...] >>> + strbuf_addf(err, "Skipping submodule '%s'\n", >>> + displaypath); >> >> Does the caller expect a

Re: [PATCHv14 5/7] git submodule update: have a dedicated helper for cloning

Hi, Stefan Beller wrote: > This introduces a new helper function in git submodule--helper > which takes care of cloning all submodules, which we want to > parallelize eventually. Patches 1-4 are still Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> I still have trouble rea

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Junio C Hamano wrote: > I somehow doubt it. Both index-pack and lost-found need to trace > "object A depends on object B", but the similarity ends there. You already responded about this in another side-thread, so the following is mostly redundant. :) I think this message can still be useful

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Stefan Beller wrote: > On Wed, Feb 10, 2016 at 12:11 PM, Shawn Pearce wrote: >> Several of us at $DAY_JOB talked about this more today and thought a >> variation makes more sense: >> >> 1. Clients attempting clone ask for /info/refs?service=git-upload-pack >> like they do

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Jeff King wrote: > On Wed, Feb 10, 2016 at 12:11:46PM -0800, Shawn Pearce wrote: >> Several of us at $DAY_JOB talked about this more today and thought a >> variation makes more sense: >> >> 1. Clients attempting clone ask for /info/refs?service=git-upload-pack >> like they do today. >> >> 2.

Re: [PATCHv9 3/6] fetching submodules: respect `submodule.fetchJobs` config option

Hi, Stefan Beller wrote: > +++ b/submodule.c [...] > @@ -169,7 +170,13 @@ void set_diffopt_flags_from_submodule_config(struct > diff_options *diffopt, > > int submodule_config(const char *var, const char *value, void *cb) > { > - if (starts_with(var, "submodule.")) > + if

Re: [PATCHv9 2/6] submodule-config: drop check against NULL

Stefan Beller wrote: > Signed-off-by: Stefan Beller <sbel...@google.com> > --- > submodule-config.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> -- To unsubscribe from this list: send the line "

Re: [PATCHv9 1/6] submodule-config: keep update strategy around

SM_UPDATE_COMMAND, > + SM_UPDATE_UNSPECIFIED > +}; If _UNSPECIFIED is equal to 0, that would futureproof this better against zero-initialized submodule structs without ->update explicitly set. After those two changes and the whitespace change Junio suggested, Reviewed-by: Jonathan Nied

Re: [PATCHv9 4/6] git submodule update: have a dedicated helper for cloning

Stefan Beller wrote: > This introduces a new helper function in git submodule--helper > which takes care of cloning all submodules, which we want to > parallelize eventually. Neat. [...] > As we can only access the stderr channel from within the parallel > processing engine, we need to reroute

Re: [RFC] On the --depth argument when fetching with submodules

Hi, Stefan Beller wrote: > 1) You work on the superproject and don't care about the submodules. > In this case you want the superproject non-shallow and the submodules > may be just fine with depth 1. (Think of libraries pulled in via Git instead > of via the build system) > > 2) The

Re: [PATCHv8 1/9] submodule-config: keep update strategy around

Stefan Beller wrote: > On Thu, Feb 4, 2016 at 4:59 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: >> Stefan Beller wrote: >>> +++ b/submodule-config.h >>> @@ -14,6 +14,7 @@ struct submodule { >>> + const char *update; >> >> gitmodules(5)

Re: [PATCHv8 4/9] submodule-config: slightly simplify lookup_or_create_by_name

Stefan Beller wrote: > No need for a strbuf, when all we use it for, is duplicating a string. > > Signed-off-by: Stefan Beller <sbel...@google.com> > --- > submodule-config.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) Reviewed-by: Jonathan Ni

Re: [PATCHv8 3/9] submodule-config: remove name_and_item_from_var

Hi, Stefan Beller wrote: > --- a/submodule-config.c > +++ b/submodule-config.c > @@ -251,18 +235,19 @@ static int parse_config(const char *var, const char > *value, void *data) > { > struct parse_config_parameter *me = data; > struct submodule *submodule; > - struct strbuf name

Re: [PATCHv8 5/9] submodule-config: introduce parse_generic_submodule_config

Hi, Stefan Beller wrote: > This rewrites parse_config to distinguish between configs specific to > one submodule and configs which apply generically to all submodules. > We do not have generic submodule configs yet, but the next patch will > introduce "submodule.fetchJobs". Does this mean that

Re: [PATCHv8 2/9] submodule-config: drop check against NULL

sbel...@google.com> > --- > submodule-config.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Thanks. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord..

Re: [PATCHv8 1/9] submodule-config: keep update strategy around

Hi, It's been a while since I looked at this series. Hopefully I can come at it with some fresh eyes. Thanks for your perseverance. Stefan Beller wrote: > We need the submodule update strategies in a later patch. This description doesn't explain what the patch will do or why parse_config

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

Jeff King wrote: > Git packfiles come from two places: > > 1. Local maintenance repacks loose and already-packed objects into a > new packfile. We trust the local repack process to generate a valid > packfile (though the contents of individual objects may be > untrusted, of

Re: [PATCH 00/10] use the $( ... ) construct for command substitution

Elia Pinto wrote: > This is the second series, the other will be sent separately. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majo

Re: [PATCH 00/10] use the $( ... ) construct for command substitution

Elia Pinto wrote: > This is the first series, the other will be sent separately. FWIW, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majo

Re: [PATCH 15/16] refs: add LMDB refs backend

David Turner wrote: > On Wed, 2015-12-16 at 17:00 -0800, Jonathan Nieder wrote: >> David Turner wrote: >>> +core.refsBackendType:: >>> + Type of refs backend. Default is to use the original files >>> + based backend. Set to 'lmdb' to activate the lmdb d

Re: [PATCH 15/16] refs: add LMDB refs backend

David Turner wrote: > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -496,6 +496,13 @@ core.repositoryFormatVersion:: > Internal variable identifying the repository format and layout > version. > > +core.refsBackendType:: > + Type of refs backend. Default

Re: Why does send-pack call pack-objects for all remote refs?

Jeff King wrote: > Hmm. I guess that makes sense. The bitmap we want is the set difference > between the objects we are sending, and the tips the other side has. If > we have a bitmap at each ref tip, that's very fast. But if you have a > very large number of refs, we don't make one for each ref,

Re: [PATCH 0/2] git-candidate: git based patch tracking and review

Michael Haggerty wrote: > On 11/10/2015 01:56 PM, Richard Ipsum wrote: >> I've continued my work[1] to add patch tracking and candidate review >> capability >> to git. >> >> git-candidate now has a more git-like user interface, so remote candidates >> can now be specified in a similar way to

Re: Dependency query regarding contrib scripts

Richard Ipsum wrote: > Having read the docs for integrating new subcommands into git[1] I am looking > for some clarification of the following, > > "While we strongly encourage coding in portable C for portability, > these [C, shell, perl] specific scripting languages are also acceptable. > We

Re: [PATCHv2] run-command: detect finished children by closed pipe rather than waitpid

Stefan Beller wrote: > Detect if a child stopped working by checking if their stderr pipe > was closed instead of checking their state with waitpid. > As waitpid is not fully working in Windows, this is an approach which > allows for better cross platform operation. (It's less code, too) Can you

Re: [PATCH 3/6] Facilitate debugging Git executables in tests with gdb

Jeff King wrote: > Somebody suggested elsewhere that the name "gdb" be configurable. We > could stick that in the same variable, like: > > test "$GIT_TEST_GDB" = 1 && GIT_TEST_GDB=gdb > exec ${GIT_TEST_GDB} --args ... > > but that does not play well with the "debug" function, which does not >

Re: [PATCH 3/6] Facilitate debugging Git executables in tests with gdb

Johannes Schindelin wrote: > On Tue, 27 Oct 2015, Johannes Schindelin wrote: >> On Mon, 26 Oct 2015, Jonathan Nieder wrote: >>> Does the 'exec' after the fi need this as well? exec is supposed to >>> itself print a message and exit when it runs into an error. [...

Re: [PATCH 3/6] Facilitate debugging Git executables in tests with gdb

- From: Johannes Schindelin <johannes.schinde...@gmx.de> Subject: Facilitate debugging Git executables in tests with gdb When prefixing a Git call in the test suite with 'debug ', it will now be run with GDB, allowing the developer to debug test failures more conveniently. Signed-off-by: Joh

Re: [PATCH 1/9] submodule-config: "goto" removal in parse_config()

Hi, Stefan Beller wrote: > Subject: submodule-config: "goto" removal in parse_config() > > Many components in if/else if/... cascade jumped to a shared > clean-up with "goto release_return", but we can restructure the > function a bit and make them disappear, Not having read the patch yet, the

Re: [PATCH 3/6] Facilitate debugging Git executables in tests with gdb

Johannes Schindelin wrote: > When prefixing a Git call in the test suite with 'TEST_GDB_GIT=1 ', it > will now be run with GDB, allowing the developer to debug test failures > more conveniently. Neat. [...] > --- a/wrap-for-bin.sh > +++ b/wrap-for-bin.sh > @@ -19,4 +19,11 @@

Re: [PATCH v4 1/1] Makefile: make curl-config path configurable

Remi Pommarel wrote: > Signed-off-by: Remi Pommarel <r...@triplefau.lt> > Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Yep. ;) Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org

Re: [PATCH v4 1/1] Makefile: link libcurl before zlib

Remi Pommarel wrote: > Signed-off-by: Remi Pommarel <r...@triplefau.lt> Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org Mor

Re: [PATCH] usage: do not insist that standard input must come from a file

Junio C Hamano wrote: > The synopsys text and the usage string of subcommands that read list nit: s/synopsys/synopsis/ [...] > +++ b/Documentation/git-cat-file.txt > @@ -10,7 +10,7 @@ SYNOPSIS > > [verse] > 'git cat-file' (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e |

Re: [PATCH] usage: do not insist that standard input must come from a file

Junio C Hamano wrote: > Here is what I prepared based on your review in an interdiff form. For what it's worth, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@v

<    7   8   9   10   11   12   13   14   15   16   >