feedback on that idea.
>
[]
>
> Torsten Bögershausen ebb8d2c9 mingw: support UNC in git clone
> file://server/share/repo
> connect.c
> ebb8d2c9 921) path = host - 2; /* include the leading "//" */
>
I actually looked into this one, and my understanding is that t
ix test for UTF-16-LE-BOM
> t0028: add more tests
>
Thanks for the update -
Reviewed-by: Torsten Bögershausen
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
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
/path as a UNC
path.]
This closes https://github.com/git-for-windows/git/issues/1264.
Signed-off-by: Torsten Bögershausen
Signed-off-by: Johannes Schindelin
---
connect.c | 4
t/t5500-fetch-pack.sh | 13 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff
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 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 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 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 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 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 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 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 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 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 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 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 04:17:24PM -0700, Elijah Newren wrote:
> When fast-export encounters a commit with an 'encoding' header, it tries
> to reencode in utf-8 and then drops the encoding header. However, if it
> fails to reencode in utf-8 because e.g. one of the characters in the
> commit messag
On Mon, May 13, 2019 at 04:17:22PM -0700, Elijah Newren wrote:
> This test used an author with non-ascii characters in the name, but
> no special commit message. It then grep'ed for those non-ascii
> characters, but those are guaranteed to exist regardless of the
> reencoding process since the ree
On Mon, May 13, 2019 at 12:23:29PM +0200, Johannes Schindelin wrote:
> Hi Elijah,
>
> On Sat, 11 May 2019, Elijah Newren wrote:
>
> > [...] the craziness is based on how Windows behaves; it seems insane to
> > me that Windows decides to munge user data (in the form of the command
> > line provided)
On Fri, May 10, 2019 at 01:53:35PM -0700, Elijah Newren wrote:
> Automatic re-encoding of commit messages (and dropping of the encoding
> header) hurts attempts to do reversible history rewrites (e.g. sha1sum
> <-> sha256sum transitions, some subtree rewrites), and seems
> inconsistent with the gen
On Fri, May 10, 2019 at 12:23:28AM +0100, Philip Oakley wrote:
> Hi,
>
> Is there a mechanism for exchanging the rerere resolutions, so that future
> fixups, e.g. future clashes on pu rather than master, can be sent with patch
> series?
>
> My current use case that there is a large patch [1] for up
at patch 1/2 is in upstream Git,
and even in git-for-windows/master - on which codebase are you ?
commit e6e15194a85af68db9f9ce076eb32c47e7063b3c
gitattributes.txt: fix typo
`UTF-16-LE-BOM` to `UTF-16LE-BOM`.
this closes https://github.com/git-for-windows/git/issues/2095
Signed-off
On Fri, Apr 19, 2019 at 09:28:32PM +0200, Ax Da wrote:
>
> We're working on Windows machines and have been experiencing issues with the
> current implementation of Git with config setting "core.ignorecase = true"
> (which is the default on Windows machines and repositories created on Windows
> m
On Tue, Apr 23, 2019 at 10:30:56AM -0700, Elijah Newren wrote:
> On Mac's HFS ("Hilarious FileSystem"? "Halfwitted FileSystem"?) --
How about "Hierarchical File System" ?
> where git sets core.precomposeUnicode to true automatically by git
> init/clone -- when a user creates a simple unicode ref
On 2019-04-09 18:46, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>>> 1cadad6f6 removes mingw_offset_1st_component from mingw.c which is
>>> included by msvc.c. Then the in git-compat.h the new file
>>> "compat/win32/path-utils.h" is only
On 2019-04-09 09:34, Sven Strickroth wrote:
> Am 09.04.2019 um 07:53 schrieb Torsten Bögershausen:
>>> Regression was introduced in commit
>>> 25d90d1cb72ce51407324259516843406142fe89.
>>
>> Was it ?
>> 25d90d1cb merged this commit:
>> 1cadad6f6 (
On 2019-04-08 21:36, Matheus Tavares Bernardino wrote:
> On Mon, Apr 8, 2019 at 4:19 PM Philip Oakley wrote:
>>
>> Hi Matheus
>>
>> On 08/04/2019 18:04, Matheus Tavares Bernardino wrote:
Another "32-bit problem" should also be expressly considered during the
GSoC work because of the MS W
On 2019-04-08 13:16, Sven Strickroth wrote:
> A path such as 'c:/somepath/submodule/../.git/modules/submodule' wasn't
> resolved correctly any more, because the *nix variant of
> offset_1st_component is used instead of the Win32 specific version.
>
> Regression was introduced in commit
> 25d90d1cb7
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
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 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 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, 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 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 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 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 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 Fri, Feb 01, 2019 at 10:02:50AM +0200, Angelo Melonas wrote:
> Hi Torsten,
>
> Thank you so much for getting back to me.
>
> Unfortunately, I believe there is a misunderstanding, as I may have
> explained what I found to be a possible bug incorrectly.
> The file that is originally added (and the
On Thu, Jan 31, 2019 at 06:59:17PM +0100, Thomas Braun wrote:
> > Junio C Hamano hat am 29. Januar 2019 um 23:15
> > geschrieben:
>
> [...]
>
> > * mk/use-size-t-in-zlib (2018-10-15) 1 commit
> > - zlib.c: use size_t for size
> >
> > The wrapper to call into zlib followed our long tradition to
On Thu, Jan 31, 2019 at 09:29:28AM +0200, Angelo Melonas wrote:
> Just to clarify, I made a mistake above. Instead of "untracked", I
> meant "unstaged".
> I apologise for the confusion.
>
> On Thu, Jan 31, 2019 at 9:01 AM Angelo Melonas
> wrote:
> >
> > Good day,
> >
> > I found a potential bug i
On Wed, Jan 30, 2019 at 10:24:44AM -0500, Jason Pyeron wrote:
> > -Original Message-
> > From: git-ow...@vger.kernel.org On Behalf Of
> > tbo...@web.de
> > Sent: Wednesday, January 30, 2019 10:02 AM
> > To: git@vger.kernel.org; adrigi...@gmail.com
> > C
On Mon, Jan 28, 2019 at 01:31:17PM -0500, Jeff King wrote:
> On Mon, Jan 28, 2019 at 09:12:00PM +0300, Sergey Lukashev wrote:
>
> > Thank you. Does the paragraph about core.eol refers to the text
> > attribute? It's written 'property' there. I was thinking it means
> > whether git thinks file is te
On Mon, Jan 28, 2019 at 02:43:21PM -0800, Junio C Hamano wrote:
>
> * tb/utf-16-le-with-explicit-bom (2019-01-22) 1 commit
> - Support working-tree-encoding "UTF-16LE-BOM"
>
> A new encoding UTF-16LE-BOM has been invented to force encoding to
> UTF-16 with BOM in little endian byte order, whic
On Sun, Jan 27, 2019 at 02:55:23PM +0300, Sergey Lukashev wrote:
> A follow up on my previous mail.
>
> Well, I have two problems:
> 1) The endings I get with core.autocrlf=false depend on whether I have *
> text=auto (a file was commited with LFs). At least in git 2.20.1
> 2) If the quote holds t
On Wed, Jan 23, 2019 at 09:54:25AM -0800, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
> >> I'd still prefer to see a more terse[1] (and not capitalized) message
> >> to be consistent with existing error messages and to keep the reported
> >> er
On 22.01.19 22:15, Eric Sunshine wrote:
> On Tue, Jan 22, 2019 at 3:00 PM Torsten Bögershausen wrote:
>> On 22.01.19 20:47, Junio C Hamano wrote:
>>> tbo...@web.de writes:
>>>> -/\bsed\s+-i/ and err 'sed -i is not portable';
>>>> +/\bsed
On 22.01.19 20:47, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> 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 operatin
On 17.01.19 17:27, Jeff King wrote:
> On Thu, Jan 17, 2019 at 06:22:05PM +0300, Dmitriy Smirnov wrote:
>
>> Calling `git add —ignore-errors` appears to be equal to calling `git add
>> —renormalize`:
>>
>> Main.java is saved with CRLF in repo
>> git config core.autocrlf = input
>>
>> $ src git:(ma
On 16.01.19 22:46, Thomas Braun wrote:
> Am 20.11.2018 um 06:04 schrieb tbo...@web.de:
>
> I'm interested in helping getting this forward!
>
>> What we really need for this patch to fly are this branches:
>> mk/use-size-t-in-zlib
>
> In pu.
Junio, is that branch ready for master ?
>
>> tb/print-s
On 10.01.19 12:57, SZEDER Gábor wrote:
> On Thu, Jan 10, 2019 at 11:28:34AM +0800, Jiang Xin wrote:
>> SZEDER Gábor 于2019年1月9日周三 下午8:56写道：
+ sed -e "s#^.*/pack-\(.*\)\.\(idx\|pack\)#\1#g" | \
>>>
>>> This sed command doesn't seem to work on macOS (on Travis CI), and
>>> causes the
On Wed, Dec 26, 2018 at 06:52:56PM -0800, Alexandre Grigoriev wrote:
>
> > -Original Message-
> > From: brian m. carlson [mailto:sand...@crustytoothpaste.net]
> > Sent: Wednesday, December 26, 2018 11:25 AM
> > To: Alexandre Grigoriev
> > Cc: '
Should it be
s/respect core.fileMode/respect core.ignoreCase/
in the header line ?
IIUC won't do nothing for older commits - so checking out a commit
> before the fix one, ghit will see this file as changed and then
> completely refuse to go back to another branch
>
> This seems a bug - as illegal as the state of the file is, shouldn't
> git reset always
On Fri, Dec 14, 2018 at 04:04:15PM -0500, Mr&Mrs D wrote:
> Hi all,
>
> I maintain a python project you can clone from:
>
> g...@github.com:wrye-bash/wrye-bash.git
>
> For reasons unknown git sees a particular file as changed
> (Mopy/Docs/Bash Readme Template.html, sometimes others too). This fi
>
> Can you please replace the rather unnecessary, very, very long
> `win_path_utils_` function name prefix by the much better prefix `win32_`,
> to keep in line with the current, already existing, surrounding files'
> convention? Thanks a bunch.
>
That makes sense - thanks for the suggestion &
On Mon, Dec 10, 2018 at 09:32:03AM +0100, Johannes Schindelin wrote:
> Hi Torsten,
>
> On Sat, 8 Dec 2018, tbo...@web.de wrote:
>
> > And, before any cleanup is done, I sould like to ask if anybody
> > can build the code with VS and confirm that it works, please ?
>
> Can you give me an easy-to-
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.
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 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:
>
>
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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()
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 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
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 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 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
[]
> 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.
> 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
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
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 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 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 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 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 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 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 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 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 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 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 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:
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
1 - 100 of 1315 matches
Mail list logo
