[PATCH] gc: fix off-by-one error with gc.autoPackLimit

This matches the documentation and allows gc.autoPackLimit=1 to maintain a single pack without attempting a repack on every "git gc --auto" invocation. Signed-off-by: Eric Wong --- builtin/gc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/gc.c b/builtin/gc.c index

[PATCH v2] unpack-trees: fix English grammar in do-this-before-that messages

Signed-off-by: Alex Henrie --- t/t1011-read-tree-sparse-checkout.sh | 2 +- t/t7607-merge-overwrite.sh | 2 +- t/t7609-merge-co-error-msgs.sh | 10 +- unpack-trees.c | 18 +- 4 files changed, 16 insertions(+), 16 deletions(-) diff -

Re: [PATCH] builtin/worktree.c: add option for setting worktree name

This is really to scratch an itch I have when I break my worktrees and can’t figure out which worktree dir is the one I’ve broken. For example, I organize my code as follows: projects/reviewboard/branches//src/ django/ djblets/ reviewboard/ for each release branch I ma

Re: [PATCH] builtin/worktree.c: add option for setting worktree name

Barret Rennie writes: > Add the --name parameter to git worktree add that allows the user to set > the name of the created worktree directory. A worktree must not already > exist with the current name or creation will fail. Hmph. This strongly smells like "because we can add this feature", not

Re: [RFC] gc: correct gc.autoPackLimit documentation

Eric Wong writes: >> That's neither here nor there for the off-by-one in gc or its >> documentation, of course, but just FYI. > > I'm now inclined to fix the problem in gc and leave the > documentation as-is (unless it cause other problems...) I think that is the best in the longer term. -- To u

[PATCH v2 02/12] test-regex: isolate the bug test code

This is in preparation to turn test-regex into some generic regex testing command. Helped-by: Eric Sunshine Helped-by: Ramsay Jones Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- t/t0070-fundamental.sh | 2 +- test-regex.c | 12 ++-- 2 files changed,

[PATCH v2 05/12] grep/icase: avoid kwsset when -F is specified

Similar to the previous commit, we can't use kws on icase search outside ascii range. But we can't simply pass the pattern to regcomp/pcre like the previous commit because it may contain regex special characters, so we need to quote the regex first. To avoid misquote traps that could lead to undef

[PATCH v2 12/12] grep.c: reuse "icase" variable

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- grep.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/grep.c b/grep.c index 3d63612..92587a8 100644 --- a/grep.c +++ b/grep.c @@ -438,10 +438,7 @@ static void compile_regexp(struct grep_pat *p, struct

[PATCH v2 07/12] grep/pcre: prepare locale-dependent tables for icase matching

The default tables are usually built with C locale and only suitable for LANG=C or similar. This should make case insensitive search work correctly for all single-byte charsets. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- grep.c | 8 ++

[PATCH v2 06/12] grep: rewrite an if/else condition to avoid duplicate expression

"!icase || ascii_only" is repeated twice in this if/else chain as this series evolves. Rewrite it (and basically revert the first if condition back to before the "grep: break down an "if" stmt..." commit). Helped-by: Junio C Hamano Signed-off-by: Nguyễn Thái Ngọc Duy --- grep.c | 5 + 1 fil

[PATCH v2 04/12] grep/icase: avoid kwsset on literal non-ascii strings

When we detect the pattern is just a literal string, we avoid heavy regex engine and use fast substring search implemented in kwsset.c. But kws uses git-ctype which is locale-independent so it does not know how to fold case properly outside ascii range. Let regcomp or pcre take care of this case in

[PATCH v2 08/12] gettext: add is_utf8_locale()

This function returns true if git is running under an UTF-8 locale. pcre in the next patch will need this. is_encoding_utf8() is used instead of strcmp() to catch both "utf-8" and "utf8" suffixes. When built with no gettext support, we peek in several env variables to detect UTF-8. pcre library m

[PATCH v2 03/12] test-regex: expose full regcomp() to the command line

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- test-regex.c | 51 +-- 1 file changed, 49 insertions(+), 2 deletions(-) diff --git a/test-regex.c b/test-regex.c index 67a1a65..eff26f5 100644 --- a/test-regex.c +++ b/test-rege

[PATCH v2 09/12] grep/pcre: support utf-8

In the previous change in this function, we add locale support for single-byte encodings only. It looks like pcre only supports utf-* as multibyte encodings, the others are left in the cold (which is fine). We need to enable PCRE_UTF8 so pcre can find character boundary correctly. It's needed for

[PATCH v2 11/12] diffcore-pickaxe: support case insensitive match on non-ascii

Similar to the "grep -F -i" case, we can't use kws on icase search outside ascii range, so we quote the string and pass it to regcomp as a basic regexp and let regex engine deal with case sensitivity. The new test is put in t7812 instead of t4209-log-pickaxe because lib-gettext.sh might cause prob

[PATCH v2 10/12] diffcore-pickaxe: Add regcomp_or_die()

There's another regcomp code block coming in this function that needs the same error handling. This function can help avoid duplicating error handling code. Helped-by: Jeff King Signed-off-by: Nguyễn Thái Ngọc Duy --- diffcore-pickaxe.c | 22 +- 1 file changed, 13 insertions

[PATCH v2 00/12] nd/icase updates

v2 fixes Junio's and Jeff's comments (both good). The sharing "!icase || ascii_only" is made a separate commit (6/12) because I think it takes some seconds to realize that the conversion is correct and it's technically not needed in 5/12 (and it's sort of the opposite of 1/12) Interdiff diff --gi

