Re: [PATCH v4] http.postbuffer: allow full range of ssize_t values

On 03.04.17 19:30, David Turner wrote: > Unfortunately, in order to push some large repos, the http postbuffer > must sometimes exceed two gigabytes. On a 64-bit system, this is OK: > we just malloc a larger buffer. > > This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the >

Re: [PATCH v2 4/8] Specify explicitly where we parse timestamps

[] --- a/git-compat-util.h +++ b/git-compat-util.h @@ -319,6 +319,8 @@ extern char *gitdirname(char *); #define PRIo32 "o" #endif +#define parse_timestamp strtoul + Would #define parse_timestamp(a,b,c) strtoul((a),(b),(c)) be more strict ?

Re: [PATCH v2 1/8] ref-filter: avoid using `unsigned long` for catch-all data type

On 02/04/17 21:06, Johannes Schindelin wrote: In its `atom_value` struct, the ref-filter source code wants to store different values in a field called `ul` (for `unsigned long`), e.g. timestamps. However, as we are about to switch the data type of timestamps away from `unsigned long` (because

Re: [BUG?] iconv used as textconv, and spurious ^M on added lines on Windows

On 2017-03-31 21:44, Jakub Narębski wrote: > W dniu 31.03.2017 o 14:38, Torsten Bögershausen pisze: >> On 30.03.17 21:35, Jakub Narębski wrote: >>> Hello, >>> >>> Recently I had to work on a project which uses legacy 8-bit encoding >>> (namely cp1

Re: [BUG?] iconv used as textconv, and spurious ^M on added lines on Windows

On 30.03.17 21:35, Jakub Narębski wrote: > Hello, > > Recently I had to work on a project which uses legacy 8-bit encoding > (namely cp1250 encoding) instead of utf-8 for text files (LaTeX > documents). My terminal, that is Git Bash from Git for Windows is set > up for utf-8. > > I wanted for

Re: [PATCH] http.postbuffer: make a size_t

On 30/03/17 22:29, David Turner wrote: Unfortunately, in order to push some large repos, the http postbuffer must sometimes exceed two gigabytes. On a 64-bit system, this is OK: we just malloc a larger buffer. Signed-off-by: David Turner --- cache.h | 1 + config.c

Re: [PATCH v2 1/2] pkt-line: add packet_writel() and packet_read_line_gently()

On 30.03.17 18:01, Ben Peart wrote: >> From: Torsten Bögershausen [mailto:tbo...@web.de] >> >> >> Does this work ? >> I would have expected >> packet_writel(fd, "line one", "line two", "line n"), NULL; Typo. Should h

Re: [PATCH v2 1/2] pkt-line: add packet_writel() and packet_read_line_gently()

[snip] Would packet_write_lines make more sense ? Just goes to prove that there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. :) The feedback on V1 was: "I am hesitant to take a function that does not take any "list" type argument and

Re: t1503 broken ?

On 03/25/2017 02:05 PM, Duy Nguyen wrote: On Sat, Mar 25, 2017 at 07:26:14PM +0700, Duy Nguyen wrote: On Sat, Mar 25, 2017 at 6:46 PM, Duy Nguyen <pclo...@gmail.com> wrote: On Sat, Mar 25, 2017 at 5:46 PM, Torsten Bögershausen <tbo...@web.de> wrote: ./t1305-config-incl

t1503 broken ?

./t1305-config-include.sh seems to be broken: not ok 19 - conditional include, $HOME expansion not ok 21 - conditional include, relative path Both Mac and Linux. The problem seems to be the line git config test.two >actual && and git config test.four >actual && In both cases the config

Re: [PATCH v2 1/2] pkt-line: add packet_writel() and packet_read_line_gently()

On 2017-03-24 16:27, Ben Peart wrote: > Add packet_writel() which writes multiple lines in a single call and > then calls packet_flush_gently(). Add packet_read_line_gently() to > enable reading a line without dying on EOF. > > Signed-off-by: Ben Peart > --- > pkt-line.c

Re: [GSoC][PATCH v4] t2027: avoid using pipes

On 24/03/17 09:27, Prathamesh Chavan wrote: From: Prathamesh Welcome to Git. The name in the "From:" must match the name in the sign-off: git config --global user.name "Prathamesh Chavan" Signed-off-by: Prathamesh Chavan The patch looks good

Re: File names are considered case insensitive in a folder. (aBcd.py ==AbcD.py) Inbox x

On 17/03/17 10:28, Vish Gite wrote: Hello, Git 2.10.1 on Apple mac is treating different(uppercase/lowercase) files as same name(e.g ABCD.py and abcd.py) In a project where file name is same but case is different, either ABCD.py or abcd.py. There is always one of these files is modified.

Re: Commiting files larger than 4 GB on Windows

On 15/03/17 22:29, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: The real "show stopper" is at the end. ... == And it seams as if zlib is the limitation here. Unless we include the zlib source code into Git and redefine uLong, is

Re: Commiting files larger than 4 GB on Windows

On 2017-03-15 17:13, Jeff King wrote: > On Wed, Mar 15, 2017 at 11:59:52AM -0400, Jeff King wrote: > >> I agree that detecting the situation in the meantime is a good idea. >> The patch above probably handles the bulk-checkin code path, I'd guess. >> It might be nice to have similar checks in

Re: Git download

On 03/05/2017 09:26 PM, Cory Kilpatrick wrote: I have downloaded Git and cannot find the application on my Mac. Should I try to download it again? I don't think so. It could be helpful if we can get some more information: - Could you open the terminal application and type which git git

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On 2017-03-03 18:47, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> Understood, thanks for the explanation. >> >> quiet is not quite any more.. >> >> Does the following fix help ? >> >> --- a/diff.c >> +++

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

Understood, thanks for the explanation. quiet is not quite any more.. Does the following fix help ? --- a/diff.c +++ b/diff.c @@ -2826,6 +2826,8 @@ int diff_populate_filespec(struct diff_filespec *s, unsigned int flags) enum safe_crlf crlf_warn = (safe_crlf == SAFE_CRLF_FAIL

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On 2017-03-02 15:20, Mike Crowe wrote: > ll the solutions presented so far do cause a small change in behaviour > when using git diff --quiet: they may now cause warning messages like: > > warning: CRLF will be replaced by LF in crlf.txt. > The file will have its original line endings in your

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

d" will not do any changes to the index, and >> "git diff -quiet" should exit 0. >> >> Add calls to would_convert_to_git() before blindly saying that a different >> size means different content. >> >> Reported-By: Mike Crowe <m...@mcrowe.com> &g

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

On 2017-02-27 21:17, Junio C Hamano wrote: > Torsten, you've been quite active in fixing various glitches around > the EOL conversion in the latter half of last year. Have any > thoughts to share on this topic? > > Thanks. Sorry for the delay, being too busy with other things. I followed the

Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

On Sun, Jan 08, 2017 at 08:17:36PM +0100, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > Some `clean` / `smudge` filters might require a significant amount of > time to process a single blob. During this process the Git checkout > operation is blocked and

Re: Git filesystem case-insensitive to case-sensitive system broken

On Fri, Jan 06, 2017 at 01:56:36PM -0800, Steven Robertson wrote: > Hello, > > I was doing development on a linux box on AWS, when we found a code > bug that had me switching to running the code on a Mac instead. We > discovered that we had accidentally named two files the same when > looked at

Re: [PATCH v4 0/5] road to reentrant real_path

On 04.01.17 01:48, Jeff King wrote: > On Tue, Jan 03, 2017 at 11:09:18AM -0800, Brandon Williams wrote: > >> Only change with v4 is in [1/5] renaming the #define MAXSYMLINKS back to >> MAXDEPTH due to a naming conflict brought up by Lars Schneider. > > Hmm. Isn't MAXSYMLINKS basically what you

Re: Test failures when Git is built with libpcre and grep is built without it

On 01.01.17 05:59, A. Wilcox wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello! > > I'm attempting to package Git for our new Linux distribution and I > have run in to a failure on our PowerPC builder while running the test > suite. > > The PowerPC builder runs a tiny version

Re: [PATCH v2] fix pushing to //server/share/dir on Windows

On 14/12/16 20:37, Johannes Sixt wrote: normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

Sure, and I'd rather see the update-unicode.sh script moved somewhere in contrib/ while at it. Those who are interested in keeping up with the unicode standard are tiny minority of the developer population, and most of us would treat the built width table as the source (after all, that is what

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

>> Minor question, especially to the next commit: >> Should we make sure to checkout the exact version, which has been tested? >> In this case cb97792880625e24a9f581412d03659091a0e54f >> >> And this is for both a fresh clone and the git pull >> needs to be replaced by >> git fetch && git

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

On 2016-12-12 00:34, Beat Bolli wrote: > We need to track the new commits in uniset, otherwise their and our code > get out of sync. > > Signed-off-by: Beat Bolli > --- > > Junio, these go on top of my bb/unicode-9.0 branch, please. > > Thanks! > > update_unicode.sh | 5

Re: [PATCH] real_path: make real_path thread-safe

On Wed, Dec 07, 2016 at 02:13:35PM -0800, Brandon Williams wrote: > On 12/07, Junio C Hamano wrote: > > Torsten Bögershausen <tbo...@web.de> writes: > > > > > But in any case it seems that e.g. > > > //SEFVER/SHARE/DIR1/DIR2/.. > > >

Re: [PATCH] real_path: make real_path thread-safe

On Wed, Dec 07, 2016 at 01:12:25AM +, Ramsay Jones wrote: > > > On 07/12/16 00:10, Brandon Williams wrote: > > On 12/06, Junio C Hamano wrote: > >> POSIX cares about treating "//" at the very beginning of the path > >> specially. Is that supposed to be handled here, or by a lot higher > >>

Re: git 2.11.0 error when pushing to remote located on a windows share

On 2016-12-05 12:05, thomas.attw...@stfc.ac.uk wrote: > On Sun, 4 Dec 2016 08:09:14 +, Torsten Bögershausen wrote: >> There seems to be another issue, which may or may not being related: >> https://github.com/git-for-windows/git/issues/979 > > I think this is the same issue. I've posted my

Re: git 2.11.0 error when pushing to remote located on a windows share

On Fri, Dec 02, 2016 at 05:37:50PM -0500, Jeff King wrote: > On Fri, Dec 02, 2016 at 06:02:16PM +, thomas.attw...@stfc.ac.uk wrote: > > > After updating git from 2.10.0 to 2.11.0 when trying to push any > > changes to a repo located in a windows share, the following error > > occurs: > > > >

Re: [PATCH v4 1/3] update-unicode.sh: automatically download newer definition files

On Sat, Dec 03, 2016 at 10:00:47PM +0100, Beat Bolli wrote: > Checking just for the unicode data files' existence is not sufficient; > we should also download them if a newer version exists on the Unicode > consortium's servers. Option -N of wget does this nicely for us. > > Reviewed-by: Torsten

Re: [PATCH v2 1/1] convert: git cherry-pick -Xrenormalize did not work

Yup, this is what I queued. Looks good, thanks you all.

Re: [PATCH v1 1/1] convert: git cherry-pick -Xrenormalize did not work

On Tue, Nov 29, 2016 at 10:42:18AM -0800, Junio C Hamano wrote: > tbo...@web.de writes: > > > From: Torsten Bögershausen <tbo...@web.de> > > > > Working with a repo that used to be all CRLF. At some point it > > was changed to all LF, with `text=auto` in .gita

Re: cherry-pick -Xrenormalize fails with formerly CRLF files

On Sun, Nov 27, 2016 at 10:19:35PM -0800, Eevee (Lexy Munroe) wrote: > I'm working with a repo that used to be all CRLF. At some point it > was changed to all LF, with `text=auto` in .gitattributes for the > sake of Windows devs. I'm on Linux and have never touched any > twiddles relating to

Re: [PATCH v8 07/10] convert: unify the "auto" handling of CRLF

RFH, the normalization as descrived in Documentation/gitattributes.txt does not work anymore: >From a clean working directory: - $ echo "* text=auto" >.gitattributes $ rm .git/index # Remove the index to force Git to $ git reset #

Re: [PATCH] Remove dependency on deprecated Net::SMTP::SSL

On 20/11/16 22:18, Mike Fisher wrote: Thanks for contributing to Git. One comment on the head line: >Refactor send_message() to remove dependency on deprecated Net::SMTP::SSL The word "refactor" may be used in other way: Re-structure the code, and use the same API. "Remove dependency on

Re: merge --no-ff is NOT mentioned in help

On 17/11/16 18:10, Junio C Hamano wrote: Mike Rappazzo writes: (Please reply inline) Indeed ;-) On Wed, Nov 16, 2016 at 10:48 AM, Vanderhoof, Tzadik wrote: I am running:git version 2.10.1.windows.1 I typed: git merge -h and got:

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

On 16.11.16 15:39, Heiko Voigt wrote: > On Tue, Nov 15, 2016 at 10:31:59AM -0500, Jeff King wrote: >> On Tue, Nov 15, 2016 at 01:07:18PM +0100, Heiko Voigt wrote: >> >>> On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote: To all macOS users on the list: Does anyone execute

Re: [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables

On 14.11.16 10:11, Lars Schneider wrote: > >> On 13 Nov 2016, at 02:13, Junio C Hamano wrote: >> >> Johannes Schindelin writes: >> Thanks. Dscho, does this fix both of these issues to you? >>> >>> Apparently it does because the CI jobs for

Re: [PATCH v1 0/2] Fix default macOS build locally and on Travis CI

On 10/11/16 00:39, Junio C Hamano wrote: I've followed what was available at the public-inbox archive, but it is unclear what the conclusion was. For the first one your "how about" non-patch, to which Peff said "that's simple and good", looked good to me as well, but is it available as a

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

On 09.11.16 10:29, Lars Schneider wrote: > >> On 09 Nov 2016, at 09:18, Torsten Bögershausen <tbo...@web.de> wrote: >> >> On 07.11.16 18:26, Jeff King wrote: >>> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote: >>> >>>>

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

On 07.11.16 18:26, Jeff King wrote: > On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote: > >> Good point. I think I found an even easier way to achieve the same. >> What do you think about the patch below? >> >> [...] >> >> diff --git a/Makefile b/Makefile >> index 9d6c245..f53fcc9

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

> * st/verify-tag (2016-10-10) 7 commits > - t/t7004-tag: Add --format specifier tests > - t/t7030-verify-tag: Add --format specifier tests > - builtin/tag: add --format argument for tag -v > - builtin/verify-tag: add --format to verify-tag > - tag: add format specifier to gpg_verify_tag > -

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

On Thu, Nov 03, 2016 at 09:30:44AM -0400, Martin-Louis Bright wrote: > I will see if I can find a OSX 10.6 system to test with, and I'll try with > perl 5.10. > > --Martin No need to worry too much: I have tested Peffs patch applied on next OK- And the integration into pu that came the 2nd

Re: [PATCH 4/4] t0021: fix filehandle usage on older perl

> +use IO::File; That did the trick (the J6T version work as well) Thanks for the fast responses.

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

> * ls/filter-process (2016-10-17) 14 commits > (merged to 'next' on 2016-10-19 at ffd0de042c) Some (late, as I recently got a new battery for the Mac OS 10.6 test system) comments: t0021 failes here: Can't locate object method "flush" via package "IO::Handle" at

Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)

> > * tb/convert-stream-check (2016-10-27) 2 commits > - convert.c: stream and fast search for binary > - read-cache: factor out get_sha1_from_index() helper > > End-of-line conversion sometimes needs to see if the current blob > in the index has NULs and CRs to base its decision. We used

Re: [PATCH v2 2/2] convert.c: stream and fast search for binary

[] > This probably should be done as four more patches to become > reviewable. > > - One to use the CONVERT_STAT_BITS a lot more for the conversion >decision than before, > > - another to allow the caller to tell gather_stats() to give up >early with the "search_only" bits, > > -

Re: [PATCH] rev-list: restore the NUL commit separator in --header mode

diff --git a/t/t6000-rev-list-misc.sh b/t/t6000-rev-list-misc.sh index 3e752ce..a2acff3 100755 --- a/t/t6000-rev-list-misc.sh +++ b/t/t6000-rev-list-misc.sh @@ -100,4 +100,11 @@ test_expect_success '--bisect and --first-parent can not be combined' ' test_must_fail git rev-list --bisect

Re: [RFC] Case insensitive Git attributes

On 17/10/16 05:07, Stefan Beller wrote: On Sun, Oct 16, 2016 at 6:04 PM, Lars Schneider wrote: Hi, Git attributes for path names are generally case sensitive. However, on a case insensitive file system (e.g. macOS/Windows) they appear to be case insensitive

Re: [PATCH v3 07/25] sequencer: completely revamp the "todo" script parsing

On 15.10.16 19:19, Jeff King wrote: > On Sat, Oct 15, 2016 at 07:03:46PM +0200, Torsten Bögershausen wrote: > >> sequencer.c:633:14: warning: comparison of constant 2 with expression of >> type 'const enum todo_command' is always true >> [-Wtautological-const

Re: [PATCH v3 07/25] sequencer: completely revamp the "todo" script parsing

Not sure is this has been reported before: sequencer.c:633:14: warning: comparison of constant 2 with expression of type 'const enum todo_command' is always true [-Wtautological-constant-out-of-range-compare] if (command < ARRAY_SIZE(todo_command_strings)) ~~~ ^

Re: 2 directories same spelling one directory is camel cased

On 12.10.16 18:05, David Brown wrote: > Howdy git gurus, > > I have the dubious distinction of working with a remote repo (master) that > has a class loader run-time error when cloned, built and executed. > > The reason for the runtime issue is a directory hierarchical path has to >

Re: [PATCH v10 13/14] convert: add filter..process option

On Tue, Oct 11, 2016 at 10:11:22AM +0200, Lars Schneider wrote: > > > On 10 Oct 2016, at 21:58, Junio C Hamano wrote: > > > > larsxschnei...@gmail.com writes: > > > > [...] > >> +# Count unique lines except clean invocations in two files and compare > >> +# them. Clean

Re: A head scratcher, clone results in modified files (tested linux and cygwin) - .gitattributes file?

On 09/10/16 08:48, Jason Pyeron wrote: The whole .gitattributes needs to be adopted, I think Git 2.10 or higher has "git ls-files --eol": git ls-files --eol | grep "i/crlf.*auto" i/crlf w/crlf attr/text=auto src/site/xdoc/upgradeto2_3.xml i/crlf w/crlf attr/text=auto

Re: [PATCH v10 14/14] contrib/long-running-filter: add long running filter example

On 08.10.16 13:25, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > Add a simple pass-thru filter as example implementation for the Git > filter protocol version 2. See Documentation/gitattributes.txt, section > "Filter Protocol" for more info. > Nothing

Re: [PATCH v10 13/14] convert: add filter..process option

On 09.10.16 01:06, Jakub Narębski wrote: >> + >> > +packet: git< status=abort >> > +packet: git< >> > + >> > + >> > +After the filter has processed a blob it is expected to wait for >> > +the next "key=value" list containing a

Re: [PATCH] run-command: fix build on cygwin (stdin is a macro)

>I am not suggesting that you apply this exact patch (stdin_ is not a good choice How about fd_stdin ?

Re: Impossible to change working directory

On 29.09.16 21:30, Sebastian Feldmann wrote: > Hi there, > > I have a problem executing a pre-commit hook. > The hook script has to change the working directory to work and if I use plain > > git commit > > it works as expected, the script executes without errors, but if I use > > git commit —only

Re: [PATCH v8 00/11] Git filter protocol

On 29/09/16 19:57, Lars Schneider wrote: On 29 Sep 2016, at 18:57, Junio C Hamano <gits...@pobox.com> wrote: Torsten Bögershausen <tbo...@web.de> writes: 1) Git exits 2) The filter process receives EOF and prints "STOP" to the log 3) t0021 checks the content of the log

