e to be done in the zlib interface.
Reviewed-by: Johannes Schindelin
Signed-off-by: Torsten Bögershausen
---
This is the 3rd version of the patch.
- Dscho contributed with a code-review (converted 2 more unsigned long)
- Thomas Braun and Philip Oakley have done more work:
https://github
From: Torsten Bögershausen
Some compilers don't allow NULL to be passed for a va_list,
and e.g. "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516"
errors out like this:
trace2/tr2_tgt_event.c:193:18:
error: invalid operands to binary &&
(have ‘int’ and ‘va_list {aka __va_list}’)
if (
From: Torsten Bögershausen
Some compilers don't allow NULL to be passed for a va_list.
Use va_list instead.
Signed-off-by: Torsten Bögershausen
---
trace2.c| 15 +++
trace2.h| 4 ++--
trace2/tr2_tgt_event.c | 2 +-
trace2/tr2_tgt_normal.c | 2 +-
From: Torsten Bögershausen
The content of a buffer can be dumped using trace_encoding()
before and after the encoding is converted.
The current function trace_encoding() in convert.c tries to
make the output easier to read:
The byte position and the character itself are dimmed, allowing
the eye t
From: Yash Bhatambare
`UTF-16-LE-BOM` to `UTF-16LE-BOM`.
this closes https://github.com/git-for-windows/git/issues/2095
Signed-off-by: Yash Bhatambare
Signed-off-by: Torsten Bögershausen
---
This patch already made it into Git for Windows,
so I send it upstream "as is".
Documentation/gitatt
From: Torsten Bögershausen
Users who want UTF-16 files in the working tree set the .gitattributes
like this:
test.txt working-tree-encoding=UTF-16
The unicode standard itself defines 3 allowed ways how to encode UTF-16.
The following 3 versions convert all back to 'g' 'i' 't' in UTF-8:
a) UTF-1
From: Torsten Bögershausen
Users who want UTF-16 files in the working tree set the .gitattributes
like this:
test.txt working-tree-encoding=UTF-16
The unicode standard itself defines 3 possible ways how to encode UTF-16.
The following 3 versions convert all back to 'g' 'i' 't' in UTF-8:
a) UTF-
From: Torsten Bögershausen
From `man sed` (on a Mac OS X box):
The -E, -a and -i options are non-standard FreeBSD extensions and may not be
available
on other operating systems.
From `man sed` on a Linux box:
REGULAR EXPRESSIONS
POSIX.2 BREs should be supported, but they aren't completel
From: Torsten Bögershausen
From `man sed` (on a Mac OS X box):
The -E, -a and -i options are non-standard FreeBSD extensions and may not be
available
on other operating systems.
From `man sed` on a Linux box:
REGULAR EXPRESSIONS
POSIX.2 BREs should be supported, but they aren't completel
From: Torsten Bögershausen
Users who want UTF-16 files in the working tree set the .gitattributes
like this:
test.txt working-tree-encoding=UTF-16
After a checkout, the resulting file has a BOM and is encoded in "UTF-16".
The unicode standard allows both little- and big-endianess (LE/BE) for
tho
From: Torsten Bögershausen
A regression for cygwin users was introduced with commit 05b458c,
"real_path: resolve symlinks by hand".
In the the commit message we read:
The current implementation of real_path uses chdir() in order to resolve
symlinks. Unfortunately this isn't thread-safe a
From: Torsten Bögershausen
A regression for cygwin users was introduced with commit 05b458c,
"real_path: resolve symlinks by hand".
In the the commit message we read:
The current implementation of real_path uses chdir() in order to resolve
symlinks. Unfortunately this isn't thread-safe a
From: Torsten Bögershausen
A regression for cygwin users was introduced with commit 05b458c,
"real_path: resolve symlinks by hand".
In the the commit message we read:
The current implementation of real_path uses chdir() in order to resolve
symlinks. Unfortunately this isn't thread-safe a
From: Torsten Bögershausen
The Windows version of offset_1st_component() needs to hande 3 cases:
- The path is an UNC path, starting with "//" or "".
Skip the servername and the name of the share.
- The path is a DOS drive, starting with e.g. "X:"
The driver letter and the ':' must be ski
From: Torsten Bögershausen
Change the return value for offset_1st_component(),
has_dos_drive_prefix() and skip_dos_drive_prefix from int into size_t,
which is the natural type for length of data in memory.
While at it, remove possible "parameter not used" warnings in for the
non-Windows builds i
From: Torsten Bögershausen
A regression for cygwin users was introduced with commit 05b458c,
"real_path: resolve symlinks by hand".
In the the commit message we read:
The current implementation of real_path uses chdir() in order to resolve
symlinks. Unfortunately this isn't thread-safe as
From: Torsten Bögershausen
Commit b878579ae7 (clone: report duplicate entries on case-insensitive
filesystems - 2018-08-17) adds a warning to user when cloning a repo
with case-sensitive file names on a case-insensitive file system.
This test has never been enabled for MINGW.
It had been working
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 size_t are 32 bits,
(and is OK when both are 64 bits).
On a 64 bit Windows system am "unsigned long" is 32 bit,
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 size_t are 32 bits,
(and is OK when both are 64 bits).
On a 64 bit Windows system am "unsigned long" is 32 bit,
From: Torsten Bögershausen
Currently Git users can not commit files >4Gib under 64 bit Windows,
where "long" is 32 bit but size_t is 64 bit.
Improve the code base in small steps, as small as possible.
What started with a small patch to replace "unsigned long" with size_t
in one file (convert.c) e
From: Torsten Bögershausen
When printing variables which contain a size, today "unsigned long"
is used at many places.
In order to be able to change the type from "unsigned long" into size_t
some day in the future, we need to have a way to print 64 bit variables
on a system that has "unsigned lon
From: Torsten Bögershausen
When setting
DEVELOPER = 1
DEVOPTS = extra-all
"gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516" errors out with
"comparison is always false due to limited range of data type"
"[-Werror=type-limits]"
It turns out that the function xcurl_off_t() has 2 flavours:
- I
From: Torsten Bögershausen
When printing variables which contains a size, today "unsigned long"
is used at many places.
In order to be able to change the type from "unsigned long" into size_t
some day the future, we need to have a way to print 64 bit variables
on a system that has "unsigned long"
From: Torsten Bögershausen
When setting
DEVELOPER = 1
DEVOPTS = extra-all
"gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516" errors out with
"comparison is always false due to limited range of data type"
"[-Werror=type-limits]"
It turns out that the function xcurl_off_t() has 2 flavours:
- I
From: Torsten Bögershausen
If a "char" in C is signed or unsigned is not specified, because it is
out of tradition "implementation dependent".
Therefore constructs like "if (name[i] < 0)" are not portable,
use "if (name[i] & 0x80)" instead.
Detected by "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0
From: Torsten Bögershausen
Comparing signed and unsigned values is not always portable.
When setting
DEVELOPER = 1
DEVOPTS = extra-all
"gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516" errors out with
"comparison is always false due to limited range of data type"
"[-Werror=type-limits]"
Sol
From: Torsten Bögershausen
When streaming data from disk into a blob, it should be possible to commit
a file with a file size > 4 GiB using the streaming functionality in Git.
Because of the streaming there is no need to load the whole data into
memory at once.
Today this is not possible on e.g.
From: Torsten Bögershausen
When streaming data from disk into a blob, use off_t instead of
size_t, which is a better choice for file length.
Signed-off-by: Torsten Bögershausen
---
This is based on an old patch from 2017, which never made it to the list.
I think it make sense to have off_t/siz
From: Martin Koegler
Signed-off-by: Martin Koegler
Signed-off-by: Junio C Hamano
Signed-off-by: Torsten Bögershausen
---
After doing a review, I decided to send the result as a patch.
In general, the changes from off_t to size_t seem to be not really
motivated.
But if they are, they could and
From: Torsten Bögershausen
git_check_attr() returns always 0.
Remove all the error handling code of the callers, which is never executed.
Change git_check_attr() to be a void function.
Signed-off-by: Torsten Bögershausen
---
archive.c | 3 ++-
attr.c | 8 +++-
From: Torsten Bögershausen
On HFS (which is the default Mac filesystem prior to High Sierra),
unicode names are "decomposed" before recording.
On APFS, which appears to be the new default filesystem in Mac OS High
Sierra, filenames are recorded as specified by the user.
APFS continues to allow t
>From 9f7d43f29eaf6017b7b16261ce91d8ef182cf415 Mon Sep 17 00:00:00 2001
In-Reply-To: <20171218131249.gb4...@sigill.intra.peff.net>
References: <20171218131249.gb4...@sigill.intra.peff.net>
From: =?UTF-8?q?Torsten=20B=C3=B6gershausen?=
Date: Fri, 23 Feb 2018 20:53:34 +0100
Subject: [PATCH 0/1] Auto
From: Torsten Bögershausen
When an UTF-16 file is commited and later changed, `git diff` shows
"Binary files XX and YY differ".
When the user wants a diff in UTF-8, a textconv needs to be specified
in .gitattributes and the textconv must be configured.
A more user-friendly diff can be produced
From: Lars Schneider
Since 3733e69464 (use xmallocz to avoid size arithmetic, 2016-02-22) we
allocate the buffer for the lower case string with xmallocz(). This
already ensures a NUL at the end of the allocated buffer.
Remove the unnecessary assignment.
Signed-off-by: Lars Schneider
Signed-off
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 and consequently built-in Git text processing
tools (e.g. 'git diff') as well as most Git web front ends do not
visu
From: Torsten Bögershausen
UTF-16 encoded files are treated as "binary" by Git, and no CRLF
conversion is done.
When the UTF-16 encoded files are converted into UF-8 using the new
"working-tree-encoding", the CRLF are converted if core.autocrlf is true.
This may lead to confusion:
A tool writes
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.
Signed-off-by: Lars Schneider
Signed-off-by: Torsten Bögershausen
---
strbuf.c | 12
strbuf.h | 1 +
2 files cha
From: Lars Schneider
Add the GIT_TRACE_CHECKOUT_ENCODING environment variable to enable
tracing for content that is reencoded with the 'working-tree-encoding'
attribute. This is useful to debug encoding issues.
Signed-off-by: Lars Schneider
Signed-off-by: Torsten Bögershausen
---
convert.c
From: Lars Schneider
Whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE
or UTF-32LE a BOM must not be used [1]. The function returns true if
this is the case.
This function is used in a subsequent commit.
[1] http://unicode.org/faq/utf_bom.html#bom10
Signed-off-by: Lars Schn
From: Lars Schneider
If the endianness is not defined in the encoding name, then let's
be strict and require a BOM to avoid any encoding confusion. The
has_missing_utf_bom() function returns true if a required BOM is
missing.
The Unicode standard instructs to assume big-endian if there in no BOM
From: Torsten Bögershausen
Take V4 from Lars, manually integrated the V2 squash patch,
so a review would be good.
Add my "comments" as a patch, see 7/7 (and this is more like an RFC)
This needs to go on top of tb/crlf-conv-flags
Lars Schneider (6):
strbuf: remove unnecessary NUL assignment
From: Torsten Bögershausen
When calling convert_to_git(), the checksafe parameter defined what
should happen if the EOL conversion (CRLF --> LF --> CRLF) does not
roundtrip cleanly. In addition, it also defined if line endings should
be renormalized (CRLF --> LF) or kept as they are.
checksafe w
From: Torsten Bögershausen
When calling convert_to_git(), the checksafe parameter has been used to
check if commit would give a non-roundtrip conversion of EOL.
When checksafe was introduced, 3 values had been in use:
SAFE_CRLF_FALSE: no warning
SAFE_CRLF_FAIL: reject the commit if EOL do not r
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.
Signed-off-by: Lars Schneider
Signed-off-by: Torsten Bögershausen
---
strbuf.c | 13 +
strbuf.h | 1 +
2 files ch
From: Lars Schneider
If the endianness is not defined in the encoding name, then let's
be strict and require a BOM to avoid any encoding confusion. The
has_missing_utf_bom() function returns true if a required BOM is
missing.
The Unicode standard instructs to assume big-endian if there in no BOM
From: Torsten Bögershausen
Simplify the convert.h/convert.c logic amd don't touch convert_to_git()
The rest is v2 from Lars
Lars Schneider (4):
strbuf: add xstrdup_toupper()
utf8: add function to detect prohibited UTF-16/32 BOM
utf8: add function to detect a missing UTF-16/32 BOM
convert
From: Lars Schneider
Whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE
or UTF-32LE a BOM must not be used [1]. The function returns true if
this is the case.
This function is used in a subsequent commit.
[1] http://unicode.org/faq/utf_bom.html#bom10
Signed-off-by: Lars Schn
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 to process the text (e.g. viewing diffs or
changing line endings).
Add an attribute to tell Git what encoding the
From: Torsten Bögershausen
When calling convert_to_git(), the checksafe parameter has been used to
check if commit would give a non-roundtrip conversion of EOL.
When checksafe was introduced, 3 values had been in use:
SAFE_CRLF_FALSE: no warning
SAFE_CRLF_FAIL: reject the commit if EOL do not r
From: Torsten Bögershausen
RFC patch: convert files from e.g. UTF-16 into UTF-8 while running
"git diff".
The diff must be called with "git diff --UTF-8" and the "encoding"
attribute must be set for the file(s).
The commit messages may need some improvements, and a closer look
at diff.c, how com
From: Torsten Bögershausen
When blobs are encoded in UTF-16, `git diff` will treat them as binary.
Make it possible to show a user readable diff encoded in UTF-8.
This allows to run git diff and feed the into a web sever.
Improve Git to look at the "encodig" attribute and to reencode the
content
From: Torsten Bögershausen
When calling convert_to_git(), the checksafe parameter has been used to
check if commit would give a non-roundtrip conversion of EOL.
When checksafe was introduced, 3 values had been in use:
SAFE_CRLF_FALSE: no warning
SAFE_CRLF_FAIL: reject the commit if EOL do not r
From: Torsten Bögershausen
wc -l was used to count the number if lines in test scripts.
$ wc -l Makefile
gives a line like this:
105 Makefile
while Mac OS has 4 leading spaces:
105 Makefile
And this means that shell expressions like
test "$(wc -l
From: Torsten Bögershausen
wc -l was used to count the number if lines in test scripts.
$ wc -l Makefile
gives a line like this:
105 Makefile
while Mac OS has 4 leading spaces:
105 Makefile
And this means that shell expressions like
test "$(wc -l
From: Torsten Bögershausen
wc -l is used to count the number if lines in test scripts.
$ wc -l Makefile
gives a line like this:
105 Makefile
while Mac OS has 4 leading spaces:
105 Makefile
And this means that shell expressions like
test "$(wc -l
From: Torsten Bögershausen
Replace `git commit -m "comment" ""` with `git commit -m "comment"` to
remove the empty path spec.
Signed-off-by: Torsten Bögershausen
---
t/t0027-auto-crlf.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crl
From: Torsten Bögershausen
The new MIX tests don't pass under Windows, adapt them
to use the correct native line ending.
Signed-off-by: Torsten Bögershausen
---
Sorry for the breakage.
This needs to go on top of tb/check-crlf-for-safe-crlf
t/t0027-auto-crlf.sh | 17 +
1 fi
From: Torsten Bögershausen
When a text file had been commited with CRLF and the file is commited
again, the CRLF are kept if .gitattributs has "text=auto".
This is done by analyzing the content of the blob stored in the index:
If a '\r' is found, Git assumes that the blob was commited with CRLF.
From: Torsten Bögershausen
When a text file had been commited with CRLF and the file is commited
again, the CRLF are kept if .gitattributs has "text=auto".
This is done by analyzing the content of the blob stored in the index:
If a '\r' is found, Git assumes that the blob was commited with CRLF.
From: Torsten Bögershausen
Make it safer to normalize the line endings in a repository:
Files that had been commited with CRLF will be commited with LF.
The old way to normalize a repo was like this:
# Make sure that there are not untracked files
$ echo "* text=auto" >.gitattributes
$ git rea
From: Torsten Bögershausen
Make it safer to normalize the line endings in a repository:
Files that had been commited with CRLF will be commited with LF.
The old way to normalize a repo was like this:
# Make sure that there are not untracked files
$ echo "* text=auto" >.gitattributes
$ git rea
From: Torsten Bögershausen
Make it safer to normalize the line endings in a repository:
Files that had been commited with CRLF will be commited with LF.
(Unless core.autorclf and .gitattributes specify that Git
should not do line ending conversions)
The old way to normalize a repo was like this
From: Torsten Bögershausen
Some implementations of `echo` support the '-e' option to enable
backslash interpretation of the following string.
As an addition, they support '-E' to turn it off.
However, none of these are portable, POSIX doesn't even mention them,
and many implementations don't sup
From: Torsten Bögershausen
When a file had been commited with CRLF but now .gitattributes say
"* text=auto" (or core.autocrlf is true),
the following does not roundtrip, `git apply` fails:
printf "Added line\r\n" >>file &&
git diff >patch &&
git checkout -- . &&
git apply patch
Before applying
From: Torsten Bögershausen
When convert_to_git() is called, the caller may want to keep CRLF
to be kept as CRLF (and not converted into LF).
This will be used in the next commit, when apply works with files that have
CRLF and patches are applied onto these files.
Add the new value "SAFE_CRLF_KE
From: Torsten Bögershausen
When convert_to_git() is called, the caller may want to keep CRLF
to be kept as CRLF (and not converted into LF).
This will be used in the next commit, when apply works with files that have
CRLF and patches are applied onto these files.
Add the new value "SAFE_CRLF_KE
From: Torsten Bögershausen
When a file had been commited with CRLF but now .gitattributes say
"* text=auto" (or core.autocrlf is true),
the following does not roundtrip, `git apply` fails:
printf "Added line\r\n" >>file &&
git diff >patch &&
git checkout -- . &&
git apply patch
Before applying
From: Torsten Bögershausen
When convert_to_git() is called, the caller may want to keep CRLF
to be kept as CRLF (and not converted into LF).
This will be used in the next commit, when apply works with files that have
CRLF and patches are applied onto these files.
Add the new value "SAFE_CRLF_KE
From: Torsten Bögershausen
When a file had been commited with CRLF but now .gitattributes say
"* text=auto" (or core.autocrlf is true),
the following does not roundtrip, `git apply` fails:
printf "Added line\r\n" >>file &&
git diff >patch &&
git checkout -- . &&
git apply patch
Before applying
From: Torsten Bögershausen
When a file had been commited with CRLF and core.autocrlf is true,
the following does not roundtrip, `git apply` fails:
printf "Added line\r\n" >>file &&
git diff >patch &&
git checkout -- . &&
git apply patch
Before applying the patch, the file from working tree is c
From: Torsten Bögershausen
When convert_to_git() is called, the caller may want to keep CRLF
to be kept as CRLF (and not converted into LF).
This will be used in the next commit, when apply works with files that have
CRLF and patches are applied onto these files.
Add the new value "SAFE_CRLF_KE
From: Torsten Bögershausen
When convert_to_git() is called, the caller may want to keep CRLF
to be kept as CRLF (and not converted into LF).
This will be used in the next commit, when apply works with files that have
CRLF and patches are applied onto these files.
Add the new value "SAFE_CRLF_KE
From: Torsten Bögershausen
When a file had been commited with CRLF and core.autocrlf is true,
the following does not roundtrip, `git apply` fails:
printf "Added line\r\n" >>file &&
git diff >patch &&
git checkout -- . &&
git apply patch
Before applying the patch, the file from working tree is c
From: Torsten Bögershausen
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()
does not load the index, this does not work, CRLF are converted into LF
and apply fails.
Fix t
From: Torsten Bögershausen
cygwin can use an UNC path like //server/share/repo
$ cd //server/share/dir
$ mkdir test
$ cd test
$ git init --bare
However, when we try to push from a local Git repository to this repo,
there is a problem: Git converts the leading "//" into a single "/".
As
From: Torsten Bögershausen
cygwin can use an UNC path like //server/share/repo
$ cd //server/share/dir
$ mkdir test
$ cd test
$ git init --bare
However, when we try to push from a local Git repository to this repo,
there is a problem: Git converts the leading "//" into a single "/".
As
From: Torsten Bögershausen
In setup.c is_git_directory() checks a Git directory using access(X_OK).
This does not check, if path is a file or a directory.
Check path with is_directory() instead.
---
After all the discussions (and lots of tests) I found that this patch
works for my setup.
All in a
From: Torsten Bögershausen
cygwin can use an UNC path like //server/share/repo
$ cd //server/share/dir
$ mkdir test
$ cd test
$ git init --bare
However, when we try to push from a local Git repository to this repo,
there are 2 problems:
- Git converts the leading "//" into a single "/".
- The re
From: Torsten Bögershausen
The purpose of t0027 is to test all CRLF related conversions at "git checkout"
and "git add".
Running t0027 under Git for Windows takes 3-4 minutes, so the whole script had
been marked as "EXPENSIVE".
The source code for "Git for Windows" overrides this since 2014:
"t
From: Torsten Bögershausen
The purpose of t0027 is to test all CRLF related conversions at
"git checkout" and "git add".
Running t0027 under Git for Windows takes 3-4 minutes, so the whole script
had been marked as "EXPENSIVE".
The source code for "Git for Windows" overrides this since 2014:
"t
From: Torsten Bögershausen
The purpose of t0027 is to test all CRLF related conversions at
"git checkout" and "git add".
Running t0027 under Git for Windows takes 3-4 minutes, so the whole script
had been marked as "EXPENSIVE".
The source code for "Git for Windows" overrides this since 2014:
"t
From: Torsten Bögershausen
The instructions how to normalize the line endings should have been updated
as part of commit 6523728499e 'convert: unify the "auto" handling of CRLF',
(but that part never made it into the commit).
Update the documentation in Documentation/gitattributes.txt
and add a
From: Junio C Hamano
git diff --quiet may take a short-cut to see if a file is changed
in the working tree:
Whenever the file size differs from what is recorded in the index,
the file is assumed to be changed and git diff --quiet returns
exit with code 1
This shortcut must be suppressed whenever
From: Torsten Bögershausen
Working with a repo that used to be all CRLF. At some point it
was changed to all LF, with `text=auto` in .gitattributes.
Trying to cherry-pick a commit from before the switchover fails:
$ git cherry-pick -Xrenormalize
fatal: CRLF would be replaced by LF in [path]
From: Torsten Bögershausen
Working with a repo that used to be all CRLF. At some point it
was changed to all LF, with `text=auto` in .gitattributes.
Trying to cherry-pick a commit from before the switchover fails:
$ git cherry-pick -Xrenormalize
fatal: CRLF would be replaced by LF in [path]
From: Torsten Bögershausen
Sincec commit 6523728499e7 'convert: unify the "auto" handling of CRLF'
the normalization instruction in Documentation/gitattributes.txt
doesn't work any more.
Update the documentation and add a test case.
Reported by Kristian Adrup
https://github.com/git-for-windows/
From: Torsten Bögershausen
When statistics are done for the autocrlf handling, the search in
the content can be stopped, if e.g
- a search for binary is done, and a NUL character is found
- a search for CRLF is done, and the first CRLF is found.
Similar when statistics for binary vs non-binary a
From: Torsten Bögershausen
Factor out the retrieval of the sha1 for a given path in
read_blob_data_from_index() into the function get_sha1_from_index().
This will be used in the next commit, when convert.c can do the
analyze for "text=auto" without slurping the whole blob into memory
at once.
A
From: Torsten Bögershausen
Changes since v1:
- Rename earlyout into search_only
- Increase buffer from 2KiB to 16KiB
- s/mask/eol_bits/
- Reduce the "noise"
- Document "split gather_stats() into gather_all_stats()/gather_stats_partly()
Torsten Bögershausen (2):
read-cache: factor out get_sha1_
From: Torsten Bögershausen
Factor out the retrieval of the sha1 for a given path in
read_blob_data_from_index() into the function get_sha1_from_index().
This will be used in the next commit, when convert.c can do the
analyze for "text=auto" without slurping the whole blob into memory
at once.
A
From: Torsten Bögershausen
An optimization when autocrlf is used and the binary/text detection is run.
Or git ls-files --eol is run to analyze the content of files or blobs.
Torsten Bögershausen (2):
read-cache: factor out get_sha1_from_index() helper
convert.c: stream and early out
cache.
From: Torsten Bögershausen
When statistics are done for the autocrlf handling, the search in
the content can be stopped, if e.g
- a search for binary is done, and a NUL character is found
- a search for CRLF is done, and the first CRLF is found.
Similar when statistics for binary vs non-binary a
From: Torsten Bögershausen
Changes since v1:
- 1/2 is left unchanged
- 2/2 is re-written and should be more consistant to read.
Torsten Bögershausen (2):
git ls-files: text=auto eol=lf is supported in Git 2.10
gitattributes: Document the unified "auto" handling
Documentation/git-ls-files.t
From: Torsten Bögershausen
Update the documentation about text=auto:
text=auto now follows the core.autocrlf handling when files are not
normalized in the repository.
For a cross platform project recommend the usage of attributes for
line-ending conversions.
Signed-off-by: Torsten Bögershausen
From: Torsten Bögershausen
The man page for `git ls-files --eol` mentions the combination
of text attributes "text=auto eol=lf" or "text=auto eol=crlf" as not
supported yet, but may be in the future.
Now they are supported
Signed-off-by: Torsten Bögershausen
---
Documentation/git-ls-files.txt
From: Torsten Bögershausen
Sorry for posting this so late:
While reviewing another patch I realized that the eol related
documentation was not updated as it should be.
Torsten Bögershausen (2):
git ls-files: text=auto eol=lf is supported in Git 2.10
gitattributes: Document the unified "auto"
From: Torsten Bögershausen
The man page for `git ls-files --eol` mentions the combination
of text attributes "text=auto eol=lf" or "text=auto eol=crlf" as not
supported yet, but may be in the future.
Now they are supported
Signed-off-by: Torsten Bögershausen
---
Documentation/git-ls-files.txt
From: Torsten Bögershausen
Update the documentation about text=auto:
text=auto now follows the core.autocrlf handling when files are not
normalized in the repository.
For a cross platform project recommend the usage of attributes for
line-ending conversions.
Signed-off-by: Torsten Bögershausen
From: Torsten Bögershausen
Here comes the promised cleanup of t0027:
- The wording NNO is removed and replaced by CRI
- No code changes
- Needs to go on top of next or pu or tb/t0027-raciness-fix
Torsten Bögershausen (1):
t0027: Rename NotNormalized (NNO) into CRLF in index
t/t0027-auto-crlf.
From: Torsten Bögershausen
Originally NNO stands for content, that had been commited
"Not NOrmalized", in other words files with CRLF in the index.
Make more clear what should be tested:
- commit a file with CRLF into the index
- Change the content in the working tree
- Run "git add" and check f
1 - 100 of 242 matches
Mail list logo
