Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

Johannes Schindelin writes: > Oh, and v14 has a bug that I reported already: > http://article.gmane.org/gmane.comp.version-control.git/298949 These two lines are the most helpful kind of response to "What's cooking" report. Highly appreciated. The value of the

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Hi Peff, sorry for the very, very late reply. On Thu, 30 Jun 2016, Jeff King wrote: > The ustar format only has room for 11 (or 12, depending on > some implementations) octal digits for the size and mtime of > each file. For values larger than this, we have to add pax > extended headers to

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > * dt/index-helper (2016-07-06) 21 commits > - index-helper: indexhelper.exitAfter config > - trace: measure where the time is spent in the index-heavy operations > - index-helper: optionally automatically run > - index-helper: autorun

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

When using experimental features (such as worktrees), it is quite possible to end up with a repository that is a little bit corrupted. In this developer's case, the auto gc run during interactive rebases in worktrees completely messed up the reflogs. The symptoms are broken links between

Re: [PATCH v4] config: add conditional include

Hi Duy, On Thu, 14 Jul 2016, Nguyễn Thái Ngọc Duy wrote: > Helped-by: Jeff King > Signed-off-by: Nguyễn Thái Ngọc Duy This commit message is quite a bit short on details. I still fail to see what use case this would benefit, and I already start to suspect

[PATCH] mingw: fix regression in t1308-config-set

When we tried to fix in 58461bd (t1308: do not get fooled by symbolic links to the source tree, 2016-06-02) an obscure case where the user cd's into Git's source code via a symbolic link, a regression was introduced that affects all test runs on Windows. The original patch introducing the test

Bug report: 'git rebase' confusing files with initially equal content

With the following steps content from one file ends up in another file by using 'git rebase' (and clobbers the original content). It is rather straight forward and I discovered this behaviour when trying to replay http://gitforteams.com/resources/rebasing.html . The special thing is, that both

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

Hi Junio, On Tue, 12 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This is the second iteration of the long-awaited re-roll of the attempt to > > avoid spawning merge-recursive from the builtin am and use merge_recursive() > > directly instead.

Re: Bug in index-helper/watchman?

...and somehow I forgot to CC git@vger, g On Thu, Jul 14, 2016 at 5:14 PM, Duy Nguyen wrote: > Bug reports should always be in public (so people are aware of it) > unless it's security exploit of course. > > I have not read this mail yet, but I will in a couple of

[PATCH 2/3] fsck_walk(): optionally name objects on the go

If fsck_options->name_objects is initialized, and if it already has name(s) for the object(s) that are to be the starting point(s) for fsck_walk(), then that function will now add names for the objects that were walked. This will be highly useful for teaching git-fsck to identify root causes for

[PATCH 1/3] fsck: refactor how to describe objects

In many places, we refer to objects via their SHA-1s. Let's abstract that into a function. For the moment, it does nothing else than what we did previously: print out the 40-digit hex string. But that will change over the course of the next patches. Signed-off-by: Johannes Schindelin

[PATCH 3/3] fsck: optionally show more helpful info for broken links

When reporting broken links between commits/trees/blobs, it would be quite helpful at times if the user would be told how the object is supposed to be reachable. With the new --name-objects option, git-fsck will try to do exactly that: name the objects in a way that shows how they are reachable.

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

