Re: Updated to v2.14.2 on macOS; git add --patch broken

Hi, Toni Uebernickel wrote: > I updated to git version v2.14.2 on macOS using homebrew. > > Since then `git add --patch` and `git stash save --patch` are not > working anymore. It's just printing the complete diff without ever > stopping to ask for actions. This results in an unusable state, as

Re: hooks are ignored if there are not marked as executable

Hi Damien, Damien wrote: > If you do `echo my_script > .git/hooks/pre-commit` and then `git commit`, > The hook is just gonna be ignored. > But if you do `chmod +x .git/hooks/pre-commit`, then it's executed. This is intentional. > I think ignoring a hook is misleading and not newbie friendly,

Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

hat this change is going to do - how it's good for the internal code structure / maintainability What it doesn't tell me about is why the user-facing effect won't cause problems. Is there no atom where %(atom:) was previously accepted and did something meaningful that this may break? Looking at the

Re: git submodule add fails when using both --branch and --depth

Hi, Thadeus Fleming wrote: > I'm running git 2.14.2 on Ubuntu 16.04. > > Compare the behavior of > >> git clone --branch pu --depth 1 https://github.com/git/git git-pu > > which clones only the latest commit of the pu branch and Yes. >> mkdir tmp && cd tmp && git init >> git submodule add

Re: What means "git config bla ~/"?

Hi, rpj...@crashcourse.ca wrote: > i'm sure i'm about to embarrass myself but, in "man git-config", > OPTIONS, one reads: > > --path > > git-config will expand leading ~ to the value of $HOME, and ~user > to the home directory for the specified user. This option has no > effect when setting

Re: [PATCH] clang-format: adjust line break penalties

