Re: [RFC/PATCH] drop vcs-svn experiment

Hi, Jeff King wrote: > The code in vcs-svn was started in 2010 as an attempt to > build a remote-helper for interacting with svn repositories > (as opposed to git-svn). However, we never got as far as > shipping a mature remote helper, and the last substantive > commit was e99d012a6bc in 2012.

Re: [PATCH] gpg-interface.c: detect and reject multiple signatures on commits

Michał Górny wrote: > On Wed, 2018-08-15 at 14:31 -0700, Jonathan Nieder wrote: >> It's not clear to me that the name is_status or SIGNATURE_STATUS >> captures what this field represents. Aren't these all sigcheck >> statuses? Can you describe briefly what distingu

Re: [PATCH/RFC] commit: add short option for --amend

Nguyễn Thái Ngọc Duy wrote: > --- a/builtin/commit.c > +++ b/builtin/commit.c > @@ -1489,7 +1489,7 @@ int cmd_commit(int argc, const char **argv, const char > *prefix) > STATUS_FORMAT_LONG), > OPT_BOOL('z', "null", _termination, >

Re: [PATCH] Makefile: extend NO_TCLTK=NoThanks to cover docs

Hi, Ævar Arnfjörð Bjarmason wrote: > Extend the NO_TCLTK=NoThanks flag to be understood by the > Documentation Makefile. > > Before this change compiling and installing with NO_TCLTK would result > in no git-gui, gitk or git-citool being installed, but their > respective manual pages would still

Re: git-clone removes destination path after permission deny

Hi, Agis wrote: > On 16 Aug 2018, at 15:08, Agis wrote: >>$ mkdir foo >>$ git clone g...@github.com:agis/private.git foo >>Cloning into 'foo'... >>Permission denied (publickey). >>fatal: Could not read from remote repository. [...] >>$ ls foo >>ls: cannot access

Re: [PATCH 2/2] submodule: munge paths to submodule git directories

Stefan Beller wrote: > Jonathan Nieder wrote: >> All at the cost of recording a little configuration somewhere. If we >> want to decrease the configuration, we can avoid recording it there in >> the easy cases (e.g. when name == gitdirname). That's "just" an &

Re: [PATCH 2/2] submodule: munge paths to submodule git directories

Hi again, Stefan Beller wrote: > On Tue, Aug 14, 2018 at 2:12 PM Jonathan Nieder wrote: >> What if we forbid directory separator characters in the gitdirname? > > Fine with me, but ideally we'd want to allow sharding the > submodules. When you have 1000 submodules > w

Re: [PATCH] gpg-interface.c: detect and reject multiple signatures on commits

Michał Górny wrote: > GnuPG supports creating signatures consisting of multiple signature > packets. If such a signature is verified, it outputs all the status > messages for each signature separately. However, git currently does not > account for such scenario and gets terribly confused over

Re: Potential vulnerability: 'mixed up' output when commit has multiple signatures

Michał Górny wrote: > On Tue, 2018-08-14 at 22:35 -0700, Jonathan Nieder wrote: > > Michał Górny wrote: >>> I've been testing the git signature verification a bit and I've >>> discovered a troubling behavior when the commit object contains >>> multiple sign

Re: [PATCHv4 0/6] Add missing includes and forward declares

Elijah Newren wrote: > 62 files changed, 152 insertions(+), 18 deletions(-) All 6 patches in this series are Reviewed-by: Jonathan Nieder Thanks for your patient work. Pointer to previous rounds for the curious: https://public-inbox.org/git/20180811043218.31456-1-new...@gmail.com/

Re: [PATCHv4 6/6] Remove forward declaration of an enum

gt; +#include "cache.h" > #include "oidset.h" > > /* in object-store.h */ > struct packed_git; > struct object_info; Not about this patch: comments like the above are likely to go stale, since nothing verifies they continue to be true. So we should remove them. #leftoverbits Reviewed-by: Jonathan Nieder

Re: [PATCHv4 2/6] alloc: make allocate_alloc_state and clear_alloc_state more consistent

Elijah Newren wrote: > Since both functions are using the same data type, they should either both > refer to it as void *, or both use the real type (struct alloc_state *). > Opt for the latter. > > Reviewed-by: Jonathan Nieder > Signed-off-by: Elijah Newren N

Re: [PATCHv4 1/6] Add missing includes and forward declarations

Elijah Newren wrote: [...] > Signed-off-by: Elijah Newren > --- [...] > 55 files changed, 132 insertions(+), 4 deletions(-) Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCHv3 1/6] Add missing includes and forward declares