Johannes Schindelin writes: > + ret = add_cache_entry(ce, options); > + if (refresh) { > > Should we really refresh, even if ret < 0? As we stopped calling make_cache_entry() with REFRESH flag on, we can change this not to refresh if we want to, and I

[PATCH v4] config: add conditional include

Helped-by: Jeff King Signed-off-by: Nguyễn Thái Ngọc Duy --- The diff from v3 is mostly clarification in code and document. diff --git a/Documentation/config.txt b/Documentation/config.txt index 18623ee..d971334 100644 ---

Server-side preventing some files from being overwritten

Hi *, is there a way, for example with some sort of pre-receive hook, to prevent some files from being overwritten by a push? Use case: In some project, we use Flyway to manage the database schema, and Jenkins to automatically build master’s HEAD after each push (and install it, thus activating

Re: [PATCH v14 00/21] index-helper/watchman

Big typo.. On Thu, Jul 14, 2016 at 5:56 PM, Duy Nguyen wrote: > For giant-scale repos, you probably want something more efficient than > a script like this. And the good thing is you have freedom to do > whatever you want. You can run one daemon per repo, you can run one >

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Johannes Sixt writes: > Am 14.07.2016 um 17:47 schrieb Johannes Schindelin: >> On Thu, 30 Jun 2016, Jeff King wrote: >>> The ustar format only has room for 11 (or 12, depending on >>> some implementations) octal digits for the size and mtime of >>> each file. For values larger

Re: [PATCH 2/3] fsck_walk(): optionally name objects on the go

Johannes Schindelin writes: > Note that this patch opts for decorating the objects with plain strings > instead of full-blown structs (à la `struct rev_name` in the code of > the `git name-rev` command), for several reasons: > > - the code is much simpler than if it

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

The pre/post receive hook may be interested in more information from the user. This information can be transmitted when both client and server support the "push-options" capability, which when used is a phase directly after update commands ended by a flush pkt. Similar to the atomic option, the

Re: [PATCH 1/3] fsck: refactor how to describe objects

Johannes Schindelin writes: > In many places, we refer to objects via their SHA-1s. Let's abstract > that into a function. > > For the moment, it does nothing else than what we did previously: print > out the 40-digit hex string. But that will change over the course

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Am 14.07.2016 um 17:47 schrieb Johannes Schindelin: On Thu, 30 Jun 2016, Jeff King wrote: The ustar format only has room for 11 (or 12, depending on some implementations) octal digits for the size and mtime of each file. For values larger than this, we have to add pax extended headers to

Re: [PATCH v4 3/5] archive-tar: write extended headers for file sizes >= 8GB

Am 30.06.2016 um 11:09 schrieb Jeff King: +/* + * This is the max value that a ustar size header can specify, as it is fixed + * at 11 octal digits. POSIX specifies that we switch to extended headers at + * this size. + */ +#define USTAR_MAX_SIZE 0777UL This is too large by one bit for

Re: [PATCH v4 3/5] archive-tar: write extended headers for file sizes >= 8GB

Johannes Sixt writes: > Am 30.06.2016 um 11:09 schrieb Jeff King: >> +/* >> + * This is the max value that a ustar size header can specify, as it is >> fixed >> + * at 11 octal digits. POSIX specifies that we switch to extended headers at >> + * this size. >> + */ >> +#define

Re: [PATCH v14 00/21] index-helper/watchman

On Wed, Jul 13, 2016 at 11:59 PM, David Turner wrote: > On 07/12/2016 02:24 PM, Duy Nguyen wrote: >> >> Just thinking out loud. I've been thinking about this more about this. >> After the move from signal-based to unix socket for communication, we >> probably are better off

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Moving of [64BIT_TIME] lazy_prereq to test-lib might be an upside if we > were planning to add a test that depends on the system having or not > having 64-bit timestamp elsewhere, but I do not think of a reason why > such a new test cannot

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

Johannes Schindelin writes: > Example output: > > ... > broken link fromtree b5eb6ff... (refs/stash@{}~37:) > toblob ec5cf80... The objective makes sense, and their progression is very nicely structured. I can "smell" that

[PATCH 3/4] push: accept push options

This implements everything that is required on the client side to make use of push options from the porcelain push command. Signed-off-by: Stefan Beller --- Documentation/git-push.txt | 8 +++- builtin/push.c | 21 ++--- send-pack.c

[PATCH 4/4] add a test for push options

The functions `mk_repo_pair` as well as `test_refs` are borrowed from t5543-atomic-push, with additional hooks installed. Signed-off-by: Stefan Beller --- t/t5545-push-options.sh | 103 1 file changed, 103 insertions(+)

[PATCH 1/4] push options: {pre,post}-receive hook learns about push options

The environment variable GIT_PUSH_OPTION_COUNT is set to the number of push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted option. The code is not executed as the push options are set to NULL, nor is the new capability advertised. There was some discussion back and forth

[PATCHv5 0/4] Push options

Jeff wrote: > Junio wrote: >> I think those extra knobs can come later. If we are not going to >> limit with max_options in the end, however, wouldn't it be more >> natural for the initial iteration without any configuration not to >> have hard-coded max_options at all? > > Yeah, I am OK with

Re: [PATCH v4] config: add conditional include

On Thu, Jul 14, 2016 at 5:53 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 14 Jul 2016, Nguyễn Thái Ngọc Duy wrote: > >> Helped-by: Jeff King >> Signed-off-by: Nguyễn Thái Ngọc Duy > > This commit message is quite a bit short

Re: [PATCH] mingw: fix regression in t1308-config-set

Johannes Schindelin writes: > When we tried to fix in 58461bd (t1308: do not get fooled by symbolic > links to the source tree, 2016-06-02) an obscure case where the user > cd's into Git's source code via a symbolic link, a regression was > introduced that affects all

Re: Server-side preventing some files from being overwritten

On Thu, Jul 14, 2016 at 8:31 AM, Thorsten Glaser wrote: > Hi *, > > is there a way, for example with some sort of pre-receive hook, > to prevent some files from being overwritten by a push? pre-receive hooks are a thing! pre-receive This hook is invoked by

Re: Server-side preventing some files from being overwritten

On Thu, 14 Jul 2016, Stefan Beller wrote: > go roughly like Thanks, that did the trick! Although I’m ordinarily loath to write GNU bash scripts, this helps avoiding temporary files. This works: -cutting here may damage your screen surface- #!/bin/bash export LC_ALL=C subdir=x/y while

Re: Server-side preventing some files from being overwritten

On Thu, Jul 14, 2016 at 11:27 AM, Junio C Hamano wrote: > Thorsten Glaser writes: > >> if test x"0" != x"$(comm -23z \ >> <(git ls-tree -r -z "$old" "$subdir" | sort -z) \ >> <(git ls-tree -r -z "$new" "$subdir" | sort -z) | wc

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

Torsten Bögershausen writes: >> There's less redundant work going on than at first seems, because >> .gitattribute files are only read once and cached. Verified by strace. >> > OK, I think I missed that work (not enough time for Git at the moment) > Junio, please help me out, do

Re: Server-side preventing some files from being overwritten

Thorsten Glaser writes: > Although I’m ordinarily loath to write GNU bash scripts, this > helps avoiding temporary files. This works: > > -cutting here may damage your screen surface- > #!/bin/bash > export LC_ALL=C > subdir=x/y > while IFS=' ' read -r old new name;

Re: [PATCHv5 0/4] Push options

On Thu, Jul 14, 2016 at 10:39:16AM -0700, Stefan Beller wrote: > Jeff wrote: > > Junio wrote: > >> I think those extra knobs can come later. If we are not going to > >> limit with max_options in the end, however, wouldn't it be more > >> natural for the initial iteration without any

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 05:47:41PM +0200, Johannes Schindelin wrote: > On Thu, 30 Jun 2016, Jeff King wrote: > > > The ustar format only has room for 11 (or 12, depending on > > some implementations) octal digits for the size and mtime of > > each file. For values larger than this, we have to

Re: Server-side preventing some files from being overwritten

On Thu, 14 Jul 2016, Junio C Hamano wrote: > Can't this become simpler, e.g. > > if ! git diff-tree --quiet "$old" "$new" -- "$subdir" Thought about diff-tree, but additions are permitted, and diffing the actual file content has overhead too. Just counting the number of object hashes

Re: Server-side preventing some files from being overwritten

On Thu, Jul 14, 2016 at 11:44 AM, Junio C Hamano wrote: > On Thu, Jul 14, 2016 at 11:27 AM, Junio C Hamano wrote: >> Thorsten Glaser writes: >> >>> if test x"0" != x"$(comm -23z \ >>> <(git ls-tree -r -z "$old" "$subdir"

Re: [PATCHv5 0/4] Push options

On Thu, Jul 14, 2016 at 11:48:58AM -0700, Stefan Beller wrote: > > Hmm. So that is a downside for people who have implemented separate > > DoS protection only in that upgrading git will open a new "hole" > > that they need to plug. But that is their problem, not upstream > > git's. > > > > -Peff

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

Stefan Beller writes: >>> + lf = strchr(line, '\n'); >>> + if (lf) >>> + *lf = '\0'; >> >> packet_read_line() -> packet_read_line_generic() calls packet_read() >> with PACKET_READ_CHOMP_NEWLINE flag bit; do we need this check? > >

[PATCH] diff: document diff-filter exclusion

In v1.8.5 days, 7f2ea5f0 (diff: allow lowercase letter to specify what change class to exclude, 2013-07-17) taught the "--diff-filter" mechanism to take lowercase letters as exclusion, but we forgot to document it. Signed-off-by: Junio C Hamano ---

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

Stefan Beller writes: > +static struct string_list *read_push_options(void) > +{ > + struct string_list *ret = xmalloc(sizeof(*ret)); > + string_list_init(ret, 1); > + > + while (1) { > + char *line, *lf; > + int len; > + > +

Re: Server-side preventing some files from being overwritten

Thorsten Glaser writes: > On Thu, 14 Jul 2016, Junio C Hamano wrote: > >> Can't this become simpler, e.g. >> >> if ! git diff-tree --quiet "$old" "$new" -- "$subdir" > > Thought about diff-tree, but additions are permitted, diff-tree -r --diff-filter=a "$old"

Re: [PATCH] mingw: fix regression in t1308-config-set

On Thu, Jul 14, 2016 at 09:18:18AM -0700, Junio C Hamano wrote: > I added a few missing Cc: and quoted the whole patch here to those > who were involved; I think this update is correct, but just trying > to make sure people know. > > Not limited to this particular topic, there probably are some

Re: [PATCH] diff: document diff-filter exclusion

On Thu, Jul 14, 2016 at 12:20 PM, Junio C Hamano wrote: > In v1.8.5 days, 7f2ea5f0 (diff: allow lowercase letter to specify > what change class to exclude, 2013-07-17) taught the "--diff-filter" > mechanism to take lowercase letters as exclusion, but we forgot to > document it.

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Jeff King writes: > On Thu, Jul 14, 2016 at 05:47:41PM +0200, Johannes Schindelin wrote: > >> On Thu, 30 Jun 2016, Jeff King wrote: >> >> > The ustar format only has room for 11 (or 12, depending on >> > some implementations) octal digits for the size and mtime of >> > each file.

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

Jeff King writes: > packet_read() does NUL-terminate for you. It gets the extra bytes > because it doesn't store the 4-byte size in the output (whereas the > client does not ever send anything over LARGE_PACKET_MAX, _including_ > those bytes, so we always have room to store its

[PATCH] Use path comparison for patch ids before the file content

When limiting the list in a revision walk using cherry pick, patch ids are calculated by producing the diff of the content of the files. This would be more efficent by using a patch id looking at the paths that were changed in the commits and only if all the file changed are the same fall back to

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Junio C Hamano writes: > OK, how about this on top of a replacement for js/t0006-for-v2.9.2 > that I'll send out as a reply to this message? which is this one, which is largely from your $gmane/299310. -- >8 -- From: Jeff King Date: Mon, 11 Jul 2016 19:54:18

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 01:00:08PM -0700, Junio C Hamano wrote: > > There's tons of discussion in: > > > > http://thread.gmane.org/gmane.comp.version-control.git/297409 > > > > but frankly it is not worth your time to read it. These tests are about > > overflowing the tar limits, which can only

[PATCH v2 2/2] archive-tar: huge offset and future timestamps would not work on 32-bit

As we are not yet moving everything to size_t but still using ulong internally when talking about the size of object, platforms with 32-bit long will not be able to produce tar archive with 4GB+ file, and cannot grok 0777UL as a constant. Disable the extended header feature and do not

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Am 14.07.2016 um 19:08 schrieb Junio C Hamano: Johannes Sixt writes: Am 14.07.2016 um 17:47 schrieb Johannes Schindelin: On Thu, 30 Jun 2016, Jeff King wrote: The ustar format only has room for 11 (or 12, depending on some implementations) octal digits for the size and mtime

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

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 > 'master'. > > Now, I think it would be okay to wait

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

On Thu, Jul 14, 2016 at 12:07:15PM -0700, Junio C Hamano wrote: > > Although as you remarked in another email, this would not pose a problem for > > the shell variable, so we could also drop it to allow multi line > > options. will do. > > One thing to note is that I do not think there is a

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 01:03:35PM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > OK, how about this on top of a replacement for js/t0006-for-v2.9.2 > > that I'll send out as a reply to this message? > > which is this one, which is largely from your

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Jeff King writes: > Yeah, that is what I was trying to get at, but you stated it much more > clearly. LONG_IS_64BIT is good. I wonder if the "git version > --build-options" should be "sizeof-long", too. It's shorter, and > indicates our assumption that we are talking about all

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Junio C Hamano writes: > OK, how about this on top of a replacement for js/t0006-for-v2.9.2 > that I'll send out as a reply to this message? I won't repeat the patch body, but I had to write a log message, so here is what I tentatively committed (not queued yet). Subject:

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Jeff King writes: >> +#if ULONG_MAX == 0x7FFF >> +#define USTAR_MAX_SIZE ULONG_MAX >> +#define USTAR_MAX_MTIME ULONG_MAX >> +#else >> #define USTAR_MAX_SIZE 0777UL >> #define USTAR_MAX_MTIME 0777UL >> +#endif >> >> /* writes out the whole block, but only

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 01:22:01PM -0700, Junio C Hamano wrote: > > Also, shouldn't it be checking against 0x? > > Correct. Somehow I thought I was checking with LONG_MAX. Will correct. > > > An easier check would be "sizeof()", but I guess we can't use that in a > > preprocessor

[PATCH v2 1/2] t0006: skip "far in the future" test when unsigned long is not long enough

From: Jeff King Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". While we can fix this issue properly by replacing unsigned long with a

[PATCH v2 0/2] ulong may only be 32-bit wide

So here is the final reroll from me for now that targets 'maint' (eventually). Jeff King (1): t0006: skip "far in the future" test when unsigned long is not long enough Junio C Hamano (1): archive-tar: huge offset and future timestamps would not work on 32-bit archive-tar.c |

Re: [PATCH] t1308: do not get fooled by symbolic links to the source tree

Hi, On Fri, 3 Jun 2016, Torsten Bögershausen wrote: > On 06/03/2016 08:53 AM, Johannes Sixt wrote: > > Am 03.06.2016 um 08:10 schrieb Jeff King: > > > On Fri, Jun 03, 2016 at 08:05:56AM +0200, Johannes Sixt wrote: > > > > > > > > -name=$(pwd)/.gitconfig > > > > > +name=$HOME/.gitconfig >

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > * js/t0006-for-v2.9.2 (2016-07-12) 1 commit > - t0006: skip "far in the future" test when unsigned long is not long enough > > A test merged to v2.9.1 forgot that the feature it was testing > would not work on a platform with 32-bit

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > * jc/renormalize-merge-kill-safer-crlf (2016-07-12) 2 commits > - merge: avoid "safer crlf" during recording of merge results I like the verbose commit message, it really makes it easier to understand the issue as well as the solution. As

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 10:52:55PM +0200, Johannes Sixt wrote: > > Dscho? I'll revert the merge of 'js/t0006-for-v2.9.2' out of > > 'next' so that we can replace it with your newer version, but it > > needs to be massaged to lose the strong linkage with "time", as > > it is no longer "is our

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

On Thu, Jul 14, 2016 at 02:24:54PM -0700, Stefan Beller wrote: > # interdiff to v5: > [...giant deletion...] Much nicer. :) > +static struct string_list *read_push_options(void) > +{ > + struct string_list *ret = xmalloc(sizeof(*ret)); This struck me as a little non-idiomatic for our code

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

On Thu, Jul 14, 2016 at 2:35 PM, Jeff King wrote: > On Thu, Jul 14, 2016 at 02:24:54PM -0700, Stefan Beller wrote: > >> # interdiff to v5: >> [...giant deletion...] > > Much nicer. :) > >> +static struct string_list *read_push_options(void) >> +{ >> + struct string_list *ret =

[PATCHv7 0/4] Push options

Jeff, here is the more idiomatic way. Thanks, Stefan diff to v6: diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index 9bb9afc..3c9360a 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -1499,11 +1499,8 @@ static struct command *read_head_info(struct sha1_array

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

The pre/post receive hook may be interested in more information from the user. This information can be transmitted when both client and server support the "push-options" capability, which when used is a phase directly after update commands ended by a flush pkt. Similar to the atomic option, the

Re: [PATCH v14 00/21] index-helper/watchman

Duy Nguyen gmail.com> writes: > > On Wed, Jul 13, 2016 at 11:59 PM, David Turner novalis.org> wrote: > > On 07/12/2016 02:24 PM, Duy Nguyen wrote: > >> > >> Just thinking out loud. I've been thinking about this more about this. > >> After the move from signal-based to unix socket for

Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

On Thu, Jul 14, 2016 at 12:58:47PM +0200, Johannes Schindelin wrote: > Hi Mike, > > On Thu, 14 Jul 2016, Mike Hommey wrote: > > > On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote: > > > Hi Junio, > > > > > > On Wed, 13 Jul 2016, Junio C Hamano wrote: > > > > > > > Does

Re: [PATCH v2 2/2] archive-tar: huge offset and future timestamps would not work on 32-bit

On Thu, Jul 14, 2016 at 01:43:57PM -0700, Junio C Hamano wrote: > As we are not yet moving everything to size_t but still using ulong > internally when talking about the size of object, platforms with > 32-bit long will not be able to produce tar archive with 4GB+ file, > and cannot grok

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Johannes Sixt writes: > My first thought was that this is not warranted because t0006 is about > commit time stamps, but the huge-tar breakage is file sizes, and the > cases should be treated differently. > > But on second thought, under the hood, both boil down to the size of >

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Jeff King writes: > If we move to time_t everywhere, I think we'll need an extra > TIME_T_IS_64BIT, but we can cross that bridge when we come to it. > > Likewise I think we'll need SIZE_T_IS_64BIT eventually (for real 32-bit > systems; LLP64 systems like Windows will then be able

Re: [PATCH v2 2/2] archive-tar: huge offset and future timestamps would not work on 32-bit

Jeff King writes: > On Thu, Jul 14, 2016 at 01:43:57PM -0700, Junio C Hamano wrote: > >> As we are not yet moving everything to size_t but still using ulong >> internally when talking about the size of object, platforms with >> 32-bit long will not be able to produce tar archive

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 03:30:58PM -0700, Junio C Hamano wrote: > > If we move to time_t everywhere, I think we'll need an extra > > TIME_T_IS_64BIT, but we can cross that bridge when we come to it. > > > > Likewise I think we'll need SIZE_T_IS_64BIT eventually (for real 32-bit > > systems; LLP64

Re: [PATCHv7 0/4] Push options

Stefan Beller writes: > Jeff, > > here is the more idiomatic way. > > Thanks, > Stefan Looks good to me. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH 1/4] push options: {pre,post}-receive hook learns about push options

On Thu, Jul 14, 2016 at 02:49:45PM -0700, Stefan Beller wrote: > We limit the push options for now > * to not exceed an arbitrary count, and > * to not exceed an arbitrary size. > > This serves two purposes: > * DoS protection (i.e. one connection can add no more than 32kB > now) > * We need

Re: [PATCH 1/4] push options: {pre,post}-receive hook learns about push options

On Thu, Jul 14, 2016 at 3:46 PM, Jeff King wrote: > On Thu, Jul 14, 2016 at 02:49:45PM -0700, Stefan Beller wrote: > >> We limit the push options for now >> * to not exceed an arbitrary count, and >> * to not exceed an arbitrary size. >> >> This serves two purposes: >> * DoS

Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

Hi Mike, On Thu, 14 Jul 2016, Mike Hommey wrote: > On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote: > > Hi Junio, > > > > On Wed, 13 Jul 2016, Junio C Hamano wrote: > > > > > Does Travis CI testing have an option to run our tests on some > > > 32-bit platforms? > > > >

Svare

Dr. Alex Morgan Drift / regionsjef Santander Bank Plc, 47-48 Piccadilly PICCADILLY W1J0DT London, Storbritannia Hei venn, Jeg er Dr. Alex Morgan, fra Harlesden North West London, leder for regnskap Revisjonen og formell senior programmerer sjef hos Deutsche bank, her i England (Santander Bank

Re: [ANNOUNCE] Git v2.9.1

On 13 Jul 2016, at 22:43, Junio C Hamano wrote: > Junio C Hamano writes: > >> It is somewhat disturbing that nobody seems to be regularly building >> on 32-bit platforms these days, which is the only reason I can think >> of why this was never reported

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > How about this one instead (which is part of the time_t-may-be-int64 > > branch on https://github.com/dscho/git which I still have to complete, as > > some unsigned longs still

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > So I got curious and looked at the man page. It says indeed that strtoul() > returns ULONG_MAX, which happens to translate into a date in the year > 2038. 4294967295 would rather be 2106. $ date -d @$((0x)) So 7. Feb 07:28:15

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> I was hoping to hear from you sooner and do v2.9.2 with your t0006 > >> workaround with lazy-prereq changes from Peff (i.e. "Makes sense!" > >> above), so that you do not have

Re: [ANNOUNCE] Git v2.9.1

tl;dr I don't really care which fix goes in. They are both fine with me, and in practice I cannot imagine either causing a big problem. But here are my thoughts because I know you want them. On Thu, Jul 14, 2016 at 09:45:12AM +0200, Johannes Schindelin wrote: > > Hmm, sorry, I do not see much

Re: Multiple Keys in ssh-agent, fail to clone

Hi Benjamin, On Wed, 13 Jul 2016, Benjamin Fritsch wrote: > I have two keys. > - KeyA (my company that has access to the repository I want to clone) > - KeyB (just my personal key with access to my personal stuff) > > Having both keys in loaded and listed in `ssh-add -L` fails to clone the >

32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Does Travis CI testing have an option to run our tests on some > 32-bit platforms? AFAIR Docker does not support 32-bit, and IIRC that's what Travis uses. However, it is possible to install a 32-bit toolchain and use that to compile Git.

Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote: > Hi Junio, > > On Wed, 13 Jul 2016, Junio C Hamano wrote: > > > Does Travis CI testing have an option to run our tests on some > > 32-bit platforms? > > AFAIR Docker does not support 32-bit, and IIRC that's what Travis uses.

Re: [PATCH] Use path comparison for patch ids before the file content

Kevin Willford writes: > When limiting the list in a revision walk using cherry pick, patch ids are > calculated by producing the diff of the content of the files. This would > be more efficent by using a patch id looking at the paths that were > changed in the commits and

[PATCH 1/4] push options: {pre,post}-receive hook learns about push options

The environment variable GIT_PUSH_OPTION_COUNT is set to the number of push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted option. The code is not executed as the push options are set to NULL, nor is the new capability advertised. There was some discussion back and forth

[PATCH 4/4] add a test for push options

The functions `mk_repo_pair` as well as `test_refs` are borrowed from t5543-atomic-push, with additional hooks installed. Signed-off-by: Stefan Beller --- t/t5545-push-options.sh | 103 1 file changed, 103 insertions(+)

[PATCH 3/4] push: accept push options

This implements everything that is required on the client side to make use of push options from the porcelain push command. Signed-off-by: Stefan Beller --- Documentation/git-push.txt | 8 +++- builtin/push.c | 21 ++--- send-pack.c

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

The pre/post receive hook may be interested in more information from the user. This information can be transmitted when both client and server support the "push-options" capability, which when used is a phase directly after update commands ended by a flush pkt. Similar to the atomic option, the

Re: [PATCH v4 3/5] archive-tar: write extended headers for file sizes >= 8GB

On Thu, Jul 14, 2016 at 10:11:18AM -0700, Junio C Hamano wrote: > Johannes Sixt writes: > > > Am 30.06.2016 um 11:09 schrieb Jeff King: > >> +/* > >> + * This is the max value that a ustar size header can specify, as it is > >> fixed > >> + * at 11 octal digits. POSIX specifies

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 06:45:47PM +0200, Johannes Sixt wrote: > Am 14.07.2016 um 17:47 schrieb Johannes Schindelin: > > On Thu, 30 Jun 2016, Jeff King wrote: > > > The ustar format only has room for 11 (or 12, depending on > > > some implementations) octal digits for the size and mtime of > > >

Re: [PATCHv5 0/4] Push options

On Thu, Jul 14, 2016 at 11:41 AM, Jeff King wrote: > On Thu, Jul 14, 2016 at 10:39:16AM -0700, Stefan Beller wrote: > >> Jeff wrote: >> > Junio wrote: >> >> I think those extra knobs can come later. If we are not going to >> >> limit with max_options in the end, however, wouldn't

  1   2   >