Stephan Beyer wrote: > On 09/29/2017 08:40 PM, Jonathan Nieder wrote: >> Going forward, is there an easy way to preview the effect of this kind >> of change (e.g., to run "make style" on the entire codebase so as to be >> able to compare the result with two differe

Re: [PATCH] clang-format: adjust line break penalties

Hi Dscho, Johannes Schindelin wrote: > Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> > --- > .clang-format | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Well executed and well explained. Thank you. Reviewed-by: Jonathan Nieder &

Re: [PATCH v4] technical doc: add a design doc for hash function transition

Junio C Hamano wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> This document describes what a transition to a new hash function for >> Git would look like. Add it to Documentation/technical/ as the plan >> of record so that future changes can be reco

Re: [PATCH] git-sh: Avoid sourcing scripts with git --exec-path

Junio C Hamano wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> This has been broken for a while, but better late than never to >> address it. > > I am not sure if this is broken in the first place. We do want to > make sure that the scripted porcelain

Re: [PATCH] git-sh: Avoid sourcing scripts with git --exec-path

Hi, Dridi Boukelmoune wrote: > For end users making use of a custom exec path many commands will simply > fail. Adding git's exec path to the PATH also allows overriding git-sh-* > scripts, not just adding commands. One can then patch a script without > tainting their system installation of git

Re: [PATCH] doc: correct command formatting

Junio C Hamano wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> Andreas Heiduk wrote: >>> +1, Thanks for spotting. >> >> Thanks for looking it over. Can we add your Reviewed-by? (See [1] >> for what this means.) > > I would just do

Re: [PATCH] doc: correct command formatting

Hi, Andreas Heiduk wrote: > +1, Thanks for spotting. Thanks for looking it over. Can we add your Reviewed-by? (See [1] for what this means.) > I did a quick > > grep -r " ` " > > which came up with with another relevant place: > > Documentation/git-format-patch.txt:

Re: [PATCH] doc: correct command formatting

a...@dinwoodie.org> > --- > Documentation/git.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Good catch. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

[PATCH v4] technical doc: add a design doc for hash function transition

oogle.com> Also-by: Stefan Beller <sbel...@google.com> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- On Thu, Mar 09, 2017 at 11:14 AM, Shawn Pearce wrote: > On Mon, Mar 6, 2017 at 4:17 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: >> Thanks for the kind wo

Re: [PATCH] diff: correct newline in summary for renamed files

t/t4013/diff.log_--decorate_--all | 6 ++ > 7 files changed, 35 insertions(+) > create mode 100644 t/t4013/diff.diff-tree_--stat_initial_mode > create mode 100644 t/t4013/diff.diff-tree_--summary_initial_mode > create mode 100644 t/t4013/diff.diff-tree_initial_mode Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: Updated to v2.14.2 on macOS; git add --patch broken

Jonathan Nieder wrote: > Jeff King wrote: >> There aren't a lot of changes to the script between v2.13.2 and v2.14.2. >> The most plausible culprit is d5addcf522 (add--interactive: handle EOF >> in prompt_yesno, 2017-06-21), but I'm scratching my head over how that >&

Re: Updated to v2.14.2 on macOS; git add --patch broken

Hi, Jeff King wrote: > On Wed, Sep 27, 2017 at 07:28:49PM +0200, Toni Uebernickel wrote: >> The previous version was v2.13.2. >> I switched back to this version, and it works perfectly fine; without any >> changes to my system. > > Thanks for confirming. > > There aren't a lot of changes to the

Re: RFC v3: Another proposed hash function transition plan

Hi, Johannes Schindelin wrote: > Sorry, you are asking cryptography experts to spend their time on the Git > mailing list. I tried to get them to speak out on the Git mailing list. > They respectfully declined. > > I can't fault them, they have real jobs to do, and none of their managers > would

Re: [PATCH] technical doc: add a design doc for hash function transition

Hi, Stefan Beller wrote: > From: Jonathan Nieder <j...@google.com> I go by jrnie...@gmail.com upstream. :) > This is "RFC v3: Another proposed hash function transition plan" from > the git mailing list. > > Signed-off-by: Jonathan Nieder <jrnie...@gmail.

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > What do you think of patch 7 in light of this? If the short-read case > gives us a sane errno, should we even bother trying to consistently > handle its error separately? I like the read_exactly_or_die variant because it makes callers more concise, but on the other hand a

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > On Mon, Sep 25, 2017 at 05:17:32PM -0700, Jonathan Nieder wrote: >> #ifndef EUNDERFLOW >> # ifdef ENODATA >> # define EUNDERFLOW ENODATA >> # else >> # define EUNDERFLOW ESPIPE >> # endif >> #endif > > Right, I think our m

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > I definitely would prefer to avoid EIO, or anything that an actual > read() might return. > > What do you think of ENODATA? The glibc text for it is pretty > appropriate. If it's not available everywhere, we'd have to fallback to > something else (EIO? 0?). I don't know how

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jonathan Nieder wrote: > On Mon, Sep 25, 2017 at 08:09:13PM -0400, Jeff King wrote: >> ENODATA is not too bad. On my glibc system it yields "No data available" >> from strerror(), which is at least comprehensible. >> >> We're still left with the questio

Re: [PATCH 3/7] read_in_full: reset errno before reading

On Mon, Sep 25, 2017 at 08:09:13PM -0400, Jeff King wrote: > On Mon, Sep 25, 2017 at 05:06:58PM -0700, Stefan Beller wrote: >> After reading this discussion from the sideline, maybe >> >> ENODATA No message is available on the STREAM head read >> queue (POSIX.1) >> >> is not too bad

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > On Mon, Sep 25, 2017 at 04:55:10PM -0700, Jonathan Nieder wrote: >> All that really matters is the strerror() that the user would see. > > Agreed, though I didn't think those were necessarily standardized. The standard allows them to vary for the sake of inter

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