nsible to me. [...] > On Tue, Aug 14, 2018 at 10:10 PM Jonathan Nieder wrote: >> Is there an easy way to review it? (Keep in mind that I'm super lazy. >> ;-)) > > I guess I could send you my hacky python script that loops through the > top-level header files and creates the du

Re: [PATCHv3 6/6] Add missing includes and forward declares

Hi, Elijah Newren wrote: > Signed-off-by: Elijah Newren > --- > bisect.h | 2 ++ > pack-objects.h | 1 + > 2 files changed, 3 insertions(+) Do you have more context about why these are in a separate commit? For pack-objects.h, I think you might be making a fix to the cc/delta-islands

Re: [PATCHv3 5/6] compat/precompose_utf8.h: use more common include guard style

Elijah Newren wrote: > Signed-off-by: Elijah Newren > --- > compat/precompose_utf8.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Jonathan Nieder The more unusual style is less likely to be recognized by compilers, so we can waste some I/O re-readin

Re: [PATCHv3 4/6] urlmatch.h: fix include guard

Elijah Newren wrote: > Signed-off-by: Elijah Newren > --- > urlmatch.h | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Jonathan Nieder This has two benefits: - avoids the definitions in this header from being evaluated twice - many compilers recognize the #include

Re: [PATCHv3 3/6] Move definition of enum branch_track from cache.h to branch.h

ned-off-by: Elijah Newren > --- > branch.h | 11 +++ > cache.h | 10 -- > config.c | 1 + > environment.c | 1 + > 4 files changed, 13 insertions(+), 10 deletions(-) \o/ Reviewed-by: Jonathan Nieder

Re: [PATCHv3 2/6] alloc: make allocate_alloc_state and clear_alloc_state more consistent

e right thing to do. Thanks for noticing and fixing it. That commit in turn was probably inspired by v1.5.2-rc0~16^2 (Clean up object creation to use more common code, 2007-04-16), which was following the same convention (void * for raw memory, struct blob * for initialized object). Reviewed-by: Jonathan Nieder

Re: [PATCHv3 1/6] Add missing includes and forward declares

Elijah Newren wrote: > Subject: Add missing includes and forward declares nit: s/declares/declarations/ This is a huge patch. Was it autogenerated or generated manually? Can the commit message say something about methodology? Is there an easy way to review it? (Keep in mind that I'm super

Re: [PATCH 0/9] Add missing includes and forward declares

include first). I wonder if it would not be simpler to change them all. It would be one less special case. That said, > Signed-off-by: Jeff King > --- > t/helper/test-tool.h | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH 0/9] Add missing includes and forward declares

Jeff King wrote: > On Mon, Aug 13, 2018 at 11:24:37AM -0700, Junio C Hamano wrote: >> Jeff King wrote: >>> So I think the better test is a two-line .c file with: >>> >>> #include "git-compat-util.h" >>> #include $header_to_check >> >> But until that tightening happens, I do not actually mind

Re: [PATCH 1/2] store submodule in common dir

Junio C Hamano wrote: > Theoretically we should be able to make modules/kernel%2fv2.[24] > additional "worktree"s of modules/kernel%2fv2.6, but given that > these are all "bare" repositories without an attached working tree, > I am not sure how that would supposed to work. Thinking about >

Re: [PATCH] partial-clone: render design doc using asciidoc

Hi, Stefan Beller wrote: > On Tue, Aug 14, 2018 at 3:28 PM Jonathan Nieder wrote: >> repack in GC has been updated to not touch promisor >> packfiles at all, and to only repack other objects. > > We'd need to adapt this documentation in Jonathans series? Yes, or in a se

Re: git submodule: 3 modules same git repo?

Hi, Joakim Tjernlund wrote: > I am trying to create 3 submodules from the same git repo, each pointing to a > different branch. > Since the repo is somewhat large, I don't want the 3 submodules to clone the > same repo 3 > times, I want one clone and then have the 3 submodules to point to

