Re: Feature request for automatic worktree checkout

On Mon, Jul 18, 2016 at 11:33 AM, Junio C Hamano wrote: > Ehsan Azarnasab writes: > >> Currently if I have a branch checked out in a work-tree, git-checkout >> will show this error message when checking out that branch: >> >> $ git checkout master >>

Re: [PATCH 12/12] receive-pack: send keepalives during quiet periods

On Sat, Jul 16, 2016 at 12:56 AM, Jeff King wrote: >> > + if (use_keepalive == KEEPALIVE_AFTER_NUL && >> > !keepalive_active) { >> > + const char *p = memchr(data, '\0', sz); >> > + if (p) { >> > +

Re: [PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

On Mon, Jul 18, 2016 at 9:32 PM, Parker Moore wrote: >> The label does not even identify the version of the source in any way, so I >> am not sure how people are depending on that feature anyway ;-) > > Would it be a better solution simply to remove this build flag? >

Re: [PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

> The label does not even identify the version of the source in any way, so I > am not sure how people are depending on that feature anyway ;-) Would it be a better solution simply to remove this build flag? Alternatively, if Git wished to support Go v1.5 and below, I would be more than happy to

[PATCH 1/3] difftool: fix argument handling in subdirs

From: John Keeping When in a subdirectory of a repository, path arguments should be interpreted relative to the current directory not the root of the working tree. The Git::repository object passed into setup_dir_diff() is configured to handle this correctly but we create a

[PATCH 3/3] difftool: use Git::* functions instead of passing around state

Call Git::command() and friends directly wherever possible. This makes it clear that these operations can be invoked directly without needing to manage the current directory and related GIT_* environment variables. Eliminate find_repository() since we can now use wc_path() and not worry about

[PATCH 2/3] difftool: avoid $GIT_DIR and $GIT_WORK_TREE

Environment variables are global and hard to reason about. Use the `--git-dir` and `--work-tree` arguments when invoking `git` instead of relying on the environment. Add a test to ensure that difftool's dir-diff feature works when these variables are present in the environment. Signed-off-by:

Re: [PATCH] pager: disable color when pager is "more"

Junio C Hamano wrote: > Jeff King writes: > > On Mon, Jul 18, 2016 at 09:19:07AM +, Eric Wong wrote: > >> Johannes Schindelin wrote: > >> > On Sun, 17 Jul 2016, n...@dad.org wrote: > >> > > 'git diff' outputs escape characters

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

Junio C Hamano writes: > Johannes Schindelin writes: > >> The two topics that are in 'pu' and conflict with this series are >> 'jh/clean-smudge-annex' and 'bc/cocci'. >> >> It also conflicted with 'va/i18n-even-more', but that one was merged to >>

Re: [PATCH] test-lib: stricter unzip(1) check

On Mon, Jul 18, 2016 at 12:43:27PM -0700, Junio C Hamano wrote: > -- >8 -- > test: check "unzip" and "unzip -a" > > Different platforms have implementations "unzip" that behave > differently. Most of the tests we use GIT_UNZIP we only care about > the command to be able to extract from *.zip

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 11:00:35AM -0700, 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

git-prompt.sh incompatible with non-basic global grep.patternType

Hi, I wanted to report something interesting that I found while tracing a severe slowdown in git-prompt.sh. https://github.com/git/git/commit/6d158cba282f22fa1548af1188f78042fed30aed#diff-f37c4f4a898819f0ca4b5ff69e81d4d9R141 Way back in this commit, someone added a useful chunk of code that

Re: t7063 failure on FreeBSD 10.3 i386/amd64

Oops, forgot to Cc some folks who worked on this :x Filesystem is ufs and it fails regardless of whether soft-updates is enabled or not. Eric Wong wrote: > Not sure what's going on, below is the relevant output when > run with -i -v --tee (the rest succeeds without -i): > > ok

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 09:00:06AM +0200, Johannes Schindelin wrote: > Hi Brian, > > On Sun, 17 Jul 2016, brian m. carlson wrote: > > > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: > > > Out of curiosity: have you considered something like padding the SHA-1s > > > with,

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

Jonathan Tan wrote: > Signed-off-by: Jonathan Tan > --- > fetch-pack.c | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) Reviewed-by: Jonathan Nieder Thanks again. -- To unsubscribe from this list: send the line

t7063 failure on FreeBSD 10.3 i386/amd64

Not sure what's going on, below is the relevant output when run with -i -v --tee (the rest succeeds without -i): ok 26 - untracked cache correct after status expecting success: avoid_racy && : >../trace && GIT_TRACE_UNTRACKED_STATS="$TRASH_DIRECTORY/trace" \ git

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

When updating large repositories, the LARGE_FLUSH limit (that is, the limit at which the window growth strategy switches from exponential to linear) is reached quite quickly. Use a conservative exponential growth strategy when that limit is reached instead (and increase LARGE_FLUSH so that there

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

Jonathan Tan writes: > and it would look like that patch. (I would probably redefine > LARGE_FLUSH to be 10 times its current value instead of multiplying it > by 10, since it is not used anywhere else.) Sounds good. Care to do the final version of the patch to be

Re: Git and SHA-1 security (again)

>> The reality of the current situation is that it's largely mitigated in >> practice because: >> >> a) it's hard to hand someone a crafted blob to begin with for reasons >> that have nothing to do with SHA-1 (they'll go "wtf is this garbage?") >> >> b) even in that case it's *very* hard to come

Re: [PATCH] test-lib: stricter unzip(1) check

On Mon, Jul 18, 2016 at 2:19 PM, Eric Wong wrote: > Thanks, but I think the test file is too small. I tried > setting up a test to store the text file as binary in the > zip to check for inadvertant CRLF conversions: > > printf 'text\r\n' >binary && zip -B infozip-binary.zip

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] test-lib: stricter unzip(1) check

Junio C Hamano wrote: > Eric Wong writes: > > Junio C Hamano wrote: > >> +test_lazy_prereq UNZIP_AUTOTEXT ' > >> + ( > >> + mkdir unzip-autotext && > >> + cd unzip-autotext > >> + "$GIT_UNZIP" -a

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

On Mon, Jul 18, 2016 at 1:00 PM, Junio C Hamano wrote: > Jonathan Nieder writes: > >> You have full control of the growth function. So how about aggressive >> growth until 1024*10? >> >> That is: >> >> Current git: >> n < 1024: aggressive exponential >>

Re: Git and SHA-1 security (again)

Ævar Arnfjörð Bjarmason writes: > The reality of the current situation is that it's largely mitigated in > practice because: > > a) it's hard to hand someone a crafted blob to begin with for reasons > that have nothing to do with SHA-1 (they'll go "wtf is this garbage?") > > b)

Re: [PATCH v4 0/4] cache-tree building fix in the presence of ita entries

Nguyễn Thái Ngọc Duy writes: > v4 removes the leading underscore from _EMPTY_BLOB and _EMPTY_TREE and > updates 4/4 slightly like this. > > diff --git a/cache-tree.c b/cache-tree.c > index 2d50640..f28b1f4 100644 > --- a/cache-tree.c > +++ b/cache-tree.c > @@ -325,6 +325,7 @@

Re: [PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

Jeff King writes: >> This `name=value` syntax for the -X flag was introduced in Go v1.5 >> (released Aug 19, 2015): >> >> - release notes: https://golang.org/doc/go1.5#link >> - commit: >> https://github.com/golang/go/commit/12795c02f3d6fc54ece09a86e70aaa40a94d5131 >> >> In Go

Re: [PATCH] test-lib: stricter unzip(1) check

Eric Wong writes: > Junio C Hamano wrote: >> +test_lazy_prereq UNZIP_AUTOTEXT ' >> +( >> +mkdir unzip-autotext && >> +cd unzip-autotext >> +"$GIT_UNZIP" -a "$TEST_DIRECTORY"/t5003/infozip-text.zip && >> +test

Re: Git and SHA-1 security (again)

On Mon, 18 Jul 2016, Herczeg Zsolt wrote: In particular, as far as I know and as Theodore Ts'o's post describes better than I could[1], you seem to be confusing preimage attacks with collision attacks, and then concluding that because SHA1 is vulnerable to collision attacks that use-cases that

Re: [PATCH] test-lib: stricter unzip(1) check

Junio C Hamano wrote: > +test_lazy_prereq UNZIP_AUTOTEXT ' > + ( > + mkdir unzip-autotext && > + cd unzip-autotext > + "$GIT_UNZIP" -a "$TEST_DIRECTORY"/t5003/infozip-text.zip && > + test -f text > + ) /usr/bin/unzip

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 7:48 PM, Herczeg Zsolt wrote: >> In particular, as far as I know and as Theodore Ts'o's post describes >> better than I could[1], you seem to be confusing preimage attacks with >> collision attacks, and then concluding that because SHA1 is vulnerable >>

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

Jonathan Nieder writes: > You have full control of the growth function. So how about aggressive > growth until 1024*10? > > That is: > > Current git: > n < 1024: aggressive exponential > 16, 32, 64, 128, 256, 512, 1024 > 1024 <= n: linear > 2048, 3072, 4096,

Re: [PATCH] test-lib: stricter unzip(1) check

Jeff King writes: > My Debian version of unzip (which is derived from Info-zip) seems to > give return code 0 for just "unzip". So for the first check, we could > possibly drop "-v"; we don't care about "-v", but just wanted some way > to say "does unzip exist on the path?".

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

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 justification > behind the order

Re: [PATCH] test-lib: stricter unzip(1) check

Jeff King writes: > On Mon, Jul 18, 2016 at 11:20:19AM -0700, Junio C Hamano wrote: > >> Stepping back a bit, why do we even care if "unzip -a" works on >> "../$zipfile" and converts things correctly in that check_zip() test >> in t5003 in the first place? It looks more like a

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

Jonathan Nieder writes: > Yay, thanks for this. > > When this condition triggers (count >= 10240), we have already > experienced 10 rounds of negotiation. Negotiation ought to have > finished by then. So this is a pretty conservative change to try to > salvage an already

Re: [PATCH] pager: disable color when pager is "more"

On Mon, Jul 18, 2016 at 10:19:09AM -0700, Junio C Hamano wrote: > > This is the tip of a smaller iceberg. See > > > > http://public-inbox.org/git/52D87A79.6060600%40rawbw.com/t/#u > > > > for more discussion, and some patches that fix more cases (like "LESS" > > without "R", or "more" that

Re: [PATCH] test-lib: stricter unzip(1) check

On Mon, Jul 18, 2016 at 11:20:19AM -0700, Junio C Hamano wrote: > Stepping back a bit, why do we even care if "unzip -a" works on > "../$zipfile" and converts things correctly in that check_zip() test > in t5003 in the first place? It looks more like a test on "unzip" > than making sure we

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

Hi, Jonathan Tan wrote: > When updating large repositories, the LARGE_FLUSH limit (that is, the > limit at which the window growth strategy switches from exponential to > linear) is reached quite quickly. Use a conservative exponential growth > strategy when that limit is reached instead. > >

Re: [PATCH v3 2/2] t/t8003-blame-corner-cases.sh: Use here documents

Mike Hommey writes: > Somehow, this test was using: > > { > echo A > echo B > } > file > > block to feed file contents. This changes those to the form most common > in git test scripts: > > cat >file <<-\EOF > A > B > EOF > > Signed-off-by: Mike Hommey

Re: [PATCH] blame: Allow to blame paths freshly added to the index

Mike Hommey writes: >> I suspect that this would be useful without copy detection. If you >> "git mv fileA fileB" (optionally followed by "edit fileB"), fileB >> would not be in HEAD but you should be able to trace the lineage of >> the lines in it back through the renaming

Re: [PATCH v2 0/4] Teach `git fsck` a new option: `--name-objects`

Johannes Schindelin writes: > -static int fsck_error_func(struct object *obj, int type, const char > *message) > +static int fsck_error_func(struct fsck_options *o, > +struct object *obj, int type, const char *message) > { > objreport(obj, (type ==

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

When updating large repositories, the LARGE_FLUSH limit (that is, the limit at which the window growth strategy switches from exponential to linear) is reached quite quickly. Use a conservative exponential growth strategy when that limit is reached instead. This optimization is only applied

Re: Feature request for automatic worktree checkout

Ehsan Azarnasab writes: > Currently if I have a branch checked out in a work-tree, git-checkout > will show this error message when checking out that branch: > > $ git checkout master > fatal: 'master' is already checked out at '/home/dashesy/development/feature' > > It

Re: [PATCH] test-lib: stricter unzip(1) check

Johannes Schindelin writes: > Hrm. That sounds a little magical, and fragile, to me. What if the next > person's unzip returns 0 and *still* cannot handle -a? That is a very sensible line of thought. > I'd rather do something like ... but the patch presented as an

Re: Git and SHA-1 security (again)

"brian m. carlson" writes: > I will say that the pack format will likely require some changes, > because it assumes ... > The reason is that we can't have an unambiguous parse of the current > objects if two hash algorithms are in use > So when we look at a new

Re: Git and SHA-1 security (again)

> In particular, as far as I know and as Theodore Ts'o's post describes > better than I could[1], you seem to be confusing preimage attacks with > collision attacks, and then concluding that because SHA1 is vulnerable > to collision attacks that use-cases that would need a preimage attack > to be

Feature request for automatic worktree checkout

Currently if I have a branch checked out in a work-tree, git-checkout will show this error message when checking out that branch: $ git checkout master fatal: 'master' is already checked out at '/home/dashesy/development/feature' It would be very useful to instead of this error just change the

Re: [PATCH] pager: disable color when pager is "more"

Jeff King writes: > On Mon, Jul 18, 2016 at 09:19:07AM +, Eric Wong wrote: > >> Johannes Schindelin wrote: >> > On Sun, 17 Jul 2016, n...@dad.org wrote: >> > > 'git diff' outputs escape characters which clutter my terminal. Yes, I >> > > can sed

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson wrote: > I'm going to end up having to do something similar because of the issue > of submodules. Submodules may still be SHA-1, while the main repo may > be a newer hash. Or even the other way around, main repo is

Re: Git and SHA-1 security (again)

On Sat, Jul 16, 2016 at 3:48 PM, Herczeg Zsolt wrote: > I would like to discuss an old topic from 2006. I understand it was > already discussed. The only reason i'm sending this e-mail is to talk > about a possible solution which didn't show up on this list before. You mention

Re: Git and SHA-1 security (again)

Hi Johannes, >> My point is not to throw out old hashes and break signatures. My point >> is to convert the data storage, and use mapping to resolve problems >> with those old hashes and signatures. > > If you convert the data storage, then the SHA-1s listed in the commit > objects will have to

Re: [PATCH] list: avoid incompatibility with *BSD sys/queue.h

> On 17 Jul 2016, at 02:25, Eric Wong wrote: > > Eric Wong wrote: >> Lars Schneider wrote: >>> It looks like as if this topic breaks the OS X build because >>> it defines LIST_HEAD. LIST_HEAD is already defined in >>>

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin wrote: > Hi Zsolt, > > On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > >> >> I think converting is a much better option. Use a single-hash >> >> storage, and convert everything to that on import/clone/pull. >> > >> >

Re: Git and SHA-1 security (again)

Hi Zsolt, On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > >> I think converting is a much better option. Use a single-hash > >> storage, and convert everything to that on import/clone/pull. > > > > That ignores two very important issues that I already had mentioned: > > That's not true. If you

Re: Git and SHA-1 security (again)

>> I think converting is a much better option. Use a single-hash storage, and >> convert everything to that on import/clone/pull. > > That ignores two very important issues that I already had mentioned: That's not true. If you double-check the next part of my message, you I just showed that an

Re: [PATCH] test-lib: stricter unzip(1) check

Hi Peff & Eric, On Mon, 18 Jul 2016, Jeff King wrote: > On Mon, Jul 18, 2016 at 06:44:31AM +, Eric Wong wrote: > > > On FreeBSD 10.3 (but presumably any FreeBSD 8+), /usr/bin/unzip > > exists, but is insufficient for t5003 due to its non-standard > > handling of the -a option[1]. This

Re: [PATCH] pager: disable color when pager is "more"

On Mon, Jul 18, 2016 at 09:19:07AM +, Eric Wong wrote: > Johannes Schindelin wrote: > > On Sun, 17 Jul 2016, n...@dad.org wrote: > > > 'git diff' outputs escape characters which clutter my terminal. Yes, I > > > can sed them out, but then why are they there? > >

Re: [PATCH] test-lib: stricter unzip(1) check

On Mon, Jul 18, 2016 at 06:44:31AM +, Eric Wong wrote: > On FreeBSD 10.3 (but presumably any FreeBSD 8+), /usr/bin/unzip > exists, but is insufficient for t5003 due to its non-standard > handling of the -a option[1]. This version of unzip exits > with "1" when given the "-v" flag. > >

[PATCH] configure.ac: stronger test for pthread linkage

We need to test linkage of pthread_create and pthread_join, as pthread_mutex_* and pthread_key_* functions do not need extra linkage under FreeBSD 10.3, leading to a false-positive of the empty case. Signed-off-by: Eric Wong --- configure.ac | 5 + 1 file changed, 5

[PATCH] pager: disable color when pager is "more"

Johannes Schindelin wrote: > On Sun, 17 Jul 2016, n...@dad.org wrote: > > 'git diff' outputs escape characters which clutter my terminal. Yes, I > > can sed them out, but then why are they there? > > Those are most likely the ANSI sequences to add color. Can you call

Re: Question: Getting 'git diff' to generate /usr/bin/diff output

Hi Norm, On Sun, 17 Jul 2016, n...@dad.org wrote: > writes: > > > >The other replies covered how to use the system's own diff instead. > >Just curious: What makes using git diff difficult and its output hard to > >deal with for you? > > In decreasing importance order: > > I am

Re: Git and SHA-1 security (again)

Hi Zsolt, On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > I think converting is a much better option. Use a single-hash storage, and > convert everything to that on import/clone/pull. That ignores two very important issues that I already had mentioned: - existing references, both in-repository,

Re: Git and SHA-1 security (again)

Hi Brian, On Sun, 17 Jul 2016, brian m. carlson wrote: > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: > > Out of curiosity: have you considered something like padding the SHA-1s > > with, say 0xa1, to the size of the new hash and using that padding to > > distinguish

[PATCH] test-lib: stricter unzip(1) check

On FreeBSD 10.3 (but presumably any FreeBSD 8+), /usr/bin/unzip exists, but is insufficient for t5003 due to its non-standard handling of the -a option[1]. This version of unzip exits with "1" when given the "-v" flag. However, the common Info-ZIP version may be installed at /usr/local/bin/unzip