found in the .gitmodules file, it is > potentially untrusted, which is why we do not run it. Add a test > confirming the behavior. > > Suggested-by: Jonathan Nieder <jrnie...@gmail.com> > Signed-off-by: Stefan Beller <sbel...@google.com> > --- > t/t7406-submodule-upda

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > [EOVERFLOW] > The file is a regular file, nbyte is greater than 0, the starting > position is before the end-of-file, and the starting position is > greater than or equal to the offset maximum established in the open > file description associated with fildes.

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: > On Mon, Sep 25, 2017 at 04:33:16PM -0700, Jonathan Nieder wrote: >> Jef King wrote: >>> errno = 0; >>> read_in_full(fd, buf, sizeof(buf)); >>> if (errno) >>> die_errno("oops"); [...] >>>

Re: [PATCH] Documentation: consolidate submodule..update

:22 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: >> Maybe we should work on first wordsmithing the doc and then figuring >> out where it goes? The current state of the doc with (?) three >> different texts, > > such that each different text highlights each locations purpos

Re: [PATCH 3/7] read_in_full: reset errno before reading

Jeff King wrote: >> --- a/wrapper.c >> +++ b/wrapper.c >> @@ -318,8 +318,10 @@ ssize_t read_in_full(int fd, void *buf, size_t count) >> ssize_t loaded = xread(fd, p, count); >> if (loaded < 0) >> return -1; >> -if (loaded == 0) >> +

Re: git ls-tree -d doesn't work if the specified path is the repository root?

Hi, Roy Wellington wrote: > When I run `git ls-tree -d HEAD -- subdir` from the root of my > repository, where `subdir` is a subdirectory in that root, I get the > treehash of that subdirectory. This is what I expect. > > However, if I merely replace `subdir` with `.` (the root of the >

Re: [PATCH] Documentation: consolidate submodule..update

Stefan Beller wrote: > On Mon, Sep 25, 2017 at 12:17 PM, Brandon Williams wrote: >> On 09/25, Stefan Beller wrote: >>> Have one place to explain the effects of setting submodule..update >>> instead of two. >>> >>> Signed-off-by: Stefan Beller >>> --- >

Re: [PATCH 7/7] add xread_in_full() helper

Jeff King wrote: > Many callers of read_in_full() expect to see exactly "len" > bytes, and die if that isn't the case. micronit: Can this be named read_in_full_or_die? Otherwise it's too easy to mistake for a function like xread, which has different semantics. I realize that xmalloc, xmemdupz,

Re: [PATCH 6/7] worktree: check the result of read_in_full()

Jeff King wrote: > We try to read "len" bytes into a buffer and just assume > that it happened correctly. In practice this should usually > be the case, since we just stat'd the file to get the > length. But we could be fooled by transient errors or by > other processes racily truncating the

Re: [PATCH 5/7] worktree: use xsize_t to access file size

y for a "gitdir" file, but it's a good > practice to model. > > Signed-off-by: Jeff King <p...@peff.net> > --- > builtin/worktree.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH 4/7] get-tar-commit-id: prefer "!=" for read_in_full() error check

Jeff King wrote: > Suggested-by: Jonathan Nieder <jrnie...@gmail.com> > Signed-off-by: Jeff King <p...@peff.net> > --- > builtin/get-tar-commit-id.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH 3/7] read_in_full: reset errno before reading

ch yields a message like unable to read: Illegal byte sequence That's not great, but at least it's deterministic and makes it possible to reverse-engineer what went wrong. Change-Id: I48138052f71b7c6cf35c2d00a10dc8febaca4f10 Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- wrapper.c | 4

Re: [PATCH 2/7] notes-merge: drop dead zero-write code

. > > Suggested-by: Jonathan Nieder <jrnie...@gmail.com> > Signed-off-by: Jeff King <p...@peff.net> > --- > notes-merge.c | 2 -- > 1 file changed, 2 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks for tying up this loose end.

Re: [PATCH 1/7] files-backend: prefer "0" for write_in_full() error check

avoid "write_in_full(fd, buf, > len) < len" pattern, 2017-09-13). > > Signed-off-by: Jeff King <p...@peff.net> > --- > refs/files-backend.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Good eyes. Thanks. Reviewed-by: Jonathan Nieder <jrnie...@gmai

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

