Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On Thu, Dec 07, 2017 at 04:33:12PM -0500, Todd Zullinger wrote: > Jeff Hostetler wrote: > >I'm looking at t5616 now on my mac. > >Looks like the MAC doesn't like my line counting in the tests. > >I'll fix in my next version. > [] > | sort >expect_2.oids && > - test "$(wc -l

Re: [PATCH v1 1/2] t0027: Don't use git commit

On Fri, Dec 08, 2017 at 10:21:19AM -0800, Junio C Hamano wrote: > Junio C Hamano <gits...@pobox.com> writes: > > > tbo...@web.de writes: > > > >> From: Torsten Bögershausen <tbo...@web.de> > >> > >> Replace `git commit -m "comment&quo

Re: What's cooking in git.git (Dec 2017, #02; Thu, 7)

> * tb/check-crlf-for-safe-crlf (2017-11-27) 1 commit > (merged to 'next' on 2017-12-05 at 7adaa1fe01) > + convert: tighten the safe autocrlf handling > > The "safe crlf" check incorrectly triggered for contents that does > not use CRLF as line endings, which has been corrected. > > Broken

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

On 2017-12-06 16:14, Lars Schneider wrote: > >> On 04 Dec 2017, at 22:46, Junio C Hamano wrote: >> >> >> * tb/check-crlf-for-safe-crlf (2017-11-27) 1 commit >> - convert: tighten the safe autocrlf handling >> >> The "safe crlf" check incorrectly triggered for contents that

Re: [PATCH 1/1] convert: tighten the safe autocrlf handling

t; > 0 is returned directly, this is the most common case. > > If a '\r' is found, the content is analyzed more deeply. > > > > Signed-off-by: Torsten Bögershausen <tbo...@web.de> > > --- > > diff --git a/convert.c b/convert.c > > @@ -220,18 +220,27 @

Re: Changing encoding of a file : What should happen to CRLF in file ?

On Thu, Nov 23, 2017 at 10:01:40PM +0530, Ashish Negi wrote: > Thanks for confirming. > Is it possible to track this via a bug number ? > It will help me to try out the fix when its available. > No worry, the fix is nearly complete and will come out in a couple of days.

Re: RFC: Native clean/smudge filter for UTF-16 files

On Thu, Nov 23, 2017 at 04:18:59PM +0100, Lars Schneider wrote: > Hi, > > I am working with a team that owns a repository with lots of UTF-16 files. > Converting these files to UTF-8 is no good option as downstream applications > require the UTF-16 encoding. Keeping the files in UTF-16 is no good

Re: core.safecrlf warning is confusing[improvement suggestion?]

On Wed, Nov 22, 2017 at 11:01:22AM +0900, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > > >> I want to have LF line endings in the repository and CRLF endings in > >> the working copy. (Because I use windows-exclusive tools to develop.) >

Re: core.safecrlf warning is confusing[improvement suggestion?]

On Tue, Nov 21, 2017 at 01:18:30PM +0800, Vladimir Nikishkin wrote: > Hello, everyone. > > I have the following question. > > So I have a fresh git repository after git init, on Windows. > > core.autocrlf is true explicitly, and core.safecrlf is true implicitly. > > I want to have LF line

Re: Changing encoding of a file : What should happen to CRLF in file ?

On Thu, Nov 16, 2017 at 12:35:33AM +0530, Ashish Negi wrote: > On windows : > > git --version > git version 2.14.2.windows.2 > > On linux : > > git --version > git version 2.7.4 > > I would like to understand the solution : > If i understood it correctly : it removes file_name.txt from index, so

Re: Changing encoding of a file : What should happen to CRLF in file ?

On Wed, Nov 15, 2017 at 01:41:42PM +0530, Ashish Negi wrote: > > If you commit the file, it will be stored with LF in the index, > This is what i believe is not happening. > > Lets do this with a public repository and steps which are reproducible. > I have created a repo :

Re: Changing encoding of a file : What should happen to CRLF in file ?

(Back to the beginning) You have a file ApplicationManifest.xml It is encoded in UTF-16 (and has CRLF) You convert it into UTF-8 The file has still CRLF (in the worktree) Now you add it and make a commit. Under both Linux and Windows you have "text=auto". I assume that you have efficiently

Re: Changing encoding of a file : What should happen to CRLF in file ?

On 2017-11-14 17:13, Ashish Negi wrote: > Running the command gives me : > > git ls-files --eol file_name > i/-text w/-text attr/text=auto file_name > That is strange to me: According to that, Git would treat the file as text=auto. And the content is "not next", so there is

Re: Changing encoding of a file : What should happen to CRLF in file ?

On 2017-11-14 13:31, Ashish Negi wrote: > Hello > > I have a cross platform project. I have a utf-16 file in it. > I changed its encoding to urf-8 and committed. When i pulled the file > in Linux, it shows that file is modified. This means that the commit > which changed the encoding does not

Re: [PATCH v2] gpg-interface: strip CR chars for Windows gpg2

On Sun, Nov 12, 2017 at 01:07:10PM +, Jerzy Kozera wrote: > This fixes the issue with newlines being \r\n and not being displayed > correctly when using gpg2 for Windows, as reported at > https://github.com/git-for-windows/git/issues/1249 > > Issues with non-ASCII characters remain for

Re: [PATCH v2 1/1] Introduce git add --renormalize .

On Fri, Nov 10, 2017 at 09:22:10AM +0900, Junio C Hamano wrote: > > Taking these altogether, perhaps > > Apply the "clean" process freshly to all tracked files to > forcibly add them again to the index. This is useful after > changing `core.autocrlf` configuration or the `text`

Re: [PATCH v2 1/1] Introduce git add --renormalize .

[] > > If we had such a term in Documentation/glossary-contents.txt, we > could even say > > Add contents of all paths to the index by freshly applying > the "clean" process, even to the ones Git may think are > unmodified in the working tree since they were added the >

Re: [PATCH v2 1/1] Introduce git add --renormalize .

[snip] > > > @@ -175,6 +175,12 @@ for "git add --no-all ...", i.e. ignored > > removed files. > > warning (e.g., if you are manually performing operations on > > submodules). > > > > +--renormalize:: > > + Normalizes the line endings from CRLF to LF of tracked files. > > + This

Re: [Bug Report] [includeIf] does not parse case insensitive -> case sensitive symlink gitdir

On Fri, Oct 27, 2017 at 09:55:58AM -0400, Adrian Kappel wrote: > Hello all, not sure if the issue I've come across is a known bug or > addressable, but wanted to report it just in-case. Thanks for the detailed description - my question is inline > > > ** Summary >

Re: Consequences of CRLF in index?

On Thu, Oct 26, 2017 at 01:01:25PM +0200, Lars Schneider wrote: > > > On 26 Oct 2017, at 09:09, Johannes Sixt wrote: > > > > Am 25.10.2017 um 14:19 schrieb Johannes Schindelin: > >> I envy you for the blessing of such a clean C++ source that you do not > >> have any, say, Unix

Re: Consequences of CRLF in index?

On Wed, Oct 25, 2017 at 10:13:57AM -0700, Jonathan Nieder wrote: > Hi again, > > Lars Schneider wrote: > >> On 24 Oct 2017, at 20:14, Jonathan Nieder wrote: > > >> In any event, you also probably want to declare what you're doing > >> using .gitattributes. By checking in

Re: Consequences of CRLF in index?

On Tue, Oct 24, 2017 at 11:14:15AM -0700, Jonathan Nieder wrote: > Hi, > > Lars Schneider wrote: > > > I've migrated a large repo (110k+ files) with a lot of history (177k > > commits) > > and a lot of users (200+) to Git. Unfortunately, all text files in the index > > of the repo have CRLF

Re: Line ending normalization doesn't work as expected

On Fri, Oct 06, 2017 at 09:33:31AM +0900, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > > > Before we put this into stone: > > Does it make sense to say "renormalize" instead of "rehash" ? > > (That term does exist alre

Re: Line ending normalization doesn't work as expected

> builtin/add.c | 42 +- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/builtin/add.c b/builtin/add.c > index 5d5773d5cd..264f84dbe7 100644 > --- a/builtin/add.c > +++ b/builtin/add.c > @@ -26,6 +26,7 @@ static const char * const

Re: Line ending normalization doesn't work as expected

On Wed, Oct 04, 2017 at 11:26:55AM -0500, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano <gits...@pobox.com> wrote: > > Torsten Bögershausen <tbo...@web.de> writes: > > > >>> $ git rm -r --cached . && git add . > >&

Re: Line ending normalization doesn't work as expected

On 2017-10-03 19:23, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 11:26 AM, Torsten Bögershausen <tbo...@web.de> wrote: >> The short version is, that the instructions on Github are outdated. >> This is the official procedure (since 2016, Git v2.12 or so) >> But it

Re: Line ending normalization doesn't work as expected

On 2017-10-03 17:00, Robert Dailey wrote: > I'm on Windows using Git for Windows v2.13.1. Following github's > recommended process for fixing line endings after adding a > `.gitattributes` file[1], I run the following: > > $ rm .git/index && git reset > > Once I run `git status`, I see that no

Re: is there a "symlink" option for cloning a repo in a separate filesystem?

On 2017-09-23 10:22, Robert P. J. Day wrote: > > reading "man git-clone", and i understand the mechanics of the local > protocol, so that if i run: > > $ git clone /path/to/repo > > then "files under .git/objects/ directory are hardlinked to save space > when possible." > > but if the

Re: [PATCH 1/4] git-compat-util.h: xsize_t() - avoid -Wsign-compare warnings

On 2017-09-21 18:46, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > git-compat-util.h | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/git-compat-util.h b/git-compat-util.h > index 9bc15b036..cedad4d58 100644 > ---

Re: [PATCH v1 1/1] test-lint: echo -e (or -E) is not portable

On Tue, Sep 19, 2017 at 01:37:14PM -0700, Jonathan Nieder wrote: > Torsten Bögershausen <tbo...@web.de> wrote: > > > Some implementations of `echo` support the '-e' option to enable > > backslash interpretation of the following string. > > As an addition, th

Re: [PATCH v6 08/12] fsmonitor: add a test tool to dump the index extension

> > Should I just make the variable type itself uintmax_t and then just skip > the cast altogether? I went with uint64_t because that is what > getnanotime returned. > That is a bit of taste question (or answer) Typically you declare the variables in the type you need, and this is uint64_t.

Re: [PATCH v6 08/12] fsmonitor: add a test tool to dump the index extension

On 2017-09-18 15:38, Ben Peart wrote: > > > On 9/17/2017 4:02 AM, Junio C Hamano wrote: >> Ben Peart writes: >> >>> diff --git a/t/helper/test-dump-fsmonitor.c b/t/helper/test-dump-fsmonitor.c >>> new file mode 100644 >>> index 00..482d749bb9 >>> --- /dev/null

Re: [PATCH v6 10/12] fsmonitor: add test cases for fsmonitor extension

On 2017-09-15 21:20, Ben Peart wrote: > +if [ "$1" != 1 ] > +then > + echo -e "Unsupported core.fsmonitor hook version.\n" >&2 > + exit 1 > +fi The echo -e not portable (It was detected by a tighter version of the lint script, which I have here, but not yet send to the list :-( This

Re: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.

On Fri, Sep 08, 2017 at 12:00:50PM -0600, Kevin Willford wrote: > When using the sparse checkout feature the git reset command will add > entries to the index that will have the skip-worktree bit off but will > leave the working directory empty. File data is lost because the index > version of

Re: Empty directories in Git: Current guidance for historical commits?

On 2017-09-05 14:47, wafflec...@openmail.cc wrote: > > Hello, > > Per the FAQ it's clear that Git (by current design) does not track empty > directories:  > https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F > > That's fine and I can fix that for my code going forward

Re: [PATCH v3] Documentation: mention that `eol` can change the dirty status of paths

On 2017-08-31 15:19, Ben Boeckel wrote: > This attribute sets a specific line-ending style to be used in the > working directory. It enables end-of-line conversion without any > -content checks, effectively setting the `text` attribute. > +content checks, effectively setting the `text`

Re: [PATCH] Documentation: mention that `eol` can change the dirty status of paths

On Wed, Aug 23, 2017 at 05:17:41PM -0400, Ben Boeckel wrote: > When setting the `eol` attribute, paths can change their dirty status > without any change in the working directory. This can cause confusion > and should at least be mentioned with a remedy. > > Signed-off-by: Ben Boeckel

Re: Cannot checkout after setting the eol attribute

On Tue, Aug 22, 2017 at 03:44:41PM -0400, Ben Boeckel wrote: > On Tue, Aug 22, 2017 at 21:13:18 +0200, Torsten Bögershausen wrote: > > When you set the text attribute (in your case "eol=crlf" implies text) > > then the file(s) -must- be nomalized and commited so that the

Re: Cannot checkout after setting the eol attribute

On Tue, Aug 22, 2017 at 01:49:18PM -0400, Ben Boeckel wrote: > Hi, > > I specified the `eol` attribute on some files recently and the behavior > of Git is very strange. > > Here is the set of commands to set up the repository used for the > discussion: > > git init > echo $'dos\r' > dos

Re: t5551 hangs ?

On Tue, Aug 22, 2017 at 01:26:25AM -0400, Santiago Torres wrote: > Hello, Torsten. > > On Tue, Aug 22, 2017 at 07:10:59AM +0200, Torsten Bögershausen wrote: > > Hej, > > I found 2 threads about hanging t5551, one in 2016, and one question > > from Junio s

t5551 hangs ?

Hej, I found 2 threads about hanging t5551, one in 2016, and one question from Junio somewhen in 2017. I have it reproducable here: - Debian 8, 64 bit - SSD - Half-modern processor ;-) The last thing I can see is: ok 29 - test allowanysha1inwant with unreachable --- A simplified ps -ef

Re: What's cooking in git.git (Aug 2017, #04; Fri, 18)

> * tb/apply-with-crlf (2017-08-17) 3 commits > - SQUASH??? > - apply: file commited with CRLF should roundtrip diff and apply > - convert: add SAFE_CRLF_KEEP_CRLF > (this branch is tangled with jc/apply-with-crlf.) > > "git apply" that is used as a better "patch -p1" failed to apply a >

Re: [Patch size_t V3 00/19] use size_t

On Wed, Aug 16, 2017 at 10:16:12PM +0200, Martin Koegler wrote: > From: Martin Koegler > > This patchset is for next [24db08a6e8fed761d3bace7f2d5997806e20b9f7]. I applied it succesfully, and run the test suite on a 32 bit system. The Laptop reported one brekage in

Re: [Patch size_t V3 01/19] delta: fix enconding size larger than an "uint" can hold

On Wed, Aug 16, 2017 at 10:16:13PM +0200, Martin Koegler wrote: > From: Martin Koegler > > The current delta code produces incorrect pack objects for files > 4GB. This may need a little bit more info (E.g. it does not fix anything on a 32 bit Linux) How about this:

Re: [PATCH 1/9] Convert pack-objects to size_t

On Wed, Aug 16, 2017 at 10:22:39PM +0200, Martin Koegler wrote: > On Mon, Aug 14, 2017 at 10:08:05AM -0700, Junio C Hamano wrote: > >It may help reducing the maintenance if we introduced obj_size_t > >that is defined to be size_t for now, so that we can later swap > >it to ofs_t or

Re: [PATCH/FIXUP 6/2] apply: clarify read_old_data() is about no-index case

On Thu, Aug 17, 2017 at 12:12:36AM -0700, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > > > Unless we re-define the meaning of "NULL" into "don't do CRLF conversions, > > like SAFE_CRLF_KEEP_CRLF does. > > My preference is not

Re: [PATCH/FIXUP 6/2] apply: clarify read_old_data() is about no-index case

On Wed, Aug 16, 2017 at 11:34:45AM -0700, Junio C Hamano wrote: > With the previous fixes to CRLF handling in place, read_old_data() > knows what it wants convert_to_git() to do with respect to CRLF. In > fact, this codepath is about applying a patch to a file in the > filesystem, which may not

Re: Bug with ignorecase on Git and Cygwin

On Wed, Aug 16, 2017 at 11:50:47AM +, CHEVALLIER Yves wrote: > Hi, > > On Cygwin, the config value `ignorecase` is set to `true` during `git init` > and it is not possible to change the default value using templates. > > The issue was discovered while I was tracking a bunch of source

Re: [PATCH 1/5] convert: initialize attr_action in convert_attrs

> > diff --git a/convert.c b/convert.c > > index 1012462e3..943d957b4 100644 > > --- a/convert.c > > +++ b/convert.c > > @@ -1040,7 +1040,6 @@ static void convert_attrs(struct conv_attrs *ca, > > const char *path) > > ca->crlf_action = git_path_check_crlf(ccheck + 4); > >

Re: [PATCH 1/5] convert: initialize attr_action in convert_attrs

On Tue, Aug 15, 2017 at 02:53:01PM +0200, Martin Ågren wrote: > convert_attrs populates a struct conv_attrs. The field attr_action is > not set in all code paths, but still one caller unconditionally reads > it. Since git_check_attr always returns the same value, we'll always end > up in the same

Re: [PATCH 1/9] Convert pack-objects to size_t

On Mon, Aug 14, 2017 at 08:31:50PM +0100, Ramsay Jones wrote: > > > On 14/08/17 18:08, Junio C Hamano wrote: > > Junio C Hamano writes: > > > >> One interesting question is which of these two types we should use > >> for the size of objects Git uses. > >> > >> Most of the

Re: [BUG] git am sometimes unable to apply git format-patch output file

On Sat, Aug 12, 2017 at 06:20:23PM +0200, Torsten Bögershausen wrote: > On Sat, Aug 12, 2017 at 07:02:59PM +0300, Soul Trace wrote: > > Hello. > > > > Using git i have found that git am command may sometimes fail to apply patch > > file which was created by the git am c

Re: [BUG] git am sometimes unable to apply git format-patch output file

On Sat, Aug 12, 2017 at 07:02:59PM +0300, Soul Trace wrote: > Hello. > > Using git i have found that git am command may sometimes fail to apply patch > file which was created by the git am command. > > > Steps to reproduce: Excellent, thanks so much for the detailed bug report. This kind of

Re: [PATCH 1/9] Convert pack-objects to size_t

Thanks for working on this - unfortunatly the patch does not apply on git.git/master. Which baseline did you use ?

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

>I left it unsaid by mistake, but I think the right thing to use as >the "previous" to take hint from in the context of "git apply" is >what is in the working tree, i.e. the result of applying patch in >step (4) to create a file F in the sample scenario. >While applying patch in step (5),

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

Test from mutt

Re: [PATCH v1 1/1] correct apply for files commited with CRLF

On 08/02/2017 11:13 PM, Junio C Hamano wrote: tbo...@web.de writes: From: Torsten Bögershausen <tbo...@web.de> git apply does not find the source lines when files have CRLF in the index and core.autocrlf is true: These files should not get the CRLF converted to LF. Because cmd_apply(

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

On 08/01/2017 10:58 PM, Anthony Sottile wrote: Here's where I'm hitting the problem described: https://github.com/pre-commit/pre-commit/issues/570 Note that `git -c core.autocrlf=false` apply patch fixes this situation, but breaks others. [] I wasn't thinking of that - and thanks for the

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

On 08/01/2017 08:24 PM, Anthony Sottile wrote: Here's my minimal reproduction -- it's slightly far-fetched in that it involves*committing crlf* and then using `autocrlf=true` (commit lf, check out crlf). ``` #!/bin/bash set -ex rm -rf foo git init foo cd foo # Commit crlf into repository