Re: [PATCH v8 00/11] Git filter protocol

On 29/09/16 12:28, Lars Schneider wrote: On 28 Sep 2016, at 23:49, Junio C Hamano wrote: I suspect that you are preparing a reroll already, but the one that is sitting in 'pu' seems to be flaky in t/t0021 and I seem to see occasional failures from it. I didn't trace where

Re: [PATCH v7 10/10] convert: add filter..process option

On 15.09.16 22:04, Junio C Hamano wrote: > Lars Schneider writes: > >> Wouldn't that complicate the pathname parsing on the filter side? >> Can't we just define in our filter protocol documentation that our >> "pathname" packet _always_ has a trailing "\n"? That would

Re: Gitattributes file is not respected when switching between branches

On 16.09.16 08:51, Виталий Ищенко wrote: > Sorry for delay. > No problem about the delay. (And please no top-posting) If you say > ".gitattributes" indeed is not present in "master", but this is intentionally then nobody has (to my knowledge) thought about this situation/workflow yet. The

Re: [PATCH v7 10/10] convert: add filter..process option

On 12.09.16 11:49, Lars Schneider wrote: >> How do we send pathnames the have '\n' ? >> Not really recommended, but allowed. >> And here I am a little bit lost, is each of the lines packed into >> a pkt-line ? >> command=smudge is packet as pkt-line and pathname= is packed into >> another one ?