found in the .gitmodules file, it is > potentially untrusted, which is why we do not run it. Add a test > confirming the behavior. > > Suggested-by: Jonathan Nieder <jrnie...@gmail.com> > Signed-off-by: Stefan Beller <sbel...@google.com> > --- > t/t7406-submodule-

Re: [PATCH v2 1/1] Win32: simplify loading of DLL functions

> return error("could not create hardlink from %S to %S", >source, target); > return 0; > > Signed-off-by: Karsten Blees <bl...@dcon.de> > Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> > Reviewe

Re: [PATCHv2] Documentation/config: clarify the meaning of submodule..update

Stefan Beller wrote: > Reported-by: Lars Schneider > Signed-off-by: Stefan Beller > --- > Documentation/config.txt | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > > Jonathan writes: >> You'll want to update

Re: [PATCH] Documentation/config: clarify the meaning of submodule..update

Hi, Stefan Beller wrote: > With more commands (that potentially change a submodule) paying attention > to submodules as well as the recent discussion[1] on submodule..update, > let's spell out that submodule..update is strictly to be used > for configuring the "submodule update" command and not

Re: [PATCH 1/4] cat-file: handle NULL object_context.path

ent? * builtin/grep.c appears to do the right thing (it stores NULL in list, so it passes NULL to grep_object, which calls grep_oid, which calls grep_source_init, which stores NULL for the grep machinery that is able to cope with a NULL). * builtin/log.c is correctly updated as part of the pa

Re: [PATCH v1] travis-ci: fix "skip_branch_tip_with_tag()" string comparison

larsxschnei...@gmail.com wrote: > 09f5e97 ("travis-ci: skip a branch build if equal tag is present", > 2017-09-17) introduced the "skip_branch_tip_with_tag" function with > a broken string comparison. Fix it! > > Reported-by: SZEDER Gábor > Signed-off-by: Lars Schneider

Re: [PATCH] revision: replace "struct cmdline_pathspec" with argv_array

Jeff King wrote: > On Wed, Sep 20, 2017 at 03:48:26PM -0700, Jonathan Nieder wrote: >> Jeff King wrote: >>> Subject: [PATCH] revision: replace "struct cmdline_pathspec" with argv_array >>> >>> We assemble an array of strings in a custom struct

Re: [PATCH] revision: replace "struct cmdline_pathspec" with argv_array

would not even be reachable. [...] > On Wed, Sep 20, 2017 at 03:48:26PM -0700, Jonathan Nieder wrote: >> In other words, proposed changes: >> >> 1. Could the commit message describe what effect this would have on >> maximum heap usage, if any? (In qualitative t

Re: [PATCH] revision: replace "struct cmdline_pathspec" with argv_array

Hi, Jeff King wrote: > Subject: [PATCH] revision: replace "struct cmdline_pathspec" with argv_array > > We assemble an array of strings in a custom struct, > NULL-terminate the result, and then pass it to > parse_pathspec(). > > But then we never free the array or the individual strings > (nor

Re: [PATCH] commit: fix memory leak in `reduce_heads()`

ed, 1 insertion(+) Good catch. Thanks. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH] Win32: simplify loading of DLL functions

Johannes Schindelin wrote: > On Tue, 19 Sep 2017, Jonathan Nieder wrote: >> Could this example go near the top of the header instead? That way, >> it's easier for people reading the header to see how to use it. > > Funny, I am *so* used to examples being at the very end, fr

Re: [PATCH 1.5/8] connect: die when a capability line comes after a ref

Brandon Williams wrote: > On 09/20, Jeff King wrote: >> (For that matter, could we just be checking whether *list is NULL?) > > True, that would probably be the better way to do this. Nice idea, thank you. That doesn't capture a few other cases of pkts that aren't supposed to come before the

Re: [PATCH] Add t/helper/test-write-cache to .gitignore

-by: Jonathan Tan <jonathanta...@google.com> > > Looks good to me Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> as well. I wonder if we can automate this a little. Some thoughts: A. We could include a test that all the binaries named in TEST_PROGRAMS_NEED_X are also

Re: [PATCH v6 09/12] split-index: disable the fsmonitor extension when running the split index test

Hi, Ben Peart wrote: > On 9/19/2017 4:43 PM, Jonathan Nieder wrote: >> This feels to me like the wrong fix. Wouldn't it be better for the >> test not to depend on the precise object ids? See the "Tips for >> Writing Tests" section in t/README: > > I com

Re: [PATCH v2] for_each_string_list_item: avoid undefined behavior for empty list

Andreas Schwab wrote: > On Sep 19 2017, Jonathan Nieder <jrnie...@gmail.com> wrote: >> B. #define for_each_string_list_item(item, list) \ >> if (list->items) \ >> for (item = ...; ...; ... ) >> >>

[PATCH v2] for_each_string_list_item: avoid undefined behavior for empty list

hed out the commit message based on mailing list discussion] Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- string-list.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Junio C Hamano wrote: > Jonathan N