[PATCH] partial-clone: render design doc using asciidoc

the output in a browser. Signed-off-by: Jonathan Nieder --- Today I noticed that this document wasn't available at https://www.kernel.org/pub/software/scm/git/docs/technical/partial-clone.html, so I wrote this patch. Thoughts of all kinds welcome, as always. Documentation/Makefile

Re: [PATCH 2/2] submodule: munge paths to submodule git directories

Hi, Stefan Beller wrote: > On Tue, Aug 14, 2018 at 11:57 AM Jonathan Nieder wrote: >> Second, what if we store the pathname in config? We already store the >> URL there: >> >> [submodule "plugins/hooks"] >> url = https://gerrit

Re: [PATCH 2/2] submodule: munge paths to submodule git directories

Hi, Brandon Williams wrote: > On 08/09, Jeff King wrote: >> One interesting thing about url-encoding is that it's not one-to-one. >> This case could also be %2F, which is a different file (on a >> case-sensitive filesystem). I think "%20" and "+" are similarly >> interchangeable. >> >> If we

Re: [PATCH] git-submodule.sh: accept verbose flag in cmd_update to be non-quiet

t; -q|--quiet) > GIT_QUIET=1 > ;; > + -v) > + GIT_QUIET=0 > + ;; Reviewed-by: Jonathan Nieder Thanks.

Re: 'git submodule update' ignores [http] config

+cc: Stefan, who has been looking at fetch --recurse-submodules recently Hi, Jonathon Reinhart wrote: > I've narrowed it down to an observation that the [http] config seems > to be ignored by 'git submodule update'. Shouldn't those options be > respected by submodules? > > Given a .git/config

Re: What's the use case for committing both the freshly created file and it's exclusion in .gitignore?

Hi, Jeff King wrote: > Bartosz Konikiewicz wrote: >> Steps to reproduce: >> >> 1. Create a new file. >> 2. Stage the file. >> 3. Add the file to .gitignore. >> 4. Stage the .gitignore. >> 5. Commit changes. [...] > As far as I know, that is not an intentionally supported workflow. It is > merely

Re: [RFC] submodule: munge paths to submodule git directories

Hi, Brandon Williams wrote: > Commit 0383bbb901 (submodule-config: verify submodule names as paths, > 2018-04-30) introduced some checks to ensure that submodule names don't > include directory traversal components (e.g. "../"). > > This addresses the vulnerability identified in 0383bbb901 but

Re: [PATCH] Documentation/diff-options: explain different diff algorithms

Hi, Stefan Beller wrote: > --- a/Documentation/diff-options.txt > +++ b/Documentation/diff-options.txt > @@ -91,14 +91,18 @@ appearing as a deletion or addition in the output. It > uses the "patience > diff" algorithm internally. > > --diff-algorithm={patience|minimal|histogram|myers}:: > -

Re: [PATCH] Makefile: enable DEVELOPER by default

Hi, Jeff King wrote: > I had the impression that DEVELOPER=1 was allowed to set flags that old > versions might not even know about. Hence they might actually barf, even > without -Werror. Yes. [...] > We're developers ourselves, and we interact with new developers that we > want to help. But

Re: Fetch on submodule update

Robert Dailey wrote: > Automatic would be > great if submodules were treated as integrated in a similar manner to > subtree, but it's not there. I wasn't aware that `submodule update` > did a fetch, because sometimes if I do that, I get errors

Re: [PATCH 1/4] line-log: demonstrate a bug with nearly-overlapping ranges

Jonathan Nieder wrote: > Johannes Schindelin wrote: >> It is really, really important to realize how valuable it is to have the >> regression test as an individual patch that can be used to verify that >> there is a bug, to pinpoint where it was introduced, to test alternat

Re: [PATCH] add a script to diff rendered documentation

Jeff King wrote: > 3. Default to number of CPUs, which is what a lot of other threading > in Git does. Unfortunately getting that from the shell is > non-trivial. I'm OK with $(grep -c ^processor /proc/cpuinfo), but > people on non-Linux platforms would have to fill in their own

Re: [PATCH 1/4] line-log: demonstrate a bug with nearly-overlapping ranges

Hi Dscho, Johannes Schindelin wrote: > On Sat, 4 Aug 2018, Jonathan Nieder wrote: >> Alternatively, could it be squashed in with the patch that fixes it? > > There is this really awful trend on this mailing list to suggest > conflating the demonstration of a bu