Re: Git on macOS shows committed files as untracked

ok strange The "box" with 04142F: Code point 4142F is unassigned and is outside any currently defined block range. So this is not valid Unicode, so we have a problem here under MacOS - not much Git can do about it. On Fri, Jul 14, 2017 at 4:41 AM, Torsten Bögershausen <tbo...@web.de

Re: Git on macOS shows committed files as untracked

On 14/07/17 06:49, Lutz Roeder wrote: Using precomposeunicode still reproduces the issue: Repro steps: 1. Download https://www.dropbox.com/s/0q5pbpqpckwzj7b/gitstatusrepro.zip?dl=0 2. unzip gitstatusrepro.zip && cd gitstatusrepro 3. git reset --hard 4. git -c core.precomposeunicode=true

Re: Git on macOS shows committed files as untracked

On 13/07/17 01:15, Jeff King wrote: On Wed, Jul 12, 2017 at 06:21:28PM -0400, roeder@mailnull.com wrote: In Git on macOS (git version 2.13.2 | brew install git) the status command will show folders as untracked even though they are committed and checked out from the repository. Does not

Re: Weirdness with git change detection

On 11/07/17 09:34, Jeff King wrote: On Tue, Jul 11, 2017 at 12:31:25AM -0700, Peter Eckersley wrote: I did try to test that hypothesis by editing the filter to be a no-op, but it's possible I go that wrong. My apologies for bugging the list! Actually I like this kind of feedback, to see