Re: [PATCH] for_each_string_list_item(): behave correctly for empty list

Hi, Kaartic Sivaraam wrote: > On Saturday 16 September 2017 09:36 AM, Michael Haggerty wrote: >> Jonathan Nieder wrote: >>> Does the following alternate fix work? I think I prefer it because >>> it doesn't require introducing a new global. [...] >>> #define

Re: [PATCH] for_each_string_list_item(): behave correctly for empty list

Hi, Junio C Hamano wrote: > Kaartic Sivaraam <kaarticsivaraam91...@gmail.com> writes: >> On Saturday 16 September 2017 09:36 AM, Michael Haggerty wrote: >>> Jonathan Nieder wrote: >>>> Does the following alternate fix work? I think I prefer it because >&

Re: [PATCH v6 09/12] split-index: disable the fsmonitor extension when running the split index test

Hi, Ben Peart wrote: > The split index test t1700-split-index.sh has hard coded SHA values for > the index. Currently it supports index V4 and V3 but assumes there are > no index extensions loaded. > > When manually forcing the fsmonitor extension to be turned on when > running the test suite,

Re: [PATCH v1 1/1] test-lint: echo -e (or -E) is not portable

.@web.de> > --- > t/check-non-portable-shell.pl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) An excellent change. Thanks for noticing and fixing this. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH v6 10/12] fsmonitor: add test cases for fsmonitor extension

Ben Peart wrote: > Some stats on these same coding style errors in the current bash scripts: > > 298 instances of "[a-z]\(\).*\{" ie "function_name() {" (no space) > 140 instances of "if \[ .* \]" (not using the preferred "test") > 293 instances of "if .*; then" > > Wouldn't it be great not to

Re: [PATCH] doc: camelCase the config variables to improve readability

ocumentation/git-branch.txt | 4 ++-- > Documentation/git-tag.txt| 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) This also is just more consistent with the rest of the docs. FWIW, with or without the commit message tweaks mentioned above, Reviewed-by: Jonathan Nieder <

Re: [PATCH] Win32: simplify loading of DLL functions

RARY_SEARCH_SYSTEM32); > + if (hnd) > + proc->pfunction = GetProcAddress(hnd, proc->function); > + } > + /* set ENOSYS if DLL or function was not found */ > + if (!proc->pfunction) > + errno = ENOSYS; > + return proc->pfunction; > +} strerror(ENOSYS) is "Function not implemented". Cute. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks, Jonathan

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

Johannes Schindelin wrote: > What you need is a tool to aggregate this information, to help working > with it, to manage the project, and to be updated automatically. And to > publish this information continuously, without costing you extra effort. > > I understand that you started before GitHub

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

Hi, Johannes Schindelin wrote: > To relate that, you are using a plain text format that is not well defined > and not structured, and certainly not machine-readable, for information > that is crucial for project management. > > What you need is a tool to aggregate this information, to help

Re: [PATCH 2/2] t9010-*.sh: skip all tests if the PIPE prereq is missing