Re: concurrent access to multiple local git repos is error prone

(administrivia: please don't top-post) Hi Alex, Alexander Mills wrote: > Yeah this concurrency problem is real. Not only does it happen with > `git status` the same thing happens with `git rev-parse > --show-toplevel`. Sorry for the confusion --- I didn't mean to claim your experience was not

Re: [PoC] coccinelle: make Coccinelle-related make targets more fine-grained

Hi, Jeff King wrote: > On Thu, Aug 02, 2018 at 11:21:44PM -0700, Jonathan Nieder wrote: >> Jeff King wrote: >>> I guess you could even replace "COCCI_COMBINED" with "COCCI_PATCH" in >>> most of the targets, and that would let people do individual

Re: git worktree add prints to stdout

Hi, Thomas Gummerer wrote: > git 2.18.0 should print both of those lines to stdout. This was done > to match where 'git reset --hard' prints the 'HEAD is now at...' > message. See also the thread at [1] where we did make that decision. > > [1]: >

Re: concurrent access to multiple local git repos is error prone

Alexander Mills wrote: > Yeah in this case what appeared to be happening is that if `git status` was > called concurrently, frequently I wouldnt get any stdout.. Thanks for reporting. A few questions: What platform are you on? What version of Git are you running? What is the output of "git

Re: [PATCH] Makefile: enable DEVELOPER by default

Hi, Eric Sunshine wrote: > On Sat, Aug 4, 2018 at 11:17 PM Jonathan Nieder wrote: >>> utf8.c:486:28: warning: passing 'iconv_ibp *' (aka 'const char **') to >>> parameter >>> of type 'char **' discards qualifiers in nested pointer types >>>

Re: [PATCH 1/1] t/test-lib: make `test_dir_is_empty` more robust

William Chargin wrote: > Jonathan Nieder wrote: >> This subject line will appear out of context in "git shortlog" output, >> so it's useful to pack in enough information to briefly summarize what >> the change does. > > I'm happy to do so. I think t

Re: [PATCH 1/1] t/test-lib: make `test_dir_is_empty` more robust

Hi, Junio C Hamano wrote: > Jonathan Nieder writes: >> but $'' is too recent of a shell feature to count on (e.g., dash doesn't >> support it). See t/t3600-rm.sh for an example of a portable way to do > > Is that "too recent"? I thought it was bashism,

Re: concurrent access to multiple local git repos is error prone

Hi, Alexander Mills wrote: > Yeah as long as git shouldnt fumble wrt concurrent access across repos, it > was most likely the same repo being accessed concurrently and that's what > was causing the issue. > > that being said, it would be really nice if git itself could handle > concurrent

Re: [PATCH 1/1] t/test-lib: make `test_dir_is_empty` more robust

Hi, William Chargin wrote: > Subject: t/test-lib: make `test_dir_is_empty` more robust This subject line will appear out of context in "git shortlog" output, so it's useful to pack in enough information to briefly summarize what the change does. How about something like

Re: [PATCH 0/1] t/test-lib: make `test_dir_is_empty` more robust

Hi, William Chargin wrote: > While the `test_dir_is_empty` function appears correct in most normal > use cases, it can fail when filenames contain newlines. This information belongs in the commit message, since it's useful context for understanding the motivation behind the patch when

Re: How to push using SSH and pull using HTTPS for all repos on GitHub?

Jeffrey Walton wrote: > On Sat, Aug 4, 2018 at 9:26 PM, Jonathan Nieder wrote: >> Jeffrey Walton wrote: >>> I'm having trouble setting up my ~/.gitconfig to push using SSH and >>> pull using HTTPS for all repos on GitHub. The idea is, no passwords on >>> pull

Re: [PATCH] Makefile: enable DEVELOPER by default

Eric Sunshine wrote: > And, compilation warnings are not limited to old compilers. Even my > fully up-to-date FreeBSD 11.2 installation is not warning-free[1]. > > [1]: For instance: > utf8.c:486:28: warning: passing 'iconv_ibp *' (aka 'const char **') to > parameter > of type 'char **'

Re: [PATCH 1/4] line-log: demonstrate a bug with nearly-overlapping ranges

Hi, Johannes Schindelin wrote: > Currently, this test case throws an assertion: > > Assertion failed! > > Program: git.exe > File: line-log.c, Line 71 > > Signed-off-by: Johannes Schindelin > --- > t/t4211-line-log.sh | 17 + > 1 file changed, 17 insertions(+)

Re: concurrent access to multiple local git repos is error prone

Hi Alexander, Alexander Mills wrote: > On Sat, Aug 4, 2018 at 2:47 PM, Alexander Mills > wrote: >> I assume that access more than 1 git repo concurrently on a local >> machine is not without errors. However this seems like a huge >> limitation or design flaw. >> >> Is my observation correct?

Re: [RFC PATCH 0/1] Introduce git-recover

Hi, Edward Thomson wrote: > I created a simple shell script a while back to help people recover > files that they deleted from their working directory (but had been added > to the repository), which looks for unreachable blobs in the object > database and places them in the working directory

Re: How to push using SSH and pull using HTTPS for all repos on GitHub?

Hi, Jeffrey Walton wrote: > I'm having trouble setting up my ~/.gitconfig to push using SSH and > pull using HTTPS for all repos on GitHub. The idea is, no passwords on > pulls and only use the password for push. > > I've got the first part of the equation using the following in my >

Re: [PATCH v2 2/2] doc hash-function-transition: pick SHA-256 as NewHash

arlson Acked-by: Johannes Schindelin Acked-by: Dan Shumow Signed-off-by: Jonathan Nieder --- Hi, Ævar Arnfjörð Bjarmason wrote: > I think it makes if you just take over 2/2 of this series (or even the > whole thing), since the meat of it is already something I copy/pasted > from yo

Re: [PATCH] pack-objects: document about thread synchronization

d delta search - 2007-09-06) >> 384b32c09b (pack-objects: fix threaded load balancing - 2007-12-08) >> 50f22ada52 (threaded pack-objects: Use condition... - 2007-12-16) > > Thanks, I think this is an improvement. Yes, Reviewed-by: Jonathan Nieder as well. Usually I would prefer to see comme

Re: [PATCH] Makefile: enable DEVELOPER by default

Hi, Stefan Beller wrote: > Reviewer bandwidth is limited, so let's have the machine of the > (potentially new) contributor warn about issues with the code by default. > > As setting DEVELOPER, the compiler is stricter and we may run into problems > on some architectures. But packagers of said

Re: [PATCH v2 2/2] doc hash-function-transition: pick SHA-256 as NewHash

re.crustytoothpaste.net/ > 2. > https://public-inbox.org/git/ca+55afwse9bf8e0hlk9pp3fvd5lavy5grdsv3fbntgzekja...@mail.gmail.com/ > 3. https://public-inbox.org/git/xmqqzhygwd5o@gitster-ct.c.googlers.com/ Footnotes to the historical part --- I'd recommend removing these. > Helped-by:

Re: [PoC] coccinelle: make Coccinelle-related make targets more fine-grained

Hi, Jeff King wrote: > On Thu, Aug 02, 2018 at 02:01:55PM -0400, Jeff King wrote: >> I suspect if we go with the one-spatch-per-source route, though, that we >> could do this just with regular make rules. > > Yeah, it's pretty straightforward: > > diff --git a/Makefile b/Makefile > index

Re: [PATCH] color: protect against out-of-bounds array access/assignment

h descriptor in an array. However, it doesn't verify that the passed-in descriptor lives within that set, which, with a buggy caller, could lead to access or assignment outside the array bounds. Signed-off-by: Eric Sunshine Acked-by: Johannes Schindelin Signed-off-by: Jonathan Nieder --- colo

Re: [PATCH 2/2] sideband: highlight keywords in remote sideband output

Hi, Han-Wen Nienhuys wrote: > The colorization is controlled with the config setting "color.remote". > > Supported keywords are "error", "warning", "hint" and "success". They > are highlighted if they appear at the start of the line, which is > common in error messages, eg. > >ERROR: commit

Re: [PATCH 1/2] config: document git config getter return value.

char **dest); > extern int git_configset_get_int(struct config_set *cs, const char *key, int > *dest); With a sign-off and whatever subset of the above suggestions makes sense to you, Reviewed-by: Jonathan Nieder Thanks.