Re: Gitattributes file is not respected when switching between branches

On 12.09.16 21:35, Torsten Bögershausen wrote: > On 12.09.16 14:55, Виталий Ищенко wrote: >> Good day >> >> I faced following issue with gitattributes file (at least eol setting) >> when was trying to force `lf` mode on windows. >> >> We have 2 branches

Re: Gitattributes file is not respected when switching between branches

On 12.09.16 14:55, Виталий Ищенко wrote: > Good day > > I faced following issue with gitattributes file (at least eol setting) > when was trying to force `lf` mode on windows. > > We have 2 branches: master & dev. With master set as HEAD in repository > > I've added `.gitattributes` with following

Re: [PATCH v7 10/10] convert: add filter..process option

[] One general question up here, more comments inline. The current order for a clean-filter is like this, I removed the error handling: int convert_to_git() { ret |= apply_filter(path, src, len, -1, dst, filter); if (ret && dst) { src = dst->buf;

Re: [PATCH v7 10/10] convert: add filter..process option

On Thu, Sep 08, 2016 at 08:21:32PM +0200, larsxschnei...@gmail.com wrote: [] > +packet: git> git-filter-client > +packet: git> version=2 > +packet: git> version=42 > +packet: git> > +packet: git< git-filter-server > +packet: git< version=2

Re: [PATCH v4 1/3] tests: move test_lazy_prereq JGIT to test-lib.sh

On Fri, Sep 09, 2016 at 10:36:28AM -0700, Jonathan Tan wrote: [] > diff --git a/t/test-lib.sh b/t/test-lib.sh > index d731d66..c9c1037 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -1072,6 +1072,10 @@ test_lazy_prereq NOT_ROOT ' > test "$uid" != 0 > ' > > +test_lazy_prereq JGIT

Re: How to simulate a real checkout to test a new smudge filter?

On 06.09.16 19:47, john smith wrote: > I am looking for a way to force smudge filter to run by simulating a > real life checkout. Let's say I just created a new branch and did not > modify any files but want to test my new smudge filter. According to > some answers such as >

Re: [PATCH v6 12/13] convert: add filter..process option

On Tue, Aug 30, 2016 at 03:23:10PM -0700, Junio C Hamano wrote: > Lars Schneider writes: > > > On 30 Aug 2016, at 20:59, Junio C Hamano wrote: > >> > >>> "abort" could be ambiguous because it could be read as "abort only > >>> this file".

Re: [PATCH v6 13/13] read-cache: make sure file handles are not inherited by child processes

> > diff --git a/sha1_file.c b/sha1_file.c > index d5e1121..759991e 100644 > --- a/sha1_file.c > +++ b/sha1_file.c > @@ -1485,7 +1485,7 @@ int check_sha1_signature(const unsigned char *sha1, > void *map, > > int git_open_noatime(const char *name) Hm, should the function then be renamed into

Re: [PATCH v1 0/3] Update eol documentation

On 25/08/16 22:31, Junio C Hamano wrote: [] This [0/3] is meant to be a cover for [1/2] and [2/2]? I am trying to see if we broke format-patch recently, or it is a manual editing error. The latter I do not care about; the former I do. No worry, 0/3 is patched by me by hand, sorry for

Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3

I was not talking about the cost of correcting mistakes. Running --filters is potentially very costly. Just so you understand what I am talking about: I have a report that says that checking out a sizeable worktree with core.autocrlf=true is 58% slower than with core.autocrlf=false. That is

Re: git-svn bridge and line endings

On 23.08.16 19:50, Lucian Smith wrote: > On Tue, Aug 23, 2016 at 10:36 AM, Julian Phillips > wrote: >> On 23/08/2016 17:14, Lucian Smith wrote: >>> >>> Thanks for the quick responses! >>> >>> My situation is that the git side is entirely whatever github.org is >>>

Re: git-svn bridge and line endings

On Mon, Aug 22, 2016 at 05:04:47PM -0700, Lucian Smith wrote: > I'm attempting to use the git-svn bridge, and am having problems with > line endings on Windows. > > The setup is that we have a git repository on github, and I've checked > out a branch on my Windows machine using Tortoise svn. I

Re: [PATCH 2/4] cat-file: introduce the --filters option

On 19.08.16 17:00, Johannes Schindelin wrote: > Hi Torsten, > > On Fri, 19 Aug 2016, Torsten Bögershausen wrote: > >> On Thu, Aug 18, 2016 at 02:46:17PM +0200, Johannes Schindelin wrote: >> >>> +--filters:: >>> + Show the content as transformed by the fi

Re: [PATCH 2/4] cat-file: introduce the --filters option

[] On Thu, Aug 18, 2016 at 02:46:17PM +0200, Johannes Schindelin wrote: > diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt > index 071029b..7d48735 100644 > --- a/Documentation/git-cat-file.txt > +++ b/Documentation/git-cat-file.txt > @@ -9,15 +9,15 @@ git-cat-file -

Re: [PATCH 4/4] cat-file: support --textconv/--filters in batch mode

On Thu, Aug 18, 2016 at 02:46:28PM +0200, Johannes Schindelin wrote: > With this patch, --batch can be combined with --textconv or --filters. > For this to work, the input needs to have the form > > > > so that the filters can be chosen appropriately. > > Signed-off-by: Johannes

Re: [PATCH 2/4] cat-file: introduce the --filters option

On Thu, Aug 18, 2016 at 02:46:17PM +0200, Johannes Schindelin wrote: > As suggested by its name, the --filters option applies the filters [] > diff --git a/t/t8010-cat-file-filters.sh b/t/t8010-cat-file-filters.sh Does it make sense to integrate tests into t1006-cat-file ? > new file mode 100755

Re: [ANNOUNCE] Git v2.10.0-rc0

On 17.08.16 19:38, Junio C Hamano wrote: > Junio C Hamano <gits...@pobox.com> writes: > >> Torsten Bögershausen <tbo...@web.de> writes: >> >>> Is this `text=auto` correct ? >> >> Thanks for spotting a typo. Definitely. >> >>

Re: [ANNOUNCE] Git v2.10.0-rc0

On Mon, Aug 15, 2016 at 08:42:48AM -0700, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > > > On 15.08.16 00:47, Junio C Hamano wrote: > >> Torsten Bögershausen (1): > >> convert: unify the "auto" handling of CRLF > &

Re: [ANNOUNCE] Git v2.10.0-rc0

On 15.08.16 00:47, Junio C Hamano wrote: > Torsten Bögershausen (1): > convert: unify the "auto" handling of CRLF Should we mention this change in the release notes? The handling of "*.text = auto" was changed, and now $ echo "* text=auto eol=crlf&qu

Re: [PATCH v1 1/2] t0027: Correct raciness in NNO test

On Sat, Aug 13, 2016 at 06:50:19PM +0200, Johannes Sixt wrote: > Am 12.08.2016 um 18:51 schrieb tbo...@web.de: > >From: Torsten Bögershausen <tbo...@web.de> > > > >When a non-reversible CRLF conversion is done in "git add", > >a warning is printed on

Re: t0027 racy?

code paths) Good ideas, I will work on a series that fixes bugs first, and then we can see if there is room for optimization. What do you think about this as a starting point, more things will follow. I like to here comments about the commit msg first ;-) commit 3754404d3d1ea4a0cbbed4986cc4ac1b5fe6

Re: t0027 racy?

> git -c core.autocrlf=$crlf add $fname >"${pfx}_$f.err" 2>&1 > > would make more sense. We _know_ that we have to do convert_to_git() in > that step because the content is changed. And then you can ignore the > warnings from "git commit" (which are racy), or you can simply commit as > a whole

Re: t0027 racy?

On Tue, Aug 09, 2016 at 07:49:38AM -0400, Jeff King wrote: > On Tue, Aug 09, 2016 at 11:33:37AM +0000, Torsten Bögershausen wrote: > > > > The second one seems plausible, given the history of issues with > > > changing CRLF settings for an existing checkout. I'm no

Re: t0027 racy?

On Tue, Aug 09, 2016 at 02:51:10AM -0400, Jeff King wrote: > On Mon, Aug 08, 2016 at 08:32:24PM +0000, Torsten Bögershausen wrote: > > > > The verbose output is not very exciting, though: > > > > > > expecting success: > > >

Re: t0027 racy?

On Mon, Aug 08, 2016 at 11:29:26AM -0400, Jeff King wrote: > On Mon, Aug 08, 2016 at 05:05:07PM +0200, Johannes Schindelin wrote: > > > I remember that you did a ton of work on t0027. Now I see problems, and > > not only that the entire script now takes a whopping 4 minutes 20 seconds > > to run

Re: t0027 racy?

Any idea about any possible races? Just to double-check: I assume that you have this commit ded2444ad8ab8128cae2b91b8efa57ea2dd8c7a5 Author: Torsten Bögershausen <tbo...@web.de> Date: Mon Apr 25 18:56:27 2016 +0200 t0027: make commit_chk_wrnNNO() reliable in your tree ? Is there a special pattern ? Did you

Re: What's cooking in git.git (Aug 2016, #02; Thu, 4)

On 2016-08-05 01.32, Junio C Hamano wrote: > Mike Hommey writes: [] >> What kind of support are you expecting? > > The only rationale I recall you justifying this series was that this > makes the resulting code easier to read, but I do not recall other > people agreeing with

Re: [PATCH v4 11/12] convert: add filter..process option

On 2016-08-06 00.06, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> On 2016-08-03 18.42, larsxschnei...@gmail.com wrote: >>> The filter is expected to respond with the result content in zero >>> or more pkt-line packets an

Re: [PATCH v4 11/12] convert: add filter..process option

On 2016-08-03 18.42, larsxschnei...@gmail.com wrote: > The filter is expected to respond with the result content in zero > or more pkt-line packets and a flush packet at the end. Finally, a > "result=success" packet is expected if everything went well. > > packet:

Re: [PATCH v4 07/12] run-command: add clean_on_exit_handler

On 2016-08-05 15.08, Lars Schneider wrote: [] > Yeah it could do that. But then the filter cannot do things like > modifying the index after the fact... however, that might be considered > nasty by the Git community anyways... I am thinking about dropping > this patch in the next roll as it is

Re: Making file permissions match

On Wed, Aug 03, 2016 at 09:46:06AM -0400, jonsm...@gmail.com wrote: > I'm working with some Windows programmers that don't believe in file > permissions They keep sending me zip files of their source tree. I > have my copy of the tree in git on Linux with all of the correct file > permissions. >

Re: [PATCH v3 03/10] pkt-line: add packet_flush_gentle()

On Sun, Jul 31, 2016 at 11:45:08PM +0200, Lars Schneider wrote: > > > On 31 Jul 2016, at 22:36, Torstem Bögershausen wrote: > > > > > > > >> Am 29.07.2016 um 20:37 schrieb larsxschnei...@gmail.com: > >> > >> From: Lars Schneider > >> > >>

Re: [PATCH v2 5/5] convert: add filter..process option

On 07/27/2016 02:06 AM, larsxschnei...@gmail.com wrote: Some comments inline [] > The filter is expected to respond with the result content size as > ASCII number in bytes and the result content in packet format with > a flush packet at the end: > > packet: git<

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