On Mon, May 13, 2019 at 04:17:25PM -0700, Elijah Newren wrote:
> The find_encoding() function returned the encoding used by a commit
> message, returning a default of git_commit_encoding (usually utf-8).
I think "UTF-8" is preferred over "utf-8".
Unless it is a function name like is_encoding_utf8()
On Mon, May 13, 2019 at 09:30:57PM -0700, Elijah Newren wrote:
> While stress testing `git filter-repo`, I noticed an issue with
> encoding; further digging led to the fixes and features in this series.
> See the individual commit messages for details.
>
No more comments from my side, thanks for t
On Sat, May 18, 2019 at 06:38:39PM +0200, Johannes Sixt wrote:
> Am 18.05.19 um 14:58 schrieb Ax Da:
> > You can rename files like this:
> > git mv File.txt file.txt
>
> On a case-insensitive, case-preserving filesystem, a case-only rename
> operation is better performed in two steps that do not ju
On Wed, Jun 12, 2019 at 12:48:00PM +0200, Alexander wrote:
> Hello,
>
> I am trying to checkout out various 3rd party Git projects on Linux
> and build them.
> Some of them have text files created under Windows with CRLF endings
> and it is not under my responsibility to change it.
>
> Thus I have
On Fri, Jul 05, 2019 at 01:35:13PM +0200, Mateusz Loskot wrote:
> Hi,
>
> Using git version 2.22.0.windows.1
>
> I have a repository with number of .txt files encoded in
> little-endian UTF-16 with BOM.
>
> What are the best practice and recommended configuration to
> manage such files with Git to
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(-)
>
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
>
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
> - '/**' mat
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
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
> streaw_blob_to_fd()
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.
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
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. Thanks
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 is
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
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 ki
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:
>
>
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 ?
>
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"
>
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 "/".
>&
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
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 w
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 size_
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
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 s
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
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 questio
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
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:
>
>
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, but
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 v0.5.
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 fi
> 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 c
[]
> 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 again.
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 the
(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`
>
> M
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 = git_conf
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
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 file
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 inserti
pend_cr >allcrlf &&
> + 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
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,
> overwritin
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 bc8ff8aec33836af3fefe1bcd3f533a1486
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
--- a/t/t5
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" &&
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) &&
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 does pa
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:
>
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 &&
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 Windows
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 conv
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,
On Wed, Feb 06, 2019 at 02:52:53PM +0100, Johannes Schindelin wrote:
> Hi Gábor,
>
> On Wed, 6 Feb 2019, SZEDER Gábor wrote:
>
> > On Wed, Feb 06, 2019 at 11:25:38AM +0100, Johannes Schindelin wrote:
> >
> > > at first I thought that those intermittent test failures were limited
> > > to Windows, b
On Wed, Feb 06, 2019 at 09:00:22PM -0500, Jeff King wrote:
> On Wed, Feb 06, 2019 at 11:42:43AM +0100, SZEDER Gábor wrote:
>
> > I reported this and Peff looked into it on the way to Git Merge, but
> > not working solution yet.
> >
> > https://public-inbox.org/git/20190129225121.gd1...@sigill.intra
On Fri, Feb 08, 2019 at 04:18:23PM +0100, Giuseppe Crinò wrote:
> OK, I successfully built git on Windows (thanks Johannes!) and I'm now able
> to run it.
>
> As of 9f16cdd I can successfully reproduce the bug.
>
> Interestingly enough, I can reproduce the bug even for /usr/bin/git running
> insi
On 08.02.19 07:04, Rich Felker wrote:
> On Fri, Feb 08, 2019 at 12:17:05AM +, brian m. carlson wrote:
[]
>> Even if Git were to produce a BOM to work around this issue, then we'd
>> still have the problem that any program using musl will write data in
>> UTF-16 without a BOM. Moreover, because
On Sat, Feb 09, 2019 at 08:08:01PM +, brian m. carlson wrote:
> When serializing UTF-16 (and UTF-32), there are three possible ways to
> write the stream. One can write the data with a BOM in either big-endian
> or little-endian format, or one can write the data without a BOM in
> big-endian fo
On Sat, Mar 09, 2019 at 09:36:34AM -0500, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm experiencing a failure in t0028-working-tree-encoding.sh. The
> first failure is test #3. The source states "source (test.utf16lebom,
> considered UTF-16LE-BOM)" but it looks like a UTF16-LE BOM followed by
> a U
On Sat, Mar 09, 2019 at 08:57:07PM -0500, Jeffrey Walton wrote:
> On Sat, Mar 9, 2019 at 11:10 AM Torsten Bögershausen wrote:
> >
> > On Sat, Mar 09, 2019 at 09:36:34AM -0500, Jeffrey Walton wrote:
> > >
> > > I'm experiencing a failure in t0028-working-tre
On Mon, Mar 11, 2019 at 06:48:11PM +0100, Johannes Sixt wrote:
> Am 10.03.19 um 23:41 schrieb Anthony Sottile:
> > git init longname-repo
> > cd longname-repo
> > touch f
> > git add ..\longna~1\f
> >
> ...
> >
> > C:\Users\Anthony\AppData\Local\Temp\t\pre-commit-hooks\longname-repo>git
> > add ..\
On Mon, Mar 18, 2019 at 08:35:26AM -0400, Jeff Hostetler wrote:
>
>
> On 3/16/2019 6:47 AM, tbo...@web.de wrote:
> > From: Torsten Bögershausen
> >
> > Some compilers don't allow NULL to be passed for a va_list.
> > Use va_list instead.
> >
> > S
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
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&view=logs
> >
>
> [jc:
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 information,
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 no
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
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 no
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 file
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
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 f
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" &&
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, a
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 b
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
On Wed, Aug 07, 2019 at 01:08:22PM +, Yagnatinsky, Mark wrote:
> I hope this is the right mailing list, hope someone will redirect me if not...
Yes, you are at the right place, wellcome to the Git community.
> The git documentation (git help config) for core.autocrlf doesn't mention
> that f
On Thu, Aug 08, 2019 at 11:08:14PM +, Yagnatinsky, Mark wrote:
> Okay, my attempt at better wording for the docs is not going well, because it
> turns I that I still don't understand the behavior here!
> I thought that "input" means that CRLF will become LF on "git add" but that
> seems to be
On Fri, Aug 09, 2019 at 03:34:05PM +, Yagnatinsky, Mark wrote:
> After correcting spelling of renormalize, the end result of the script you
> gave is that line endings in working directory are CRLF,
> and in the repo are LF.
> Is that expected?
Yes. "git add" does typically not touch the file
On Mon, Aug 12, 2019 at 01:47:18PM +, Yagnatinsky, Mark wrote:
> Wait a second... suppose a file is committed with CRLF line endings.
> You're saying that even if I have autocrlf set to "input" or "auto", the file
> will never get "converted" to LF format unless I explicitly renormalize?
Yes.
On Mon, Aug 12, 2019 at 11:18:35AM -0700, Junio C Hamano wrote:
> "Yagnatinsky, Mark" writes:
>
> > ... Assuming the repo has no .gitattributes,
> > is it possible to predict what line endings sample.txt will end up with in
> > my repo?
> > Or does it depend on more information than what I've ju
On Tue, Aug 13, 2019 at 03:31:43PM +, Yagnatinsky, Mark wrote:
> Thank you once more. Finally, I believe I understood everything you said.
> I was about to say that this contradicts my own experience.
> But then I remembered that I normally use my IDE rather than the command line.
> And I just
On Thu, Aug 15, 2019 at 04:56:05AM +, Yagnatinsky, Mark wrote:
> Okay, first attempt at better phrasing. This may need more paragraph breaks,
> or something.
> Right now it's very wall-of-texty. And probably in a style way too different
> from the rest of the git docs.
> Also, the syntax is
On Mon, Sep 23, 2019 at 03:04:19AM -0700, Alexandr Miloslavskiy via
GitGitGadget wrote:
> From: Alexandr Miloslavskiy
>
> According to its name, the test is designed for UTF-16-LE-BOM.
> However, possibly due to copy&paste oversight, it was using UTF-32 file.
>
> While the test succeeds (probably
On Mon, Sep 23, 2019 at 03:04:19AM -0700, Alexandr Miloslavskiy via
GitGitGadget wrote:
> From: Alexandr Miloslavskiy
Thanks for the tests, some nit-picks inline.
>
> After I discovered that UTF-16-LE-BOM test was bugged and still
> succeeded...
My interpretation is that the \000\000 must be h
ix test for UTF-16-LE-BOM
> t0028: add more tests
>
Thanks for the update -
Reviewed-by: Torsten Bögershausen
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 repo would checkout correc
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
> interpreted as binary and con
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 ri
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 endin
On Wed, Nov 22, 2017 at 11:01:22AM +0900, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
> >> I want to have LF line endings in the repository and CRLF endings in
> >> the working copy. (Because I use windows-exclusive tools to develop.)
> >
> > Side
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
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.
x27; is found,
> > 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
> > ---
> > diff --git a/convert.c b/convert.c
> > @@ -220,18 +220,27
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 does
>> not use CRLF as
> * 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
On Fri, Dec 08, 2017 at 10:21:19AM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > tbo...@web.de writes:
> >
> >> From: Torsten Bögershausen
> >>
> >> Replace `git commit -m "comment" ""` with `git commit -m "
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 +
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 to process the text (e.g. vi
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 all other encodings, too,
> >
On Fri, Dec 22, 2017 at 01:07:59PM -0800, Junio C Hamano wrote:
> tbo...@web.de writes:
>
> >
> > Reviewed-by: Johannes Schindelin
> > Signed-off-by: Torsten Bögershausen
>
> I'll flip these and add a helped-by to credit Eric.
...
> Don't tr
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,
401 - 500 of 1315 matches
Mail list logo
