Re: [PATCH] tests: avoid syntax triggering old dash bug

On Wed, Nov 28, 2018 at 01:47:41AM +, brian m. carlson wrote: > On Tue, Nov 27, 2018 at 05:42:53PM +0100, Ævar Arnfjörð Bjarmason wrote: > > Avoid a bug in dash that's been fixed ever since its > > ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first > > released with dash

t5570 shaky for anyone ?

After running the "Git 2.20-rc1" testsuite here on a raspi, the only TC that failed was t5570. When the "grep" was run on daemon.log, the file was empty (?). When inspecting it later, it was filled, and grep would have found the "extended.attribute" it was looking for. The following fixes it,

Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)

On Sun, Nov 25, 2018 at 05:28:35AM +0100, Torsten Bögershausen wrote: > On Sat, Nov 24, 2018 at 08:33:37PM +0100, Ævar Arnfjörð Bjarmason wrote: > > > > On Wed, Sep 05 2018, Ævar Arnfjörð Bjarmason wrote: > > > > > On Wed, Sep 05 2018, Eric Sunshine wrote: > >

Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)

On Sat, Nov 24, 2018 at 08:33:37PM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Sep 05 2018, Ævar Arnfjörð Bjarmason wrote: > > > On Wed, Sep 05 2018, Eric Sunshine wrote: [] > > SunCC used to be ahead of GCC & Clang when it came to certain classes of > > warnings, but e.g. now everything

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

On Sat, Nov 24, 2018 at 03:51:26PM +0100, Frank Schäfer wrote: [] > > Hmm... is CR-only line termination supported at all ? > E.g. 'eol' can be set to 'lf' or 'crlf' but not 'cr'... > No, CR-only is not supported, because: Nobody was implementing it, and that is probably because the only

Re: Cygwin Git with Windows paths

On 20.11.18 01:17, Steven Penny wrote: > On Sun, Nov 18, 2018 at 11:21 PM Torsten Bögershausen wrote: >> If nothing works, >> it may help to add some fprintf(stderr,...) in the functions used >> by 05b458c104708141d2f: >> >> strip_last_component(), >> get

Re: grep issues

On Sun, Nov 11, 2018 at 03:17:50PM +0200, Orgad Shaneh wrote: > Hi, > > I found 2 bugs in grep, using Git for Windows 2.19.1 (but noticed > these several versions ago): > > 1. git grep --recursive on a worktree (without rev) always matches > against the submodule's HEAD, not its worktree, as it

Re: [PATCH/RFC v2 1/1] Use size_t instead of 'unsigned long' for data in memory

On Tue, Nov 20, 2018 at 06:04:54AM +0100, tbo...@web.de wrote: > From: Torsten Bögershausen > > Currently the length of data which is stored in memory is stored > in "unsigned long" at many places in the code base. > This is OK when both "unsigned long" and si

Re: [PATCH/RFC v1 1/1] Use size_t instead of unsigned long

On Sun, Nov 18, 2018 at 03:18:52PM -0500, Derrick Stolee wrote: > On 11/17/2018 10:11 AM, tbo...@web.de wrote: > >From: Torsten Bögershausen > > > >Currently Git users can not commit files >4Gib under 64 bit Windows, > >where "long" is 32 bit but si

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

On 2018-11-19 09:20, Carlo Marcelo Arenas Belón wrote: > While I don't have an HFS+ volume to test, I suspect this patch should be > needed for both, even if I have to say thay even the broken output was > better than the current state. > > Travis seems to be using a case sensitive filesystem so

Re: [PATCH/RFC v1 1/1] Use size_t instead of unsigned long

On 2018-11-19 00:40, Junio C Hamano wrote: > Derrick Stolee writes: > >>> This needs to go on top of pu, to cover all the good stuff >>>cooking here. >> >> Better to work on top of 'master', as the work in 'pu' will be >> rewritten several times, probably. > > We may not be able to find any