. It would need to use a socket or something for backflow to work on Windows. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH 1/2] test-lib: use more compact expression in PIPE prerequisite

Ramsay Jones wrote: > Signed-off-by: Ramsay Jones <ram...@ramsayjones.plus.com> > --- > t/test-lib.sh | 10 ++ > 1 file changed, 2 insertions(+), 8 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH 2/2] read_info_alternates: warn on non-trivial errors

Jeff King wrote: > When we fail to open $GIT_DIR/info/alternates, we silently > assume there are no alternates. This is the right thing to > do for ENOENT, but not for other errors. > > A hard error is probably overkill here. If we fail to read > an alternates file then either we'll complete our

Re: [PATCH 1/2] read_info_alternates: read contents into strbuf

Jeff King wrote: > Reported-by: Michael Haggerty <mhag...@alum.mit.edu> > Signed-off-by: Jeff King <p...@peff.net> > --- > sha1_file.c | 29 + > 1 file changed, 9 insertions(+), 20 deletions(-) Thanks for tracking it down. Reviewed

Re: [PATCH 0/2] fix read past end of array in alternates files

Jeff King wrote: > This series fixes a regression in v2.11.1 where we might read past the > end of an mmap'd buffer. It was introduced in cf3c635210, The above information is super helpful. Can it go in one of the commit messages? > but

Re: [PATCH] rev-parse: rev-parse: add --is-shallow-repository

est_expect_success 'git-path notshallow repository' ' Likewise: should this be test_expect_success 'rev-parse --is-shallow-repository in non-shallow repo' ' ? > + echo false >expect && > + git rev-parse --is-shallow-repository >actual && > + test_cmp expect actual > +' > + > test_expect_success 'showing the superproject correctly' ' With the two tweaks mentioned above, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [OUTREACHY] pack: make packed_git_mru global a value instead of a pointer

Hi, phionah bugosi wrote: > Just to reecho a previous change requested before in one of the mail > threads, we currently have two global variables declared: > > struct mru packed_git_mru_storage; > struct mru *packed_git_mru = _git_mru_storage; > > We normally use pointers in C to point or refer

Re: RFC v3: Another proposed hash function transition plan

Hi, Gilles Van Assche wrote: > Hi Johannes, >> SHA-256 got much more cryptanalysis than SHA3-256 […]. > > I do not think this is true. Keccak/SHA-3 actually got (and is still > getting) a lot of cryptanalysis, with papers published at renowned > crypto conferences [1]. > > Keccak/SHA-3 is

Re: [PATCH v2] git-svn: Fix svn.pushmergeinfo handling of svn+ssh usernames.

ot; > > So, let's call remove_username (as we do for svn info) before comparing > rooturl to branchurl. > > Signed-off-by: Jason Merrill <ja...@redhat.com> > Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> > --- > git-svn.perl | 1 + > 1 file changed, 1 insertion(+) Th

Re: [PATCH] Fix merge parent checking with svn.pushmergeinfo.

Jason Merrill wrote: > On Fri, Sep 15, 2017 at 1:52 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > > Jason Merrill wrote: >>> Subject: Fix merge parent checking with svn.pushmergeinfo. >>> >>> Without this fix, svn dcommit of a merge with svn.pushmerge

Re: [PATCH] for_each_string_list_item(): behave correctly for empty list