Re: Hash algorithm analysis

Hi Dan, Dan Shumow wrote: [replying out of order for convenience] > However, I agree with Adam Langley that basically all of the > finalists for a hash function replacement are about the same for the > security needs of Git. I think that, for this community, other > software engineering

Re: Question regarding quarantine environments

Hi, Jeff King wrote: > On Thu, Aug 02, 2018 at 12:58:52PM -0500, Liam Decker wrote: >> The solution that I implemented was to check the objects directory for the >> object, and if it was not there, to look for a quarantine directory and try >> there. However, that feels fairly inefficient. > >

Re: Fetch on submodule update

Hi again, Robert Dailey wrote: > Problem: I want to avoid recursively fetching submodules when I run a > `fetch` command, and instead defer that operation to the next > `submodule update`. Essentially I want `fetch.recurseSubmodules` to be > `false`, and `get submodule update` to do exactly what

Re: [PATCH] remote: clear string_list after use in mv()

word so the behavior is more obvious in the caller: string_list_clear(_branches, STRING_LIST_FREE_UTIL); Or maybe even having a separate function: string_list_clear_free_util(_branches); That's a topic for another day, though. With whatever subset of the changes suggested above makes sense, Reviewed-by: Jonathan Nieder Thanks for a pleasant read.

Re: [PATCH v2] remote: make refspec follow the same disambiguation rule as local refs

