Re: t6044 broken on pu

On 08.05.16 04:21, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> That's true, but the test passes anyway. > You can also remove the body of the test and replace it with "true" > and say "the test passes anyway". Changing

t6044 broken on pu

The "seq" is not understood by all shells, using printf fixes this, index 20a3ffe..48d964e 100755 --- a/t/t6044-merge-unrelated-index-changes.sh +++ b/t/t6044-merge-unrelated-index-changes.sh @@ -20,7 +20,7 @@ test_description="merges with unrelated index changes" # Commit E: renames

t6392 broken on pu (Mac OS X)

These tests fail here under Mac OS, they pass under Linux: commit ff3d9b660a4b6e9d3eeb664ce1febe717adff737 I haven't had a chance to dig further. expecting success: git for-each-ref --format="%(if)%(authorname)%(then)%(authorname): %(refname)%(end)" >actual && cat >expect <<-\EOF

Re: t6044 broken on pu

On 2016-05-07 14.19, Andreas Schwab wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> The "seq" is not understood by all shells, >> using printf fixes this, >> >> index 20a3ffe..48d964e 100755 >> --- a/t/t6044-merge-unrelated-ind

Re: t6044 broken on pu

On 08.05.16 20:20, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> May a simple >> printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" >> >> be an option ? > If you were to do that, at least have the decency to make it more >

Re: [PATCH v10 12/12] bisect--helper: `get_terms` & `bisect_terms` shell function in C

On 07/25/2016 06:53 PM, Junio C Hamano wrote: Pranit Bauva writes: >>> +enum terms_defined { >>> + TERM_BAD = 1, >>> + TERM_GOOD = 2, >>> + TERM_NEW = 4, >>> + TERM_OLD = 8 >>> +}; >>> + >> >> What does TERM stand for ? The terms (words)

Re: [PATCH v2 4/5] convert: generate large test files only once

On 07/27/2016 02:06 AM, larsxschnei...@gmail.com wrote: From: Lars Schneider Generate a more interesting large test file with random characters in between and reuse this test file in multiple tests. Run tests formerly marked as EXPENSIVE every time but with a

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<

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

On 07/22/2016 05:49 PM, larsxschnei...@gmail.com wrote: From: Lars Schneider Git's clean/smudge mechanism invokes an external filter process for every single blob that is affected by a filter. If Git filters a lot of blobs then the startup time of the external

Re: [PATCH v10 12/12] bisect--helper: `get_terms` & `bisect_terms` shell function in C

On 07/20/2016 11:47 PM, Pranit Bauva wrote: Reimplement the `get_terms` and `bisect_terms` shell function in C and add `bisect-terms` subcommand to `git bisect--helper` to call it from git-bisect.sh . In the shell version, the terms were identified by strings but in C version its done by bit

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: 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 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: What's cooking in git.git (Jun 2016, #05; Thu, 16)

On 07/13/2016 12:20 AM, Joey Hess wrote: Torsten Bögershausen wrote re jh/clean-smudge-annex: The thing is that we need to check the file system to find .gitatttibutes, even if we just did it 1 nanosecond ago. So the .gitattributes is done 3 times: -1 would_convert_to_git_filter_fd( -2

Re: Looking for help to understand external filter driver code

On 07/20/2016 12:01 AM, Lars Schneider wrote: On 19 Jul 2016, at 23:33, Junio C Hamano wrote: Lars Schneider writes: Git writes --> 4 byte filename length Git writes --> filename string Why limit to 32GB? Perhaps NUL termination is more

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

On 07/15/2016 12:38 AM, Jeff King wrote: 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

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

yet, so right now both topics are stalled and waiting for an action from you. Yes, the code looks good to me. And the commit message does explain what is going on. For my taste, these 3 lines don't explain too much,may be remove them ? > The test update was taken from a series by Torsten Bög

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

On 07/14/2016 06:48 PM, Johannes Sixt wrote: 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

Re: [PATCH v4 0/6] worktree lock/unlock

>On 03.06.16 14:19, Nguyễn Thái Ngọc Duy wrote: Minor problem: t2028 fails, when the test is run from a directory that is a softlink. (In my case /Users/tb/projects/git/git.pu is a softlink to /Users/tb/NoBackup/projects/git/git.pu/ [master (root-commit) 2519212] init Author: A U Thor

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 2016-07-06 16.57, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> At some point inside the merge, Git calls read-cache.c/ce_compare_data(), >> to check if the path named "file" is clean. >> According to the tree informat

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 07/07/16 20:43, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> This is the call stack: >> >> merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1, >>const char *path,

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 07/08/2016 06:36 PM, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: I dunno. I really do not like that extra sha1 argument added all over the callchain by this patch. Or did you mean other calls to add_cacheinfo()? I didn't mean too much - the whole call

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 07/07/16 20:43, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: This is the callstack: merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh, int options) { struct cache_ent

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: 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: 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: [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: [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: 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 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: 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 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: 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: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 29.06.16 18:14, Junio C Hamano wrote: > tbo...@web.de writes: > >> From: Torsten Bögershausen <tbo...@web.de> >> >> The following didn't work as expected: > > Sorry for being slow (not in response but in understanding), but > let's examine the expe

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 2016-07-02 00.11, Junio C Hamano wrote: [snip] diff --git a/read-cache.c b/read-cache.c index a3ef967..c109b6d 100644 --- a/read-cache.c +++ b/read-cache.c @@ -163,7 +163,9 @@ static int ce_compare_data(const struct cache_entry *ce, struct stat *st) if (fd >= 0) {

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: [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: [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: [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: 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: 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: 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: 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 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 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 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: [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: 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 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: [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 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] 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: [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 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: 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: 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: [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: 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: [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 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: [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: 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 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 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: [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 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: 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: 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: [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: [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 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: 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 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: 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] 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: [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: 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: [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)

> > * 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 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: 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: [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: [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: [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 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 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

>> 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 v2 1/1] convert: git cherry-pick -Xrenormalize did not work

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

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: 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 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: 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: [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: 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: 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

<    5   6   7   8   9   10   11   12   13   >