Hi, Michael Haggerty wrote: > If you pass a newly-initialized or newly-cleared `string_list` to > `for_each_string_list_item()`, then the latter does > > for ( > item = (list)->items; /* note, this is NULL */ > item < (list)->items + (list)->nr; /* note: NULL + 0 */ >

Re: [PATCH] Fix merge parent checking with svn.pushmergeinfo.

Hi, Jason Merrill wrote: > Subject: Fix merge parent checking with svn.pushmergeinfo. > > Without this fix, svn dcommit of a merge with svn.pushmergeinfo set would > get error messages like "merge parent for is on branch > svn+ssh://gcc.gnu.org/svn/gcc/trunk, which is not under the git-svn

Re: [PATCH 0/3] Improve abbreviation disambiguation

Hi, Derrick Stolee wrote: > This is my first patch submission, and I look forward to your feedback. Thanks for writing this. Looks exciting. [...] > When displaying object ids, we frequently want to see an abbreviation [etc] > Note that performance improves in all cases, but the performance

Re: RFC v3: Another proposed hash function transition plan

Johannes Schindelin wrote: > On Wed, 13 Sep 2017, Jonathan Nieder wrote: >> As a side note, I am probably misreading, but I found this set of >> paragraphs a bit condescending. It sounds to me like you are saying >> "You are making the wrong choice of hash function

Re: RFC v3: Another proposed hash function transition plan

Hi, Johannes Schindelin wrote: > On Wed, 13 Sep 2017, Jonathan Nieder wrote: >> [3] https://www.imperialviolet.org/2017/05/31/skipsha3.html, > > I had read this short after it was published, and had missed the updates. > One link in particular caught my eye: > >

Re: [PATCH v2] test-lib: don't use ulimit in test prerequisites on cygwin

E_DESCRIPTORS prerequisites. > > Signed-off-by: Ramsay Jones <ram...@ramsayjones.plus.com> > --- > t/t1400-update-ref.sh | 5 - > t/t6120-describe.sh | 1 - > t/t7004-tag.sh| 1 - > t/test-lib.sh | 10 -- > 4 files changed, 12 insertion

Re: RFC v3: Another proposed hash function transition plan

Hi, Yves wrote: > On 13 September 2017 at 14:05, Johannes Schindelin >> For example, I am still in favor of SHA-256 over SHA3-256, after learning >> some background details from in-house cryptographers: it provides >> essentially the same level of security, according to my sources, while >>

Re: RFC v3: Another proposed hash function transition plan

Junio C Hamano wrote: > In the proposed transition plan, the treatment of various signatures > (deliberately) makes the conversion not quite roundtrip. That's not precisely true. Details below. > When existing SHA-1 history in individual clones are converted to > NewHash, we obviously cannot

Re: RFC v3: Another proposed hash function transition plan

Hi, Stefan Beller wrote: > On Wed, Sep 13, 2017 at 2:52 PM, Junio C Hamano wrote: >> This is a tangent, but it may be fine for a shallow clone to treat >> the cut-off points in the history as if they are root commits and >> compute generation numbers locally, just like

Re: [PATCH 7/7] config: flip return value of store_write_*()

look like the following (as a patch to squash in): With or without that tweak, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> diff --git i/config.c w/config.c index 272a32aac0..8f92d452bf 100644 --- i/config.c +++ w/config.c @@ -2297,11 +2297,10 @@ static int write_error(const char *filename)

Re: [PATCH 6/7] notes-merge: use ssize_t for write_in_full() return value

sented in "long" and "unsigned > long", and if your size_t is larger than a "long" (as it is > on 64-bit Windows). > > Signed-off-by: Jeff King <p...@peff.net> > --- > notes-merge.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Yik

Re: [PATCH 5/7] pkt-line: check write_in_full() errors against "< 0"

ditionals to our usual style. > > Signed-off-by: Jeff King <p...@peff.net> > --- > pkt-line.c | 29 ++--- > 1 file changed, 14 insertions(+), 15 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH 4/7] convert less-trivial versions of "write_in_full() != len"

| 5 +++-- > refs/files-backend.c | 2 +- > streaming.c | 2 +- > 3 files changed, 5 insertions(+), 4 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH 3/7] avoid "write_in_full(fd, buf, len) != len" pattern

| 6 +++--- > refs.c | 2 +- > refs/files-backend.c | 8 > rerere.c | 2 +- > shallow.c | 6 +++--- > t/helper/test-delta.c | 2 +- > transport-helper.c | 5 ++--- > wrapper.c | 2 +- > 16 files changed, 26 insertions(+), 27 deletions(-) All of these look correctly done. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