Junio C Hamano wrote: > One thing I forgot to mention. > > When asking to fetch T, in order to be able to favor refs/tags/T > over refs/heads/T at the fetching end, you would have to be able to > *see* both, so all 6 variants "T", "refs/tags/T", "refs/heads/T", > "refs/remotes/T",

Re: [PATCH v2] remote: make refspec follow the same disambiguation rule as local refs

return value convention. [...] > --- a/t/t5510-fetch.sh > +++ b/t/t5510-fetch.sh > @@ -535,6 +535,41 @@ test_expect_success "should be able to fetch with > duplicate refspecs" ' > ) > ' > > +test_expect_success 'LHS of refspec follows ref disambiguation rules' ' Clearly illustrates the bug this fixes, in a way that makes it obvious that a user would prefer the new behavior. Good. With or without the tweak of introducing NUM_REV_PARSE_RULES mentioned above, Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH] push: comment on a funny unbalanced option help

Hi, Junio C Hamano wrote: > Add a comment to save future readers from wasting time just like I > did ;-) Thanks. I think we should go further, and start the comment with TRANSLATORS so it shows up for the audience most affected by this as well. See the note on TRANSLATORS in po/README for

Re: Fetch on submodule update

Hi, Robert Dailey wrote: > Problem: I want to avoid recursively fetching submodules when I run a > `fetch` command, and instead defer that operation to the next > `submodule update`. Essentially I want `fetch.recurseSubmodules` to be > `false`, and `get submodule update` to do exactly what it

Re: [PATCH] t1404: increase core.packedRefsTimeout to avoid occasional test failure

Hi, SZEDER Gábor wrote: > While 3secs timeout seems plenty, and indeed is sufficient in most > cases, on rare occasions it's just not quite enough: I saw this test > fail in Travis CI build jobs two, maybe three times because 'git > update-ref' timed out. I suspect these tests will fail with

Re: [PATCH] remote: prefer exact matches when using refspecs

ef *get_remote_ref(const struct ref *remote_refs, const char *name) > diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh > index e402aee6a..da88f35f0 100755 > --- a/t/t5510-fetch.sh > +++ b/t/t5510-fetch.sh > @@ -535,6 +535,34 @@ test_expect_success "should be able to fet

Re: [PATCH] mw-to-git/t9360: fix broken &&-chain

A small detail from there would be useful to have in the commit message: namely that this was detected using --chain-lint (and what command I can run to reproduce it myself). With or without such a tweak to the commit message, Reviewed-by: Jonathan Nieder Thanks. > contrib/mw-to-git/t/t9360-mw-to-git-

Re: [PATCH v2 01/10] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells

Eric Sunshine wrote: > On Mon, Jul 30, 2018 at 2:14 PM Jonathan Nieder wrote: >> ( >> chks_sub=$(cat <> $chks >> TXT >> ) && >> >> Ugly quoting, useless use of "cat", etc, aside, I don't think

[PATCH 2/2] subtree test: simplify preparation of expected results

that its subshells use an unbroken &&-chain, causing "make -C contrib/subtree test" to fail with error: bug in the test script: broken &&-chain or run-away HERE-DOC: in t7900.21. Signed-off-by: Jonathan Nieder --- That's the end of the series. Thanks for

[PATCH 1/2] subtree test: add missing && to &&-chain

Detected using t/chainlint. Signed-off-by: Jonathan Nieder --- contrib/subtree/t/t7900-subtree.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh index d05c613c97..e6a28f2c3e 100755 --- a/contrib

[PATCH 0/2] subtree: fix &&-chain and simplify tests (Re: [PATCH v2 01/10] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells)

(resetting cc list) Jonathan Nieder wrote: > This is causing contrib/subtree tests to fail for me: running "make -C > contrib/subtree test" produces [...] > error: bug in the test script: broken &&-chain or run-away HERE-DOC: [...] > Ugly quoting, useless use

Re: [PATCH v2 01/10] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells

Hi, Eric Sunshine wrote: > The --chain-lint option detects broken &&-chains by forcing the test to > exit early (as the very first step) with a sentinel value. If that > sentinel is the test's overall exit code, then the &&-chain is intact; > if not, then the chain is broken. Unfortunately, this

Re: Proposed approaches to supporting HTTP remotes in "git archive"

(just cc-ing René Scharfe, archive expert; Peff; Dscho; Franck Bui-Huu to see how his creation is evolving. Using the correct address for René this time. Sorry for the noise.) Josh Steadmon wrote: > # Supporting HTTP remotes in "git archive" > > We would like to allow remote archiving from HTTP

Re: Proposed approaches to supporting HTTP remotes in "git archive"

(just cc-ing René Scharfe, archive expert; Peff; Dscho; Franck Bui-Huu to see how his creation is evolving) Josh Steadmon wrote: > # Supporting HTTP remotes in "git archive" > > We would like to allow remote archiving from HTTP servers. There are a > few possible implementations to be discussed:

Re: [PATCH v2] packfile: ensure that enum object_type is defined

de cache.h > instead to make sure the enum is defined. > > Helped-by: Jonathan Nieder > Signed-off-by: Beat Bolli > --- > packfile.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks! I had run into this using clang on Linux, too, but hadn't spent the ti

Re: [PATCH 2/2] doc hash-function-transition: pick SHA-256 as NewHash

Hi, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: >> The consensus on the mailing list seems to be that SHA-256 should be >> picked as our NewHash, see the "Hash algorithm analysis" thread as of >> [1]. Linus has come around to this choice and suggested Junio make the >> final pick,

Re: [PATCH] pack-protocol: mention and point to docs for protocol v2

Brandon Williams wrote: > If so I suggest we move away from the term "pack" protocol. Mostly > because maybe at some future date we don't only want to communicate to > transfer packs. So at the risk of bikeshedding (and because naming is > hard) I think we should begin talking about the over

Re: [PATCH] diff: --color-moved: rename "dimmed_zebra" to "dimmed-zebra"

ts or configuration they won't have to be mystified about why it works. I don't have any good ideas about deprecating more aggressively, and the patch looks good, so Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH 2/2] remote-odb: un-inline function remote_odb_reinit

Hi, Beat Bolli wrote: > When compiling under Apple LLVM version 9.1.0 (clang-902.0.39.2) with > "make DEVELOPER=1 DEVOPTS=pedantic", the compiler says > > remote-odb.c:87:2: error: static function 'remote_odb_do_init' is > used in an inline function with external linkage >

Re: [PATCH 1/2] packfile: drop a repeated enum declaration