[PATCH v2 01/12] grep: break down an "if" stmt in preparation for next changes

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- grep.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/grep.c b/grep.c index 7b2b96a..f430d7e 100644 --- a/grep.c +++ b/grep.c @@ -403,7 +403,9 @@ static void compile_regexp(struct grep_pat *p, struct g

[PATCH] builtin/worktree.c: add option for setting worktree name

Add the --name parameter to git worktree add that allows the user to set the name of the created worktree directory. A worktree must not already exist with the current name or creation will fail. Signed-off-by: Barret Rennie --- Documentation/git-worktree.txt | 6 +- builtin/worktree.c

Re: [RFC] gc: correct gc.autoPackLimit documentation

Jeff King wrote: > On Sat, Jun 25, 2016 at 01:14:50AM +, Eric Wong wrote: > > > I'm not sure if this is the best approach, or if changing > > too_many_packs can be done without causing problems for > > hosts of big repos. > > > > ---8<- > > Subject: [PATCH] gc: correct gc.autoPackLim

Re: [RFC] gc: correct gc.autoPackLimit documentation

On Sat, Jun 25, 2016 at 01:14:50AM +, Eric Wong wrote: > I'm not sure if this is the best approach, or if changing > too_many_packs can be done without causing problems for > hosts of big repos. > > ---8<- > Subject: [PATCH] gc: correct gc.autoPackLimit documentation > > I want to en

[RFC] gc: correct gc.autoPackLimit documentation

I'm not sure if this is the best approach, or if changing too_many_packs can be done without causing problems for hosts of big repos. ---8<- Subject: [PATCH] gc: correct gc.autoPackLimit documentation I want to ensure there is only one pack in my repo to take advantage of pack bitmaps. B

Re: [PATCH v3 06/11] diff: rename struct diff_filespec's sha1_valid member

On Fri, Jun 24, 2016 at 05:29:18PM -0700, Junio C Hamano wrote: > "brian m. carlson" writes: > > > > @@ > > struct diff_filespec o; > > @@ > > - o.sha1_valid > > + o.oid_valid > > > > @@ > > struct diff_filespec *p; > > @@ > > - p->sha1_valid > > + p->oid_valid > > Totally offtopic (from Git's

Re: [PATCH v3 06/11] diff: rename struct diff_filespec's sha1_valid member

"brian m. carlson" writes: > @@ > struct diff_filespec o; > @@ > - o.sha1_valid > + o.oid_valid > > @@ > struct diff_filespec *p; > @@ > - p->sha1_valid > + p->oid_valid Totally offtopic (from Git's point of view), but why does Coccinelle need both of these? I recall that between v1 and v2 the

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

On Fri, Jun 24, 2016 at 03:41:47PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The difference in time between the two is measurable on my system, but > > it's only a few milliseconds (for 4096 bytes). So maybe it's not worth > > worrying about (though as a general technique, it does m

[PATCH v3 07/11] merge-recursive: convert struct stage_data to use object_id

Convert the anonymous struct within struct stage_data to use struct object_id. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct stage_data o; expression E1; @@ - o.stages[E1].sha + o.stages[E1].oid.hash @@ struct st

[PATCH v3 05/11] diff: convert struct diff_filespec to struct object_id

Convert struct diff_filespec's sha1 member to use a struct object_id called "oid" instead. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct diff_filespec o; @@ - o.sha1 + o.oid.hash @@ struct diff_filespec *p; @@ -

[PATCH v3 10/11] merge-recursive: convert merge_recursive_generic to object_id

Convert this function and the git merge-recursive subcommand to use struct object_id. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano --- builtin/merge-recursive.c | 20 ++-- merge-recursive.c | 14 +++--- merge-recursive.h | 6 +++--- 3 fi

[PATCH v3 08/11] merge-recursive: convert struct merge_file_info to object_id

Convert struct merge_file_info to use struct object_id. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct merge_file_info o; @@ - o.sha + o.oid.hash @@ struct merge_file_info *p; @@ - p->sha + p->oid.hash Signed-off

[PATCH v3 04/11] coccinelle: apply object_id Coccinelle transformations

Apply the set of semantic patches from contrib/coccinelle to convert some leftover places using struct object_id's hash member to instead use the wrapper functions that take struct object_id natively. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano --- bisect.c | 2 +-

[PATCH v3 06/11] diff: rename struct diff_filespec's sha1_valid member

Now that this struct's sha1 member is called "oid", update the comment and the sha1_valid member to be called "oid_valid" instead. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct diff_filespec o; @@ - o.sha1_valid +

[PATCH v3 02/11] contrib/coccinelle: add basic Coccinelle transforms

Coccinelle (http://coccinelle.lip6.fr/) is a program which performs mechanical transformations on C programs using semantic patches. These semantic patches can be used to implement automatic refactoring and maintenance tasks. Add a set of basic semantic patches to convert common patterns related

[PATCH v3 11/11] diff: convert prep_temp_blob to struct object_id.

All of the callers of this function use struct object_id, so convert it to use struct object_id in its arguments and internally. Signed-off-by: brian m. carlson --- diff.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/diff.c b/diff.c index 9abb54ad..8cdfdf32 100644

[PATCH v3 09/11] merge-recursive: convert leaf functions to use struct object_id

Convert all but two of the static functions in this file to use struct object_id. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano --- merge-recursive.c | 236 +++--- 1 file changed, 118 insertions(+), 118 deletions(-) diff --git a/m

[PATCH v3 00/11] struct object_id, Part 4

This series is part 4 in a series of conversions to replace instances of unsigned char [20] with struct object_id. Most of this series touches the merge-recursive code. New in this series is the use of Coccinelle (http://coccinelle.lip6.fr/) semantic patches. These semantic patches can make auto

[PATCH v3 03/11] Convert hashcpy with null_sha1 to hashclr.

hashcpy with null_sha1 as the source is equivalent to hashclr. In addition to being simpler, using hashclr may give the compiler a chance to optimize better. Convert instances of hashcpy with the source argument of null_sha1 to hashclr. This transformation was implemented using the following sem

[PATCH v3 01/11] hex: add oid_to_hex_r.

This function works just like sha1_to_hex_r, except that it takes a pointer to struct object_id instead of a pointer to unsigned char. Signed-off-by: brian m. carlson --- cache.h | 1 + hex.c | 5 + 2 files changed, 6 insertions(+) diff --git a/cache.h b/cache.h index 6049f867..7bd7c472 1

Re: [PATCH] unpack-trees: fix English grammar in do-this-before-that messages

Citando Junio C Hamano : Vasco Almeida writes: The only downside I can tell about this is translator are going to have to update those strings on their translations, but that is a normal thing to do on an active project like Git. A larger issue is this fails to update tests that check these

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

Jeff King writes: > The difference in time between the two is measurable on my system, but > it's only a few milliseconds (for 4096 bytes). So maybe it's not worth > worrying about (though as a general technique, it does make me worry > that it's easy to get wrong in a way that will fail racily).

[bug] Reliably Reproducible Bad Packing of Objects

Hi, when run on a 32 bit system (Linux system, don't know about other systems), mkdir test && cd test && git init && touch someFile && git add someFile && git commit -m "Initial commit." && dd if=/dev/urandom of=bigBinaryFile bs=1MB count=4294 && git add bigBinaryFile && git commit -m "Introduced

Re: [PATCH] unpack-trees: fix English grammar in do-this-before-that messages

Vasco Almeida writes: > The only downside I can tell about this is translator are going to have > to update those strings on their translations, but that is a normal > thing to do on an active project like Git. A larger issue is this fails to update tests that check these messages. -- To unsubs

Re: [PATCH] diff: let --output= default to --no-color

Johannes Schindelin writes: > It is highly unlikely that any user would want to see ANSI color > sequences in a file. So let's stop doing that by default. > > This is a backwards-incompatible change. > > The reason this was not caught earlier is most likely that either > --output= is not used, or

Re: [PATCH v4 08/10] format-patch: use stdout directly

Johannes Schindelin writes: > Earlier, we freopen()ed stdout in order to write patches to files. > That forced us to duplicate stdout (naming it "realstdout") because we > *still* wanted to be able to report the file names. > > As we do not abuse stdout that way anymore, we no longer need to > du

Re: [PATCH v4 06/10] format-patch: explicitly switch off color when writing to files

Johannes Schindelin writes: > We rely on the auto-detection ("is stdout a terminal?") to determine > whether to use color in the output of format-patch or not. That happens > to work because we freopen() stdout when redirecting the output to files. > > However, we are about to fix that work-aroun

Re: [PATCH 1/4] tests: factor portable signal check out of t0005

Am 24.06.2016 um 23:05 schrieb Jeff King: On Fri, Jun 24, 2016 at 10:52:32PM +0200, Johannes Sixt wrote: The Windows behavior is most closely described as having signal(SIGPIPE, SIG_IGN) at the very beginning of the program. Right, but then we would get EPIPE. So what does git do in such cases

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

On Fri, Jun 24, 2016 at 04:58:58PM -0400, Eric Sunshine wrote: > On Fri, Jun 24, 2016 at 3:07 PM, Jeff King wrote: > > On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote: > >> Jeff King writes: > >> > +tar_info () { > >> > + "$TAR" tvf "$1" | awk '{print $3 " " $4}' | cut -d- -f1 >

Re: [PATCH 1/4] tests: factor portable signal check out of t0005

On Fri, Jun 24, 2016 at 10:52:32PM +0200, Johannes Sixt wrote: > Am 24.06.2016 um 21:43 schrieb Jeff King: > > In POSIX shells, a program which exits due to a signal > > generally has an exit code of 128 plus the signal number. > > However, some platforms do other things. ksh uses 256 plus > > the

Re: [PATCH v4 01/10] Prepare log/log-tree to reuse the diffopt.close_file attribute

Johannes Schindelin writes: > We are about to teach the log-tree machinery to reuse the diffopt.file > field to output to a file stream other than stdout, in line with the > diff machinery already writing to diffopt.file. > > However, we might want to write something after the diff in > log_tree_

Re: [PATCH 1/4] tests: factor portable signal check out of t0005

Am 24.06.2016 um 21:43 schrieb Jeff King: In POSIX shells, a program which exits due to a signal generally has an exit code of 128 plus the signal number. However, some platforms do other things. ksh uses 256 plus the signal number, and on Windows, all signals are just "3". That's not true, see

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

On Fri, Jun 24, 2016 at 03:07:44PM -0400, Jeff King wrote: > > "dd bs=1 count=4096" is hopefully more portable. > > Hmm. I always wonder whether dd is actually very portable, but we do use > it already, at least. > > Perhaps the perl monstrosity in t9300 could be replaced with that, too. Hrm. S

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

On Fri, Jun 24, 2016 at 3:07 PM, Jeff King wrote: > On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote: >> Jeff King writes: >> > +tar_info () { >> > + "$TAR" tvf "$1" | awk '{print $3 " " $4}' | cut -d- -f1 >> > +} > >> Seeing an awk piped into cut always makes me want to suggest a

[PATCH] refs/files-backend: mark a file-local symbol static

Commit 6d41edc6 ("refs: add methods for reflog", 24-02-2016), moved the reflog handling into the ref-storage backend. In particular, the files_reflog_iterator_begin() API was removed from internal refs API header, resulting in sparse warnings. Signed-off-by: Ramsay Jones --- Hi Michael, If you

Loan offer for Projects Finance (1.5 -1).

Sir, I am a retired banker, currently working as a consultant. By virtue of my past working experience, I have contacts to high net worth Individuals and Investment firms in need to place funds into different projects to generate profits. The funding would be provided as a soft loan at 3% Retu

Re: [PATCH v2] Refactor recv_sideband()

On vr, 2016-06-24 at 14:14 -0400, Jeff King wrote: > On Fri, Jun 24, 2016 at 07:45:04PM +0200, Johannes Schindelin wrote: >> Do we *actually* send color via the sideband, like, ever? > We don't, but remember that we forward arbitrary output from hooks. > If the consensus is "nah, it is probably c

Re: git-svn aborts with "Use of uninitialized value $u" when a non-svn-backed branch is present in remote

Please don't drop Cc:, re-adding git@vger and Christian Jacob Godserv wrote: > > Christian (Cc-ed) also noticed the problem a few weeks ago > > and took a more drastic approach by having git-svn die > > instead of warning: > > http://mid.gmane.org/1462604323-18545-1-git-send-email-chrisc...@tuxfa

Re: [PATCH 0/4] portable signal-checking in tests

On Fri, Jun 24, 2016 at 03:39:24PM -0400, Jeff King wrote: > Anyway. Here's a series that I think makes things better, and it is not > too painful to do. > > [1/4]: tests: factor portable signal check out of t0005 > [2/4]: t0005: use test_match_signal as appropriate > [3/4]: test_must_fail:

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

Matthieu Moy writes: > Junio C Hamano writes: > >> On Wed, Jun 22, 2016 at 12:00 PM, Eric Wong wrote: >>> >>> Just wondering, who updates >>> https://kernel.org/pub/software/scm/git/docs/ >>> and why hasn't it been updated in a while? >>> (currently it says Last updated 2015-06-06 at the bottom

Re: [PATCH v3 2/4] archive-tar: write extended headers for file sizes >= 8GB

On Fri, Jun 24, 2016 at 12:45:05PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > So if anything, I would put a comment here, explaining that ustar cannot > > handle anything larger than this, and POSIX mandates it (but I didn't > > because the commit message already goes into much more

Re: [PATCH v3 2/4] archive-tar: write extended headers for file sizes >= 8GB

Jeff King writes: > So if anything, I would put a comment here, explaining that ustar cannot > handle anything larger than this, and POSIX mandates it (but I didn't > because the commit message already goes into much more detail). That sounds like a good thing to do. Not everybody runs "blame"

[PATCH 4/4] t/lib-git-daemon: use test_match_signal

When git-daemon exits, we expect it to be with the SIGTERM we just sent it. If we see anything else, we'll complain. But our check against exit code "143" is not portable. For example: $ ksh93 t5570-git-daemon.sh [...] error: git daemon exited with status: 271 We can fix this by using test_

[PATCH 3/4] test_must_fail: use test_match_signal

In 8bf4bec (add "ok=sigpipe" to test_must_fail and use it to fix flaky tests, 2015-11-27), test_must_fail learned to recognize "141" as a sigpipe failure. However, testing for a signal is more complicated than that; we should use test_match_signal to implement more portable checking. Signed-off-by

[PATCH 2/4] t0005: use test_match_signal as appropriate

The first test already uses this more portable construct (that was where it was factored from initially), but the later tests do a raw comparison against 141 to look for SIGPIPE, which can fail on some shells and platforms. Signed-off-by: Jeff King --- Again, I couldn't test these. They're skippe

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

Jeff King writes: >> > +# When parsing, we'll pull out only the year from the date; that >> > +# avoids any question of timezones impacting the result. >> >> ... as long as the month-day part is not close to the year boundary. >> So this explanation is insuffucient to convince the reader that >

[PATCH 1/4] tests: factor portable signal check out of t0005

In POSIX shells, a program which exits due to a signal generally has an exit code of 128 plus the signal number. However, some platforms do other things. ksh uses 256 plus the signal number, and on Windows, all signals are just "3". We've accounted for that in t0005, but not in other tests. Let's

[PATCH 0/4] portable signal-checking in tests

On Fri, Jun 24, 2016 at 07:05:14PM +0200, Johannes Sixt wrote: > Am 24.06.2016 um 18:46 schrieb Jeff King: > > On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote: > > > It's going to be 269 with ksh, and who-knows-what on Windows (due to lack > > > of > > > SIGPIPE - I haven't tested t

Re: git-svn aborts with "Use of uninitialized value $u" when a non-svn-backed branch is present in remote

Jacob Godserv wrote: > On Tue, Sep 22, 2015 at 2:48 PM, Jacob Godserv wrote: > > I found a specific case in which git-svn improperly aborts: > > > > 1. I created a git-svn repository, named "git-svn repo", by cloned an > > svn repository via the git-svn tool. > > 2. I created a normal git reposit

Re: [PATCH v3 3/4] archive-tar: write extended headers for far-future mtime

On Fri, Jun 24, 2016 at 12:06:59PM -0700, Junio C Hamano wrote: > > + if (args->time > 0777UL) { > > + strbuf_append_ext_header_uint(&ext_header, "mtime", > > + args->time); > > + args->time = 0777UL; > > + } > > + > >

Re: [PATCH v3 2/4] archive-tar: write extended headers for file sizes >= 8GB

On Fri, Jun 24, 2016 at 12:01:16PM -0700, Junio C Hamano wrote: > > @@ -267,7 +281,13 @@ static int write_tar_entry(struct archiver_args *args, > > memcpy(header.linkname, buffer, size); > > } > > > > - prepare_header(args, &header, mode, size); > > + size_in_header =

Re: [PATCH v3 4/4] archive-tar: drop return value

Jeff King writes: > On Fri, Jun 24, 2016 at 01:49:24PM +0200, Remi Galan Alfonso wrote: > >> Hi Peff, >> >> Jeff King writes: >> > @@ -413,7 +411,7 @@ static int write_tar_archive(const struct archiver *ar, >> > { >> > int err = 0; >> > >> > -err = write_global_extended_head

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The ustar format only has room for 11 (or 12, depending on > > some implementations) octal digits for the size and mtime of > > each file. After this, we have to add pax extended headers > > to specify the

Re: [PATCH v3 3/4] archive-tar: write extended headers for far-future mtime

Jeff King writes: > There's a slight bit of trickiness there. We may already be > ... > After writing the extended header, we munge the timestamp in > the ustar headers to the maximum-allowable size. This is > wrong, but it's the least-wrong thing we can provide to a > tar implementation that doe

Re: [PATCH v3 2/4] archive-tar: write extended headers for file sizes >= 8GB

Jeff King writes: > If the size was 64GB or greater, then we actually overflowed > digits into the mtime field, meaning our value was was was was > effectively right-shifted by those lost octal digits. And > this patch is again a strict improvement over that. > diff --git a/archive-tar.c b/arc

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

Jeff King writes: > The ustar format only has room for 11 (or 12, depending on > some implementations) octal digits for the size and mtime of > each file. After this, we have to add pax extended headers > to specify the real data, and git does not yet know how to > do so. I am not a native speak

Re: [PATCH v2] Refactor recv_sideband()

On Fri, Jun 24, 2016 at 11:14 AM, Jeff King wrote: > > I do wonder about the ANSI_SUFFIX thing, though. compat/winansi.c seems to have a provision for 'K' (and obviously 'm' for colors). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.k

Re: [PATCH] pathspec: warn on empty strings as pathspec

I suppose I got ahead of myself there. :-) Thanks for the clarification on the process. On Thu, Jun 23, 2016 at 2:17 AM, Junio C Hamano wrote: > Emily Xie writes: > >> Awesome. Thanks, Junio---this is exciting! > > No, thank _you_. > >> As for step 2: do you have a good sense on the timing? Arou

Re: Migrating away from SHA-1?

On Sat, Jun 18, 2016 at 03:10:27AM +0100, Leo Gaspard wrote: > First, sorry for not having this message threaded: I'm not subscribed to > the list and haven't found a way to get a Message-Id from gmane. Sorry it's taken so long to get back to this. I've been at a conference. > So, my questions t

Re: [PATCH v2] Refactor recv_sideband()

On Fri, Jun 24, 2016 at 07:45:04PM +0200, Johannes Schindelin wrote: > > $ git grep -A2 IMPORTANT color.h > > color.h: * IMPORTANT: Due to the way these color codes are emulated on > > Windows, > > color.h- * write them only using printf(), fprintf(), and fputs(). In > > particular, > >

[PATCH] l10n: de.po: fix translation of autostash

Signed-off-by: Ralf Thielow --- po/de.po | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/po/de.po b/po/de.po index d50cb1b..fdf4d92 100644 --- a/po/de.po +++ b/po/de.po @@ -12408,7 +12408,7 @@ msgstr "" #: git-rebase.sh:168 msgid "Applied autostash." -msgstr "\"aut

Re: [PATCH v2] Refactor recv_sideband()

Hi Peff, On Fri, 24 Jun 2016, Jeff King wrote: > On Tue, Jun 14, 2016 at 11:00:38PM +0200, Lukas Fleischer wrote: > > > Improve the readability of recv_sideband() significantly by replacing > > fragile buffer manipulations with string buffers and more sophisticated > > format strings. Note that

Re: Short-term plans for the post 2.9 cycle

On Fri, Jun 24, 2016 at 09:54:21AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > ... It's > > not a flag day for either, of course; we'll build in all of the usual > > backwards-compatibility flags. But it's convenient for users to remember > > that "3.0" is the minimum to support a ne

Re: [PATCH 0/2] strbuf: improve API

On Thu, Jun 02, 2016 at 01:11:56PM +0200, Michael Haggerty wrote: > On 06/01/2016 11:07 PM, Jeff King wrote: > > On Wed, Jun 01, 2016 at 03:42:18AM -0400, Jeff King wrote: > > > >> I have no idea if those ideas would work. But I wouldn't want to start > >> looking into either of them without some

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

Am 24.06.2016 um 18:46 schrieb Jeff King: On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote: It's going to be 269 with ksh, and who-knows-what on Windows (due to lack of SIGPIPE - I haven't tested this, yet). Thanks, I meant to ask about that. We do a workaround in t0005, but we _d

Re: Short-term plans for the post 2.9 cycle

Jeff King writes: > ... It's > not a flag day for either, of course; we'll build in all of the usual > backwards-compatibility flags. But it's convenient for users to remember > that "3.0" is the minimum to support a new slate of > backwards-incompatible features. > > So my inclination is that t

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote: > Am 24.06.2016 um 01:20 schrieb Jeff King: > > +# We expect git to die with SIGPIPE here (otherwise we > > +# would generate the whole 64GB). > > +test_expect_failure BUNZIP 'generate tar with huge size' ' > > + { > > + gi

Re: name for A..B ranges?

Jeff King writes: > On Wed, Jun 22, 2016 at 08:25:59AM +0100, Philip Oakley wrote: > >> Is there a common name for the A..B range format (two dots) that would >> complement the A...B (three dots) symmetric range format's name? >> >> I was looking at the --left-right distinctions and noticed that

Re: [PATCH v3 1/4] t5000: test tar files that overflow ustar headers

Am 24.06.2016 um 01:20 schrieb Jeff King: +# We expect git to die with SIGPIPE here (otherwise we +# would generate the whole 64GB). +test_expect_failure BUNZIP 'generate tar with huge size' ' + { + git archive HEAD + echo $? >exit-code + } | head -c 4096 >

Re: name for A..B ranges?

On Wed, Jun 22, 2016 at 08:25:59AM +0100, Philip Oakley wrote: > Is there a common name for the A..B range format (two dots) that would > complement the A...B (three dots) symmetric range format's name? > > I was looking at the --left-right distinctions and noticed that the trail > back to the sy

Re: Short-term plans for the post 2.9 cycle

On Sun, Jun 19, 2016 at 03:52:04PM -0700, Junio C Hamano wrote: > Here are the list of topics that are in the "private edition" I use > for every day work, grouped by where they sit in the the near-term > plan of merging them up to 'next' and then to 'master'. By the way, I wondered if you had th

Re: what is a snapshot?

On Sun, Jun 19, 2016 at 04:20:14PM +0100, Philip Oakley wrote: > From: "Ovatta Bianca" > > I read in every comparison of git vs other version control systems, > > that git does not record differences but takes "snapshots" > > I was wondering what a "snapshot" is ? Does git store at every commit >

Re: [PATCH v2] Refactor recv_sideband()

On Tue, Jun 14, 2016 at 11:00:38PM +0200, Lukas Fleischer wrote: > Improve the readability of recv_sideband() significantly by replacing > fragile buffer manipulations with string buffers and more sophisticated > format strings. Note that each line is printed using a single write() > syscall to av

Re: [PATCH v2 3/8] Convert struct diff_filespec to struct object_id

On Tue, Jun 21, 2016 at 03:22:04PM -0700, Junio C Hamano wrote: > "brian m. carlson" writes: > > I was trying to make sure there is no misconversion, but some lines > that got wrapped were distracting. For example: > > > @@ -2721,7 +2722,8 @@ static int diff_populate_gitlink(struct diff_filespe

Re: git-svn aborts with "Use of uninitialized value $u" when a non-svn-backed branch is present in remote

On Tue, Sep 22, 2015 at 2:48 PM, Jacob Godserv wrote: > I found a specific case in which git-svn improperly aborts: > > 1. I created a git-svn repository, named "git-svn repo", by cloned an > svn repository via the git-svn tool. > 2. I created a normal git repository, named "configuration repo". I

[PATCH v3 1/3] t4202: refactor test

Subsequent patches will want to reuse the 'signed' branch that the 'log --graph --show-signature' test creates and uses. Split the set-up part into a test of its own, and make the existing test into a separate one that only inspects the history on the 'signed' branch. This way, it becomes clearer

Re: Git Bash Slow in Windows (possible fix)

Hi, On Thu, 23 Jun 2016, UberBooster wrote: > [...] and I also installed MS Office 360. AFTER installing this > software, Git-Bash was AMAZINGLY fast. I suspect you mean Office 365. In any case, it is next to impossible to diagnose slowness after it dissipated. For the record, we do have a wi

Re: [PATCH v3 4/4] archive-tar: drop return value

On Fri, Jun 24, 2016 at 01:49:24PM +0200, Remi Galan Alfonso wrote: > Hi Peff, > > Jeff King writes: > > @@ -413,7 +411,7 @@ static int write_tar_archive(const struct archiver *ar, > > { > > int err = 0; > > > > -err = write_global_extended_header(args); > > +write_gl

Re:The global market so much, You'll only other foreign customers to your door, do not open up new ways to do?

您好，我们是能够帮您： 1、一天搜索上万家行业内匹配客人邮箱，帮您开发到B2B、展会上遇不到的优质客户。 2、高效邮件营销，帮您获得更多一对一高质量优质客户询盘。 3、让您的潜在客户主动找您洽谈订单！ 请加+QQ 3246075707 联系 在线演示主动开发全球客户，欢迎验证是否真实有效 也可加微信号：sunsesoftsam 您是选择主动出击，从源头开发优质客户，还是苦苦等待客户来联系你呢 如有不需要此信息，请回复“不需要”，我们将会将您的邮箱进行屏蔽，不再给您发信的。 祝：生意兴隆！N�Р骒r��yb�X�肚�v�^�)藓{.n�+丕��≤�}��财�z�&j:

Re: [PATCH v3 0/3] Introduce log.showSignature config variable

On Fri, Jun 24, 2016 at 5:21 AM, Mehul Jain wrote: > On Thu, Jun 23, 2016 at 12:02 PM, Junio C Hamano wrote: >> Mehul Jain writes: >>> In patch 2/3 and 3/3, there are many tests which requires a branch >>> similar to that of "signed" branch, i.e. a branch with a commit having >>> GPG signature.

Re: [PATCH] unpack-trees: fix English grammar in do-this-before-that messages

Às 05:31 de 24-06-2016, Alex Henrie escreveu: > Signed-off-by: Alex Henrie > --- > unpack-trees.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/unpack-trees.c b/unpack-trees.c > index 6bc9512..11c37fb 100644 > --- a/unpack-trees.c > +++ b/unpack-tree

Re: [PATCH v3 4/4] archive-tar: drop return value

Hi Peff, Jeff King writes: > @@ -413,7 +411,7 @@ static int write_tar_archive(const struct archiver *ar, > { > int err = 0; > > -err = write_global_extended_header(args); > +write_global_extended_header(args); > if (!err) > err = write_archive

Re: may be bug in svn fetch no-follow-parent

https://s3-eu-west-1.amazonaws.com/profff/mergeinfo.zip even ordinary merge may take up to 20-30 minutes. I'll try to trace in future 23.06.2016, 01:58, "Eric Wong" : > Александр Овчинников wrote: >>  Unfortunately this is not open source repository. I agree that it is >> pointless try to handl

  1   2   >