h_i_mean_it and read_this_much_or_to_eof. Anyway, I think the below is an improvement. With or without this tweak, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks. diff --git i/builtin/get-tar-commit-id.c w/builtin/get-tar-commit-id.c index 6d9a79f9b3..03ef7c5ba4 100644 --- i/buil

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

Jeff King wrote: > AFAIK there's no way to turn it on for specific functions, but I'm far > from a gcc-warning guru. Even if you could, though, the error may be far > from the function (e.g., if we store the result in an ssize_t and then > compare that with a size_t). It turns out that yes, we

Re: [PATCH] test-lib: don't use ulimit in test prerequisites on cygwin

E_DESCRIPTORS prerequisites. > > Signed-off-by: Ramsay Jones <ram...@ramsayjones.plus.com> > --- > t/t1400-update-ref.sh | 11 ++- > t/t6120-describe.sh | 1 - > t/t7004-tag.sh| 1 - > t/test-lib.sh | 22 -- > 4 files changed

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

Jeff King wrote: > On Wed, Sep 13, 2017 at 11:24:31AM -0700, Jonathan Nieder wrote: >> Compilers' signed/unsigned comparison warning can be noisy, but I'm >> starting to feel it's worth the suppression noise to turn it on when >> DEVELOPER=1 anyway. What do you think? I

Re: [PATCH 8/7] read_pack_header: handle signed/unsigned comparison in read result

e. > And anyway, this function reads from pipes and network > sockets. A network error may racily appear as EOF to us > anyway if there's data left in the socket buffers. > > Signed-off-by: Jeff King <p...@peff.net> > --- > sha1_file.c | 2 +- > 1 file changed,

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

wo size_t variables, making the result an unsigned size_t. > We can fix this by just checking for a negative return value > directly, as write_in_full() will never return any value > except -1 or the full count. [...] > Reported-by: demerphq <demer...@gmail.com> > Signed-off-by:

Re: [PATCH 1/7] config: avoid "write_in_full(fd, buf, len) < len" pattern

Jeff King wrote: > On Wed, Sep 13, 2017 at 10:47:28AM -0700, Jonathan Nieder wrote: >> Jeff King wrote: >>> I scoured the code base for cases of this, but it turns out >>> that these two in git_config_set_multivar_in_file_gently() >>> are the only ones. Thi

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

Jeff King wrote: > We ask to write 41 bytes and make sure that the return value > is at least 41. This is the same "dangerous" pattern that > was fixed in the prior commit (wherein a negative return > value is promoted to unsigned), though it is not dangerous > here because our "41" is a

Re: [PATCH 1/7] config: avoid "write_in_full(fd, buf, len) < len" pattern

Hi, Jeff King wrote: > I scoured the code base for cases of this, but it turns out > that these two in git_config_set_multivar_in_file_gently() > are the only ones. This case is actually quite interesting: > we don't have a size_t, but rather use the subtraction of > two pointers. Which you

Re: RFC v3: Another proposed hash function transition plan

Hi Dscho, Johannes Schindelin wrote: > So even if the code to generate a bidirectional old <-> new hash mapping > might be with us forever, it *definitely* should be optional ("optional" > at least as in "config setting"), allowing developers who only work with > new-hash repositories to save

[PATCH 4/4] packed refs: pass .git dir instead of packed-refs path to init_fn

From: Stefan Beller <sbel...@google.com> The first argument of a ref_store_init_fn is documented to represent the $GIT_DIR, not the path to the packed-refs file. This brings the packed-refs store more in line with the usual ref store interface. Signed-off-by: Jonathan Nieder <jrnie...@

[PATCH 3/4] replace-objects: evaluate replacement refs without using the object store

point to a valid object! Noticed while adapting the object store (and in particular its evaluation of replace refs) to handle arbitrary repositories. Signed-off-by: Stefan Beller <sbel...@google.com> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- refs.c | 2 +- 1 file ch

<    3   4   5   6   7   8   9   10   11   12   >