Hi, Beat Bolli wrote: > --- a/packfile.h > +++ b/packfile.h > @@ -6,7 +6,6 @@ > /* in object-store.h */ > struct packed_git; > struct object_info; > -enum object_type; > > /* > * Generate the filename to be used for a pack file with checksum "sha1" and Good catch. This means packfile.h

Re: de-alphabetizing the documentation

Hi, frede...@ofb.net wrote: > Next week I should have time to send you a patch with the manual page > reordered... Yay! > although, unless you have a special 'diff' which can > detect when text has been moved from one place to another, I'm > guessing it would take you even longer

Re: Hash algorithm analysis

Hi, Linus Torvalds wrote: > On Tue, Jul 24, 2018 at 12:01 PM Edward Thomson > wrote: >> Switching gears, if I look at this from the perspective of the libgit2 >> project, I would also prefer SHA-256 or SHA3 over blake2b. To support >> blake2b, we'd have to include - and support - that code

Re: [PATCH] pack-protocol: mention and point to docs for protocol v2

Hi, Brandon Williams wrote: > --- a/Documentation/technical/pack-protocol.txt > +++ b/Documentation/technical/pack-protocol.txt > @@ -50,7 +50,8 @@ Each Extra Parameter takes the form of `=` or > ``. > > Servers that receive any such Extra Parameters MUST ignore all > unrecognized keys.

Re: [PATCH] Documentation/diff-options: explain different diff algorithms

Hi, Stefan Beller wrote: > As a user I wondered what the diff algorithms are about. Offer at least > a basic explanation on the differences of the diff algorithms. Interesting. Let's see. [...] > --- a/Documentation/diff-options.txt > +++ b/Documentation/diff-options.txt > @@ -94,16 +94,34 @@

Re: [PATCH] fetch-pack: mark die strings for translation

Brandon Williams wrote: > Signed-off-by: Brandon Williams > --- > fetch-pack.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH v6 8/8] fetch-pack: implement ref-in-want

Hi, Duy Nguyen wrote: > On Mon, Jul 23, 2018 at 7:53 PM Brandon Williams wrote: >> What criteria is used to determine if something should be translated? [...] > Besides drawing the line "benefit from (not) being translated" varies > from one developer to another. I think it's just easier and

Re: Hash algorithm analysis

Hi Yves, demerphq wrote: > On Sun, 22 Jul 2018 at 01:59, brian m. carlson > wrote: >> I will admit that I don't love making this decision by myself, because >> right now, whatever I pick, somebody is going to be unhappy. [...] > I do not envy you this decision. > > Personally I would aim

Re: [PATCH 2/9] vscode: hard-code a couple defines

Hi, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > Sadly, we do not get all of the definitions via ALL_CFLAGS. Some defines > are passed to GCC *only* when compiling specific files, such as git.o. > > Let's just hard-code them into the script for the time being.

Re: [PATCH 1/9] contrib: add a script to initialize VS Code configuration

Hi, Thanks for working on this. Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > VS Code is a lightweight but powerful source code editor which runs on > your desktop and is available for Windows, macOS and Linux. Among other > languages, it has support for C/C++ via

Re: Hash algorithm analysis

Hi, brian m. carlson wrote: > I know this discussion has sort of petered out, but I'd like to see if > we can revive it. I'm writing index v3 and having a decision would help > me write tests for it. Nice! That's awesome. > To summarize the discussion that's been had in addition to the

Re: [PATCH] clone: send ref-prefixes when using protocol v2

Hi, Brandon Williams wrote: > Signed-off-by: Brandon Williams > --- > Noticed we miss out on server side filtering of refs when cloning using > protocol v2, this will enable that. > > builtin/clone.c | 22 +- > 1 file changed, 17 insertions(+), 5 deletions(-) Nice! The

Re: [PATCH] gc: do not warn about too many loose objects

Hi Ævar, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jul 17 2018, Jonathan Nieder wrote: >> That suggests a possible improvement. If all callers should be >> ignoring the exit code, can we make the exit code in daemonize mode >> unconditionally zero in this kind of case?

[PATCH 3/3] gc: do not return error for prior errors in daemonized mode

behavior as tools like "git fetch" that ignore the exit status from gc --auto. Once the period of time described by gc.pruneExpire elapses, the unreachable loose objects will be removed by "git gc --auto" automatically. [1] https://gerrit-review.googlesource.com/c/git-repo/+/1

[PATCH 2/3] gc: exit with status 128 on failure

A value of -1 returned from cmd_gc gets propagated to exit(), resulting in an exit status of 255. Use die instead for a clearer error message and a controlled exit. Signed-off-by: Jonathan Nieder --- As in https://public-inbox.org/git/20180716225639.gk11...@aiede.svl.corp.google.com/. The only

<    1   2   3   4   5   6   7   8   9   10   >