Re: Cygwin Git with Windows paths

On 2018-11-19 04:33, Junio C Hamano wrote: > "Randall S. Becker" writes: > >>> Torsten Bögershausen writes: >>> >>>> And it may even be that we need a special handling for the "\" to be >>>> treated as "/". >&

Re: Cygwin Git with Windows paths

On Sun, Nov 18, 2018 at 11:34:04AM -0600, Steven Penny wrote: > On Sun, Nov 18, 2018 at 11:15 AM Torsten Bögershausen wrote: > > But it may be that we need to pull in more stuff, similar to mingw, > > to get the C: stuff working, see > > "skip_dos_drive_prefix" >

Re: Cygwin Git with Windows paths

On Sun, Nov 18, 2018 at 10:23:19AM -0600, Steven Penny wrote: > On Sun, Nov 18, 2018 at 9:41 AM Torsten Bögershausen wrote: > > Thanks for the report > > It seams as if "C:" is not recognized as an absolute path under > > cygwin. > > May be it should ? >

Re: Cygwin Git with Windows paths

On Sun, Nov 18, 2018 at 07:21:58AM -0800, Steven Penny wrote: > Cygwin programs can handle Unix form paths: > >$ ls /var >cache lib log run tmp > > and also Windows form paths: > >$ ls 'C:\cygwin64\var' >cache lib log run tmp > > However current Cygwin Git cannot: > >

Re: [PATCH v2 1/1] remote-curl.c: xcurl_off_t is not portable (on 32 bit platfoms)

On Mon, Nov 12, 2018 at 12:50:30PM +0900, Junio C Hamano wrote: > tbo...@web.de writes: > > > > > This is a re-semd, the orignal patch was part of a 2 > > patch-series. > > This patch needed some rework, and here should be > > the polished version. > > Will queue. Thanks, is there a chance to

Re: [PATCH v2 1/1] Upcast size_t variables to uintmax_t when printing

On Sun, Nov 11, 2018 at 02:28:35AM -0500, Jeff King wrote: > On Sun, Nov 11, 2018 at 08:05:04AM +0100, tbo...@web.de wrote: > > > From: Torsten Bögershausen > > > > When printing variables which contain a size, today "unsigned long" > > is used at many p

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

On Wed, Nov 07, 2018 at 05:38:18AM +0100, Adrián Gimeno Balaguer wrote: > Hello Torsten, > > Thanks for answering. > > Answering to your question, I removed the comments with "rebase" since > my reported encoding issue happens on more simpler operations > (described in the PR), and the problem

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

On Mon, Nov 05, 2018 at 07:10:14PM +0100, Torsten Bögershausen wrote: > On Mon, Nov 05, 2018 at 05:24:39AM +0100, Adrián Gimeno Balaguer wrote: > > [] > > > https://github.com/git/git/pull/550 > > [] > > > This is covered in the mentioned PR above.

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

On Mon, Nov 05, 2018 at 05:24:39AM +0100, Adrián Gimeno Balaguer wrote: [] > https://github.com/git/git/pull/550 [] > This is covered in the mentioned PR above. Thanks for feedback. Thanks for the code, I will have a look (the next days) > > -- > Adrián

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

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] builtin/receive-pack: dead initializer for retval in check_nonce

On Sat, Oct 20, 2018 at 12:08:59AM -0700, Carlo Marcelo Arenas Belón wrote: > NONCE_BAD is explicitly set when needed with the fallback > instead as NONCE_SLOP > > Signed-off-by: Carlo Marcelo Arenas Belón > --- > builtin/receive-pack.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

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 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 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: [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: 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: 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: 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 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: [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: "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 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: [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 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: [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 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: 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: [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: 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: 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: 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: 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) &&

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" &&   

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

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

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

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

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

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

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

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/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

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

  1   2   3   4   5   6   7   8   9   10   >