Re: Weirdness with git change detection

On 11/07/17 01:45, Peter Eckersley wrote: I have a local git repo that's in some weird state where changes appear to be detected by "git diff" and prevent operations like "git checkout" from switching branches, but those changes are not removed by a "git reset --hard" or "git stash". Here's

Re: Help needed for solving a few issues with building git

On 2017-07-03 15:18, Kaartic Sivaraam wrote: > Hello all, > > Building without localization support > > I tried to build git from source without localization support by adding > the following line to the Makefile, > > NO_GETTEXT=1 > May be make

Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)

On 01/07/17 09:39, Ævar Arnfjörð Bjarmason wrote: On Fri, Jun 30 2017, Junio C. Hamano jotted: * xz/send-email-batch-size (2017-05-23) 1 commit - send-email: --batch-size to work around some SMTP server limit "git send-email" learned to overcome some SMTP server limitation that does

Re: [PATCH] status: suppress additional warning output in plumbing modes

>On 30/06/17 18:28, Stefan Beller wrote: The patch makes a lot of sense - thanks for the fast reply. A question: does the header correspond to the patch ? < [PATCH] status: suppress additional warning output in plumbing modes > [PATCH] status: suppress CRLF warnings in porcelain modes (And

Re: Bug with automated processing of git status results

On 30/06/17 11:09, Matthieu Moy wrote: Сергей Шестаков writes: I understand that we can turn off core.safecrlf, but it's inconvinient. Note that you can do that without actually changing the config file: git -c core.safecrlf=false status ... Beside that, I

Re: EOL LF Windows auto.crlf issue

On 24/06/17 18:56, Filip Kucharczyk wrote: I'm on Windows 10. auto.crlf in .gitconfig is set to [core] autocrlf = true I've got a git (git version 2.13.1.windows.2) repo. A linux guy emails me a text with with line endings LF. I paste this file into my repo. Now every time I introduce changes

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

On 23/06/17 20:04, Junio C Hamano wrote: Junio C Hamano writes: Sorry for my mess, see below I am not sure if we even want the dot there, but at least that is what the original author of the test intended to do when s/he decided to pass an empty string as the pathspec.

Re: [PATCH v5 4/5] convert: move multiple file filter error handling to separate function

On 2017-06-18 13:47, Lars Schneider wrote: > >> On 18 Jun 2017, at 09:20, Torsten Bögershausen <tbo...@web.de> wrote: >> >> >> On 2017-06-01 10:22, Lars Schneider wrote: >>> This is useful for the subsequent patch 'convert: add "status=dela

Re: [PATCH v5 4/5] convert: move multiple file filter error handling to separate function

On 2017-06-01 10:22, Lars Schneider wrote: > This is useful for the subsequent patch 'convert: add "status=delayed" to > filter process protocol'. May be Collecting all filter error handling is useful for the subsequent patch 'convert: add "status=delayed" to filter process protocol'. > >

Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

On 14.06.17 09:42, Lars Schneider wrote: > >> * ls/filter-process-delayed (2017-06-01) 5 commits >> - convert: add "status=delayed" to filter process protocol >> - convert: move multiple file filter error handling to separate function >> - t0021: write "OUT" only on success >> - t0021: make

Re: [PATCH v3] doc: do not use `rm .git/index` when normalizing line endings

On 14/06/17 00:15, Andreas Heiduk wrote: Looks good to me, one minor typo below When illustrating how to normalize the line endings, the documentation in gitattributes tells the user to `rm .git/index`. This is incorrect for two reasons: - Users shouldn't be instructed to mess around with

Re: [PATCH v2] doc: fix location of index in worktree scenatio

On 06/12/2017 06:06 PM, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: Thanks for working on this (and keeping me in cc) The commit head line does not fully match my expactions: "doc: fix location of index in worktree scenatio" "doc:" is OK, but

Re: [PATCH v2] doc: fix location of index in worktree scenatio

Thanks for working on this (and keeping me in cc) The commit head line does not fully match my expactions: "doc: fix location of index in worktree scenatio" "doc:" is OK, but is the "location of index" fixed ? Actually something that includes the important stuff: "doc" "fix" "normalize the line

Re: Git Daemon on Windows fatal error.

On 31/05/17 21:10, Hector Santos wrote: Hi, I am relatively new to GIT (coming from CVS and SVN) and I am trying to setup "Git Daemon" on windows. I got it working for Local network communications: d:\local\wc5\testgit>git clone git://localhost/http clone10 Cloning into 'clone10'... remote:

Re: Bug report: Corrupt pack file after committing a large file (>4 GB?)

On 2017-05-26 07:51, Yu-Hsuan Chen wrote: > Dear maintainer, > > There is a bug where committing a large file corrupts the pack file in > Windows. Steps to recreate are: > > 1. git init > 2. stage and commit a file larger than 4 GB (not entirely sure about this > size) > 3. git checkout -f > >

Re: [PATCH v6 6/6] clean: teach clean -d to preserve ignored paths

diff --git a/builtin/clean.c b/builtin/clean.c index d861f836a..937eb17b6 100644 --- a/builtin/clean.c +++ b/builtin/clean.c @@ -857,6 +857,38 @@ static void interactive_main_loop(void) } } +static void correct_untracked_entries(struct dir_struct *dir) +{ + int src, dst,

Re: [PATCH v4 4/4] convert: add "status=delayed" to filter process protocol

On 2017-05-22 15:50, Lars Schneider wrote: > + > +int async_query_available_blobs(const char *cmd, struct string_list > *delayed_paths) > +{ > + int err; > + char *line; > + struct cmd2process *entry; > + struct child_process *process; > + struct strbuf filter_status =

Re: [PATCH v4 4/4] convert: add "status=delayed" to filter process protocol

On 2017-05-22 15:50, Lars Schneider wrote: > +After Git received the pathnames, it will request the corresponding > +blobs again. These requests contain a pathname and an empty content > +section. The filter is expected to respond with the smudged content > +in the usual way as explained above. >

Re: [PATCH v2 4/6] fsmonitor: add test cases for fsmonitor extension

> diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh > new file mode 100755 > index 00..d3cffc758f > --- /dev/null > +++ b/t/t7519-status-fsmonitor.sh > @@ -0,0 +1,153 @@ > +#!/bin/sh > + > +test_description='git status with file system watcher' > + > +. ./test-lib.sh >

Re: [PATCH v2 1/1] t0027: tests are not expensive; remove t0025

be retiered: s/retiered/retired/ The execution time for t0027 is 14 seconds under Linux, and 63 seconds under Mac Os X. And in case you ask, things are not going significantly faster using a SSD instead of a spinning disk. Signed-off-by: Torsten Bögershausen <tbo...@web.de> Thank you for t

Re: [PATCH v2 1/9] t7300: skip untracked dirs containing ignored files

On 2017-05-05 12:46, Samuel Lijin wrote: > If git sees a directory which contains only untracked and ignored > files, clean -d should not remove that directory. It was recently > discovered that this is *not* true of git clean -d, and it's possible > that this has never worked correctly; this test

Re: not uptodate. Cannot merge

On 2017-05-04 23:40, G. Sylvie Davies wrote: > Hi, > > My little bitbucket "cherry-pick" button is failing on Windows from a > "git reset --hard" blowing up. > > My situation: Git-2.10.2.windows.1 / Bitbucket-4.14.3 / Windows > 10-10.0-amd64. But I suspect even more recent Git will have the

Re: [PATCH/RFC 1/1] t0027: Some tests are not expensive

On 01/05/17 05:07, Junio C Hamano wrote: tbo...@web.de writes: From: Torsten Bögershausen <tbo...@web.de> ... The execution time for the non-expansive part is 6..8 seconds under Linux, and 32 seconds under Mac Os X. Running the "expensive" version roughly doubles the time.

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

On 2017-04-30 09:53, René Scharfe wrote: > Am 30.04.2017 um 07:31 schrieb Torsten Bögershausen: >> Sorry, I was not looking careful enough, the macro `$GIT_UNZIP` >> gave the impression that an unzip provided by Git (or the Git test >> framework) was used :-( >> >>

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

On 30/04/17 00:28, René Scharfe wrote: Am 29.04.2017 um 23:00 schrieb Torsten Bögershausen: This fails here under Mac OS: commit 4cdf3f9d84568da72f1dcade812de7a42ecb6d15 Author: René Scharfe <l@web.de> Date: Mon Apr 24 19:33:34 2017 +0200 archive-zip: support files bigger th

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

On 2017-04-24 19:22, René Scharfe wrote: > The first patch adds (expensive) tests, the next two are cleanups which > set the stage for the remaining two to actually implement zip64 support > for offsets and file sizes. > > Half of the series had been laying around for months, half-finished and >

Re: Bug: Git rename does not work if folder naming was changed from lower to upper case on OSX

after having committed folders with lower case naming, I decided to rename them to upper-case names. Expecting git to detect them as renamings, it started a new parallel hierarchy with new files, which I had to add/commit. It was a kinda strange behavior, which I fixed by rename the folder to

Re: t0025 flaky on OSX

So all in all it seams as if there is a very old race condition here, which we "never" have seen yet. Moving the file to a different inode number fixes the test case, Git doesn't treat it as unchanged any more. Thanks a lot for investigating this! Would you mind posting the fix as patch?

Re: t0025 flaky on OSX

On 2017-04-24 19:00, Torsten Bögershausen wrote: > On 2017-04-24 18:45, Lars Schneider wrote: >> Hi, >> >> "t0025.3 - crlf=true causes a CRLF file to be normalized" failed >> sporadically on next and master recently: >> https://travis-ci.org/git/git/jo

Re: t0025 flaky on OSX

On 2017-04-24 18:45, Lars Schneider wrote: > Hi, > > "t0025.3 - crlf=true causes a CRLF file to be normalized" failed > sporadically on next and master recently: > https://travis-ci.org/git/git/jobs/225084459#L2382 > https://travis-ci.org/git/git/jobs/223830505#L2342 > > Are you aware of a

Re: [PATCH] test-lib: abort when can't remove trash directory

[] - cd "$(dirname "$remove_trash")" && - rm -rf "$(basename "$remove_trash")" || - error "Tests passed but test cleanup failed; aborting" + cd "$(dirname "$TRASH_DIRECTORY")" && + rm -fr "$TRASH_DIRECTORY" ||

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

I think I meant to write "big pidfiles" there. With xsize_t() gc would die when seeing a pidfile whose size doesn't fit into size_t. The version I sent just ignores such files. However, it would choke on slightly smaller files that happen to not fit into memory. And no reasonable pidfile

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

On 2017-04-19 22:02, René Scharfe wrote: > Am 19.04.2017 um 21:09 schrieb Torsten Bögershausen: >> On 2017-04-19 19:28, René Scharfe wrote: >> [] >> One or two minor comments inline >>> diff --git a/builtin/gc.c b/builtin/gc.c >>> index 2daede7820..4

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

On 2017-04-19 19:28, René Scharfe wrote: [] One or two minor comments inline > diff --git a/builtin/gc.c b/builtin/gc.c > index 2daede7820..4c1c01e87d 100644 > --- a/builtin/gc.c > +++ b/builtin/gc.c > @@ -228,21 +228,99 @@ static int need_to_gc(void) > return 1; > } > > +struct pidfile {

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

>> (Back to the roots) >> Which criteria do you have in mind: When should a filter process the blob >> and return it immediately, and when would it respond "delayed" ? > > See above: it's up to the filter. In case of Git LFS: delay if a network call > is required. > That make sense. I try to

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

On 2017-04-11 21:50, Lars Schneider wrote: [] >> packet: git> command=smudge >> packet: git> pathname=path/testfile.dat >> packet: git> delay-id=1 >> packet: git> >> packet: git> CONTENT >> packet: git> >> packet: git<

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

On 2017-04-09 21:11, Lars Schneider wrote: [] > + > +packet: git> command=smudge > +packet: git> pathname=path/testfile.dat > +packet: git> delay-able=1 > +packet: git> > +packet: git> CONTENT > +packet: git> >

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