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: 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: [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: [PATCH v1] convert: add support for 'encoding' attribute

On Mon, Dec 11, 2017 at 04:50:23PM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > Git and its tools (e.g. git diff) expect all text files in UTF-8 > encoding. Git will happily accept content in all other encodings, too, > but it might not be able

Re: [PATCH v1] convert: add support for 'encoding' attribute

On Mon, Dec 11, 2017 at 09:47:24PM +0100, Johannes Sixt wrote: > Am 11.12.2017 um 16:50 schrieb lars.schnei...@autodesk.com: > >From: Lars Schneider > > > >Git and its tools (e.g. git diff) expect all text files in UTF-8 > >encoding. Git will happily accept content in

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

(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 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: [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] 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 .

[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: [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: 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: [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, #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: 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: 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: git diff: meaning of ^M at line ends ?

On 14.05.18 18:08, Frank Schäfer wrote: > What does ^M at the end of lines in the output of 'git diff' mean ? > > Thanks, > Frank > ^M is the representation of a "Carriage Return" or CR. Under Linux/Unix/Mac OS X a line is terminated with a single "line feed", LF. Windows typically uses CRLF

Re: Can not save changes into stash

[Please no top posting here] On 09.05.18 15:27, KES wrote: > I even can not drop local changes: > > $ git checkout local.conf > error: pathspec 'local.conf' did not match any file(s) known to git. > > $ git log local.conf > commit 6df8bab88fd703c6859954adc51b2abaad8f59ec > Author: Eugen Konkov

Re: git diff: meaning of ^M at line ends ?

On 15.05.18 20:04, Frank Schäfer wrote: > Am 14.05.2018 um 20:13 schrieb Torsten Bögershausen: >> ^M is the representation of a "Carriage Return" or CR. >> Under Linux/Unix/Mac OS X a line is terminated with a single >> "line feed", LF. >> >&g

Re: Why is there no force pull?

On Sat, Jun 09, 2018 at 09:01:54PM +0200, Christoph Böhmwalder wrote: > Hi, > > Since this is a use case that actually comes up quite often in > day-to-day use, especially among git beginners, I was wondering: is > there a specific reason why a command like "fetch changes from remote, >

Re: [PATCH] config.c: fix regression for core.safecrlf false

On Mon, Jun 11, 2018 at 06:46:34PM -0700, Anthony Sottile wrote: [] > Anything else for me to do here? (sorry! not super familiar with the process) Your patch has been picked up by Junio, and is currently merged into the "pu" branch (proposed updates): commit

t5562: gzip -k is not portable

Hej Max, t5562 fails here under MacOS: "gzip -k"  is not portable. The following works (there may be better solutions, I didn't dig into the test code) diff --git a/t/t5562-http-backend-content-length.sh b/t/t5562-http-backend-content-length.sh index 8040d80e04..7befe3885c 100755 ---

t5310 broken under Mac OS

One test case fails here, but I am to tired to dig further. ok 42 - pack reuse respects --incremental expecting success:     git repack -ad &&     git rev-list --use-bitmap-index --count --all >expect &&     bitmap=$(ls .git/objects/pack/*.bitmap) &&     test_when_finished "rm -f $bitmap" &&   

Re: t5310 broken under Mac OS

On 06/19/2018 07:35 PM, Eric Sunshine wrote: On Tue, Jun 19, 2018 at 1:33 PM Torsten Bögershausen wrote: expecting success: git repack -ad && git rev-list --use-bitmap-index --count --all >expect && bitmap=$(ls .git/objects/pack/*.bitmap) &&

Re: t5562: gzip -k is not portable

On 06/19/2018 08:22 PM, Eric Sunshine wrote: On Tue, Jun 19, 2018 at 2:06 PM Junio C Hamano wrote: Torsten Bögershausen writes: t5562 fails here under MacOS: "gzip -k" is not portable. Very odd. Stock /usr/bin/gzip on my MacOS 10.12.6 _does_ recognize -k, and the test

Re: Regression (?) in core.safecrlf=false messaging

(as usual, no top-posting here, please see my answers at the end) On Sun, Jun 03, 2018 at 10:54:00PM -0700, Anthony Sottile wrote: > I'm a bit unclear if I was depending on undocumented behaviour or not > here but it seems the messaging has recently changed with respect to > `core.safecrlf` > >

Re: Regression (?) in core.safecrlf=false messaging

Does the following patch fix your problem ? diff --git a/config.c b/config.c index 6f8f1d8c11..c625aec96a 100644 --- a/config.c +++ b/config.c @@ -1233,7 +1233,7 @@ static int git_default_core_config(const char *var, const char *value) } eol_rndtrp_die =

Re: Regression (?) in core.safecrlf=false messaging

On 04.06.18 17:43, Anthony Sottile wrote: > On Mon, Jun 4, 2018 at 12:55 AM, Torsten Bögershausen wrote: >> >> Does the following patch fix your problem ? >> >> diff --git a/config.c b/config.c >> index 6f8f1d8c11..c625aec96a 100644 >> --- a/config.c

Re: [PATCH 04/10] t0027: use $ZERO_OID

On Mon, Jun 04, 2018 at 11:52:23PM +, brian m. carlson wrote: > Use the ZERO_OID variable to express the all-zeros object ID so that it > works with hash algorithms of all sizes. > > Signed-off-by: brian m. carlson > --- > t/t0027-auto-crlf.sh | 14 +++--- > 1 file changed, 7

Re: [PATCH 01/10] t: add tool to translate hash-related values

Some style nite inline On Mon, Jun 04, 2018 at 11:52:20PM +, brian m. carlson wrote: > Add a test function helper, test_translate, that will produce its first > argument if the hash in use is SHA-1 and the second if its argument is > NewHash. Implement a mode that can read entries from a

Re: [PATCH] config.c: fix regression for core.safecrlf false

+ git add allcrlf 2>err && > + test_must_be_empty err > +' > + > + > test_expect_success 'switch off autocrlf, safecrlf, reset HEAD' ' > git config core.autocrlf false && > git config core.safecrlf false && > -- > 2.7.4 > Looks good to me, thanks for cleaning my mess. Acked-By: Torsten Bögershausen

Re: Use of new .gitattributes working-tree-encoding attribute across different platform types

On 27.06.18 09:54, Steve Groeger wrote: > Hi, > > Sorry for incomplete post earlier. Here is the full post: > > > In the latest version of git a new attribute has been added, > working-tree-encoding. The release notes states: > > 'The new "working-tree-encoding" attribute can ask Git to

Re: t5562: gzip -k is not portable

On Tue, Jun 19, 2018 at 04:53:10PM -0400, Jeff King wrote: > On Tue, Jun 19, 2018 at 10:40:16PM +0200, Torsten Bögershausen wrote: > > > > > > > On 06/19/2018 08:22 PM, Eric Sunshine wrote: > > > On Tue, Jun 19, 2018 at 2:06 PM Junio C Hamano wrote: >

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

On 26.04.18 18:48, Elijah Newren wrote: > On HFS (which appears to be the default Mac filesystem prior to High > Sierra), unicode names are "normalized" before recording. Thus with a > script like: > > mkdir tmp > cd tmp > > auml=$(printf "\303\244") > aumlcdiar=$(printf

Re: [PATCH v1 1/1] test: Correct detection of UTF8_NFD_TO_NFC for APFS

On 30.04.18 17:33, Elijah Newren wrote: > Hi, > > On Sun, Apr 29, 2018 at 11:35 PM, <tbo...@web.de> wrote: >> From: Torsten Bögershausen <tbo...@web.de> >> >> On HFS (which is the default Mac filesystem prior to High Sierra), >> unicode names are &qu

Re: [PATCH v1 1/1] test: Correct detection of UTF8_NFD_TO_NFC for APFS

On 30.04.18 09:56, Junio C Hamano wrote: > tbo...@web.de writes: > >> From: Torsten Bögershausen <tbo...@web.de> >> >> On HFS (which is the default Mac filesystem prior to High Sierra), >> unicode names are "decomposed" before recording. >> On

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 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: [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: [PATCH v2 1/5] strbuf: add xstrdup_toupper()

On Fri, Dec 29, 2017 at 04:22:18PM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > Create a copy of an existing string and make all characters upper case. > Similar xstrdup_tolower(). > > This function is used in a subsequent commit. > >

Re: [PATCH v1] convert: add support for 'encoding' attribute

On 2017-12-28 17:14, Lars Schneider wrote:> >> On 17 Dec 2017, at 18:14, Torsten Bögershausen <tbo...@web.de> wrote: >> >> On Mon, Dec 11, 2017 at 04:50:23PM +0100, lars.schnei...@autodesk.com wrote: >>> From: Lars Schneider <larsxsch

Re: [PATCH v2 4/5] convert: add support for 'checkout-encoding' attribute

I probably need to look at convert.c more closer, some other comments inline. On Fri, Dec 29, 2017 at 04:22:21PM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > Git and its tools (e.g. git diff) expect all text files in UTF-8 > encoding. Git will

Re: [PATCH v3 1/1] convert_to_git(): checksafe becomes int conv_flags

On 2018-01-05 20:00, Lars Schneider wrote: > >> On 01 Jan 2018, at 22:59, tbo...@web.de wrote: >> >> From: Torsten Bögershausen <tbo...@web.de> >> >> When calling convert_to_git(), the checksafe parameter has been used to >> check if commit would give

Re: [PATCH v1] convert: add support for 'encoding' attribute

On Mon, Dec 18, 2017 at 08:12:49AM -0500, Jeff King wrote: > On Mon, Dec 18, 2017 at 11:13:34AM +0100, Torsten Bögershausen wrote: > > > Just to confirm my missing knowledge here: > > Does this mean, that git-gui and gitk can decode/reencode > > the content of a file/blob,

Re: [PATCH v3 1/1] check-non-portable-shell.pl: Quoted `wc -l` is not portable

On Fri, Dec 22, 2017 at 01:07:59PM -0800, Junio C Hamano wrote: > tbo...@web.de writes: > > > > > Reviewed-by: Johannes Schindelin <johannes.schinde...@gmx.de> > > Signed-off-by: Torsten Bögershausen <tbo...@web.de> > > I'll flip these and add a

Re: [PATCH v3 0/7] convert: add support for different encodings

On Sat, Jan 06, 2018 at 01:48:01AM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > Hi, > > Patches 1-5 and 6 are helper functions and preparation. > Patch 6 is the actual change. > > I am still torn between "checkout-encoding" and

Re: [PATCH v3 5/7] convert_to_git(): safe_crlf/checksafe becomes int conv_flags

On Mon, Jan 08, 2018 at 11:47:20PM +0100, Lars Schneider wrote: > > > On 08 Jan 2018, at 22:28, Junio C Hamano wrote: > > > > lars.schnei...@autodesk.com writes: > > > >> diff --git a/sha1_file.c b/sha1_file.c > >> index afe4b90f6e..dcb02e9ffd 100644 > >> --- a/sha1_file.c >

Re: [PATCH v3 0/7] convert: add support for different encodings

On Mon, Jan 08, 2018 at 03:38:48PM +0100, Lars Schneider wrote: [] > > Some comments: > > > > I would like to have the CRLF conversion a little bit more strict - > > many users tend to set core.autocrlf=true or write "* text=auto" > > in the .gitattributes. > > Reading all the effort about BOM

Re: [PATCH/RFC v5 7/7] Careful with CRLF when using e.g. UTF-16 for working-tree-encoding

On Tue, Jan 30, 2018 at 12:23:47PM +0100, Lars Schneider wrote: > > > On 29 Jan 2018, at 21:19, tbo...@web.de wrote: > > > > From: Torsten Bögershausen <tbo...@web.de> > > > > UTF-16 encoded files are treated as "binary" by Git, and no CRLF &g

Re: Cloned repository has file changes -> bug?

On Sat, Jan 27, 2018 at 08:59:50PM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Sat, Jan 27 2018, Filip Jorissen jotted: > > > I think our git repository is bugged. The reason why I say this is the > > following. When cloning the repository, the newly cloned repository > > immediately has file

Re: [PATCH/RFC v5 7/7] Careful with CRLF when using e.g. UTF-16 for working-tree-encoding

[] > > That is a good one. > > If you ever plan a re-roll (I don't at the moment) the *.proj extemsion > > make much more sense in Documentation/gitattributes that *.tx > > There no text files encoded in UTF-16 wich are called xxx.txt, but those > > are non-ideal examples. *.proj makes good sense

contrib/completion/git-completion.bash: declare -g is not portable

Hej Duy, After running t9902-completion.sh on Mac OS I got a failure in this style: .../projects/git/git.pu/t/../contrib/completion/git-completion.bash: line 300: declare: -g: invalid option declare: usage: declare [-afFirtx] [-p] [name[=value] ...] --- expected2018-02-03 17:10:18.0

Re: [PATCH v1] name-hash: properly fold directory names in adjust_dirname_case()

On Wed, Feb 07, 2018 at 07:41:56PM -0500, Ben Peart wrote: [] > diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh > index b29d749bb7..219c96594c 100755 > --- a/t/t0050-filesystem.sh > +++ b/t/t0050-filesystem.sh > @@ -80,7 +80,17 @@ test_expect_success 'merge (case change)' ' > git

Re: [PATCH v2] name-hash: properly fold directory names in adjust_dirname_case()

On Thu, Feb 08, 2018 at 02:23:33PM -0500, Ben Peart wrote: [] > - > +test_expect_success CASE_INSENSITIVE_FS 'add directory (with different > case)' ' > + git reset --hard initial && > + mkdir -p dir1/dir2 && > + echo > dir1/dir2/a && > + echo > dir1/dir2/b && Thanks for

Re: [PATCH/RFC v5 7/7] Careful with CRLF when using e.g. UTF-16 for working-tree-encoding

On Fri, Feb 02, 2018 at 11:17:04AM -0800, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > > > There are 2 opposite opionions/user expectations here: > > > > a) They are binary in the working tree, so git should leave the line endings &

Re: Crash when clone includes magic filenames on Windows

On Sat, Feb 10, 2018 at 03:55:58AM -0500, Jeffrey Walton wrote: > Hi Everyone, > > I'm seeing this issue on Windows: https://pastebin.com/YfB25E4T . It > seems the filename AUX is the culprit. Also see > https://blogs.msdn.microsoft.com/oldnewthing/20031022-00/?p=42073 . > (Thanks to Milleneumbug

Re: [PATCH v6 5/7] convert: add 'working-tree-encoding' attribute

On Fri, Feb 09, 2018 at 02:28:28PM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > Git recognizes files encoded with ASCII or one of its supersets (e.g. > UTF-8 or ISO-8859-1) as text files. All other encodings are usually > interpreted as binary

Re: Duplicate safecrlf warning for racily clean index entry

On Tue, Feb 20, 2018 at 08:42:26AM -0500, Matt McCutchen wrote: > I noticed that if a file subject to a safecrlf warning is added to the > index in the same second that it is created, resulting in a "racily > clean" index entry, then a subsequent "git add" command prints another > safecrlf

Re: Line ending normalization doesn't work as expected

On Thu, Feb 15, 2018 at 09:24:40AM -0600, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote: [] > > Sorry to bring this old thread back to life, but I did notice that > this causes file modes to reset back to 644 (from 755) on Windows > version of

Re: [PATCH v7 0/7] convert: add support for different encodings

re for review, if someone thinks that it may be useful, I can send it as a real patch/RFC. git show HEAD commit 9f7d43f29eaf6017b7b16261ce91d8ef182cf415 Author: Torsten Bögershausen <tbo...@web.de> Date: Fri Feb 2 15:35:23 2018 +0100 Auto diff of UTF-16 files in UTF-8 When an

Re: [PATCH] status: handle worktree renames

On 2017-12-25 11:37, Nguyễn Thái Ngọc Duy wrote: [] > wt-status.c | 24 +++- > wt-status.h | 1 + > 3 files changed, 35 insertions(+), 5 deletions(-) > > diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh > index 1bdf38e80d..41a8874e60 100755 >

Re: [PATCH v7 0/7] convert: add support for different encodings

On Sun, Feb 25, 2018 at 08:44:46PM -0500, Jeff King wrote: > On Sat, Feb 24, 2018 at 04:18:36PM +0100, Lars Schneider wrote: > > > > We always use the in-repo contents when generating 'diff'. I think > > > by "attribute to be used in diff", what you are reallying after is > > > to convert the

Re: t5562: gzip -k is not portable

On Wed, Jun 20, 2018 at 08:40:06AM -0400, Jeff King wrote: > On Wed, Jun 20, 2018 at 08:13:06AM +0200, Torsten Bögershausen wrote: > > > Good eyes, thanks. > > The "-f -c" combo works: > > > > - gzip -k fetch_body &&

Re: [PATCH/RFC] clone: report duplicate entries on case-insensitive filesystems

On 2018-08-02 15:43, Duy Nguyen wrote: > On Wed, Aug 1, 2018 at 11:20 PM Junio C Hamano wrote: >> >> Junio C Hamano writes: >> >>> Jeff King writes: >>> > Presumably we are already in an error codepath, so if it is > absolutely necessary, then we can issue a lstat() to grab the inum

Re: [PATCH/RFC] clone: report duplicate entries on case-insensitive filesystems

On Mon, Jul 30, 2018 at 05:27:55PM +0200, Nguyễn Thái Ngọc Duy wrote: > Paths that only differ in case work fine in a case-sensitive > filesystems, but if those repos are cloned in a case-insensitive one, > you'll get problems. The first thing to notice is "git status" will > never be clean with

Re: [PATCH v4] clone: report duplicate entries on case-insensitive filesystems

On Sun, Aug 12, 2018 at 11:07:14AM +0200, Nguyễn Thái Ngọc Duy wrote: > Paths that only differ in case work fine in a case-sensitive > filesystems, but if those repos are cloned in a case-insensitive one, > you'll get problems. The first thing to notice is "git status" will > never be clean with

Re: "Changes not staged for commit" after cloning a repo on macOS

On Thu, Aug 16, 2018 at 12:25:24AM +0430, Hadi Safari wrote: > Hi everyone! > > I encountered a strange situation on OS X recently. I cloned a repository > (https://github.com/kevinxucs/Sublime-Gitignore.git), went to folder, and > saw "Changes not staged for commit" message for four specific

Re: [PATCH v4] clone: report duplicate entries on case-insensitive filesystems

On Wed, Aug 15, 2018 at 12:38:49PM -0700, Junio C Hamano wrote: This should answer Duys comments as well. > Torsten Bögershausen writes: > [snip] > > Should the following be protected by core.checkstat ? > > if (check_stat) { > > I do not think such a if stateme

Re: [PATCH v5] clone: report duplicate entries on case-insensitive filesystems

On Fri, Aug 17, 2018 at 06:16:45PM +0200, Nguyễn Thái Ngọc Duy wrote: The whole patch looks good to me. (I was just sending a different version, but your version is better :-) One minor remark, should the line warning: the following paths have collided start with a capital letter: Warning: the

Re: Automatic core.autocrlf?

On Mon, Aug 27, 2018 at 09:10:33AM -0500, Robert Dailey wrote: > Is there an 'auto' setting for the 'core.autocrlf' config? Reason I > ask is, I want that setting to be 'input' on linux but 'true' on > Windows. I have a global .gitconfig that I sync across different > platforms with Google Drive,

Re: [PATCH v2 05/11] t0027: make hash size independent'

On 20.08.18 00:10, Eric Sunshine wrote: > On Sun, Aug 19, 2018 at 5:57 PM brian m. carlson > wrote: >> On Sun, Aug 19, 2018 at 04:10:21PM -0400, Eric Sunshine wrote: >>> On Sun, Aug 19, 2018 at 1:54 PM brian m. carlson - tr '\015\000abcdef0123456789' QN0 <"$2" >"$exp"

Re: [PATCH 0/1] t7406: avoid failures solely due to timing issues

On Mon, Jul 23, 2018 at 12:10:24PM -0700, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > This fixes a regression test that produces false positives occasionally: > > https://git-for-windows.visualstudio.com/git/_build/results?buildId=14035=logs > > > > [jc:

t7406-submodule-update shaky ?

It seems that t7406 is sometimes shaky - when checking stderr in test case 4. The order of the submodules may vary, sorting the stderr output makes it more reliable (and somewhat funny to read). Does anybody have a better idea ? [] cat

Re: [PATCH 5/6] pass st.st_size as hint for strbuf_readlink()

On Tue, Jul 24, 2018 at 06:51:39AM -0400, Jeff King wrote: > When we initially added the strbuf_readlink() function in > b11b7e13f4 (Add generic 'strbuf_readlink()' helper function, > 2008-12-17), the point was that we generally have a _guess_ > as to the correct size based on the stat

Re: Automatic core.autocrlf?

On Thu, Aug 30, 2018 at 09:57:52AM -0500, Robert Dailey wrote: > On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder wrote: > > > > Hi, > > > > Robert Dailey wrote: > > > > > Is there an 'auto' setting for the 'core.autocrlf' config? Reason I > > > ask is, I want that setting to be 'input' on linux

Re: [PATCH v3 05/11] t0027: make hash size independent

On Wed, Aug 29, 2018 at 12:56:36AM +, brian m. carlson wrote: > We transform various object IDs into all-zero object IDs for comparison. > Adjust the length as well so that this works for all hash algorithms. > > Signed-off-by: brian m. carlson > --- > t/t0027-auto-crlf.sh | 6 -- > 1

Re: [PATCH v3 4/4] read-cache: speed up index load through parallelization

> diff --git a/read-cache.c b/read-cache.c > index fcc776aaf0..8537a55750 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -1941,20 +1941,212 @@ static void *load_index_extensions(void *_data) > return NULL; > } > > +/* > + * A helper function that will load the specified range of

Re: Automatic core.autocrlf?

On Fri, Aug 31, 2018 at 07:57:04AM -0400, Randall S. Becker wrote: > > On August 30, 2018 11:29 PM, Jonathan Nieder wrote: > > Torsten Bögershausen wrote: > > > > > My original plan was to try to "make obsolete"/retire and phase out > > > core.autoc

Re: [PATCH v2 0/6] Force pipes to flush immediately on NonStop platform

On Fri, Jan 19, 2018 at 12:33:59PM -0500, randall.s.bec...@rogers.com wrote: > From: "Randall S. Becker" > > * wrapper.c: called setbuf(stream,0) to force pipe flushes not enabled by > default on the NonStop platform. > > Signed-off-by: Randall S. Becker

Re: [PATCH v4 0/6] convert: add support for different encodings

On Sat, Jan 20, 2018 at 04:24:12PM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > Hi, > > Patches 1-4 and 6 are preparation and helper functions. > Patch 5 is the actual change. I (still) have 2 remarks on convert.c - to make live easier, I will

Re: [PATCH v7 0/7] convert: add support for different encodings

On Mon, Feb 26, 2018 at 03:46:35PM -0500, Jeff King wrote: > On Mon, Feb 26, 2018 at 06:35:33PM +0100, Torsten Bögershausen wrote: > > > > diff --git a/userdiff.c b/userdiff.c > > > index dbfb4e13cd..48fa7e8bdd 100644 > > > --- a/userdiff.c > > &g

Re: [PATCH v9 4/8] utf8: add function to detect a missing UTF-16/32 BOM

On Tue, Mar 06, 2018 at 03:37:16PM -0800, Junio C Hamano wrote: > Lars Schneider writes: > > > After thinking about it I wonder if we should barf on "utf16" without > > dash. Your Linux iconv would handle this correctly. My macOS iconv would > > not. > > That means the

Re: [PATCH v11 06/10] convert: add 'working-tree-encoding' attribute

On 01.04.18 15:24, Lars Schneider wrote: >> TRUE or false are values, but just wrong ones. >> If this test is removed, the user will see "failed to encode "TRUE" to >> "UTF-8", >> which should give enough information to fix it. > > I see your point. However, I would like to stop the processing

Re: [PATCH v11 06/10] convert: add 'working-tree-encoding' attribute

Some comments inline On Fri, Mar 09, 2018 at 06:35:32PM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > Git recognizes files encoded with ASCII or one of its supersets (e.g. > UTF-8 or ISO-8859-1) as text files. All other encodings are usually >

t006 broken under Mac OS

Hej, Beside that t1006 has a broken indentation (mixed spaces and TABs at the beginning of the line, I get 4 errors here under Mac OS: not ok 15 - Check %(refname) gives empty output not ok 36 - Check %(refname) gives empty output not ok 58 - Check %(refname) gives empty output not ok 89 - Check

Re: [PATCH v7 0/7] convert: add support for different encodings

On 2018-02-28 14:21, Jeff King wrote: > On Wed, Feb 28, 2018 at 09:20:05AM +0100, Torsten Bögershausen wrote: > >>> 2. auto-detect utf-16 (your patch) >>> - Just Works for existing repositories storing utf-16 >>> >>> - carries some

Re: [PATCH v7 0/7] convert: add support for different encodings

On Tue, Feb 27, 2018 at 04:25:38PM -0500, Jeff King wrote: > On Tue, Feb 27, 2018 at 10:05:17PM +0100, Torsten Bögershausen wrote: > > > The other question is: > > Would this help showing diffs of UTF-16 encoded files on a "git hoster", > > github/bitbucket/..

Re: [PATCH v4] Documentation: declare "core.ignoreCase" as internal variable

On 28.06.18 13:21, Marc Strapetz wrote: > The current description of "core.ignoreCase" reads like an option which > is intended to be changed by the user while it's actually expected to > be set by Git on initialization only. Subsequently, Git relies on the > proper configuration of this variable,

Re: [PATCH v2] Documentation: declare "core.ignorecase" as internal variable

On Sun, Jun 24, 2018 at 12:44:26PM +0200, Marc Strapetz wrote: > The current description of "core.ignoreCase" reads like an option which > is intended to be changed by the user while it's actually expected to > be set by Git on initialization only. This is especially important for > Git for

Re: [PATCH v2 1/1] zlib.c: use size_t for size

[] > Neither v1 nor v2 of this patch compiles on 32 bit Linux; see > > https://travis-ci.org/git/git/jobs/440514375#L628 > > The fixup patch below makes it compile on 32 bit and the test suite > passes as well, but I didn't thoroughly review the changes; I only > wanted to get 'pu' build

Re: [PATCH v2 1/1] zlib.c: use size_t for size

On 15.10.18 06:22, Junio C Hamano wrote: > Ramsay Jones writes: > >>> >>> For the record, I am not opposed to including the comment _and_ using >>> xsize_t() to do the cast, giving us an assertion that the comment is >>> correct. >> >> Heh, I haven't found any enthusiasm tonight. Let's see if

Re: [PATCH v1 2/2] curl_off_t xcurl_off_t is not portable

On Fri, Oct 26, 2018 at 11:48:38AM +0900, Junio C Hamano wrote: > tbo...@web.de writes: > > > From: Torsten Bögershausen > > > Subject: Re: [PATCH v1 2/2] curl_off_t xcurl_off_t is not portable > > That title is misleading; it sounded as if the are these two >

Re: [PATCH 3/3] cat-file: handle streaming failures consistently

On Tue, Oct 30, 2018 at 07:23:38PM -0400, Jeff King wrote: > There are three ways to convince cat-file to stream a blob: > > - cat-file -p $blob > > - cat-file blob $blob > > - echo $batch | cat-file --batch > > In the first two, we simply exit with the error code of >

Re: git-rebase is ignoring working-tree-encoding

On Fri, Nov 02, 2018 at 03:30:17AM +0100, Adrián Gimeno Balaguer wrote: > I’m attempting to perform fixups via git-rebase of UTF-16 LE files > (the project I’m working on requires that exact encoding on certain > files). When the rebase is complete, Git changes that file’s encoding > to UTF-16 BE.

Re: [PATCH] Prevent warning

Thanks for the patch. Could you please sign it off ? The other remark would be if the header line could be written longer than just "Prevent warning". to give people digging into the Git history an initial information, where the warning occured and from which module it was caused. May be something

Re: [PATCH] wildmatch: change behavior of "foo**bar" in WM_PATHNAME mode

On Sat, Oct 27, 2018 at 10:48:23AM +0200, Nguyễn Thái Ngọc Duy wrote: > In WM_PATHNAME mode (or FNM_PATHNAME), '*' does not match '/' and '**' > can but only in three patterns: > > - '**/' matches zero or more leading directories > - '/**/' matches zero or more directories in between > - '/**'

<    7   8   9   10   11   12   13   >