Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

On Sun, Jan 08, 2017 at 08:17:36PM +0100, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > Some `clean` / `smudge` filters might require a significant amount of > time to process a single blob. During this process the Git checkout > operation is blocked and

Re: [GSoC][PATCH v4] t2027: avoid using pipes

On 24/03/17 09:27, Prathamesh Chavan wrote: From: Prathamesh Welcome to Git. The name in the "From:" must match the name in the sign-off: git config --global user.name "Prathamesh Chavan" Signed-off-by: Prathamesh Chavan The patch looks good

Re: [PATCH v2 1/2] pkt-line: add packet_writel() and packet_read_line_gently()

On 2017-03-24 16:27, Ben Peart wrote: > Add packet_writel() which writes multiple lines in a single call and > then calls packet_flush_gently(). Add packet_read_line_gently() to > enable reading a line without dying on EOF. > > Signed-off-by: Ben Peart > --- > pkt-line.c

t1503 broken ?

./t1305-config-include.sh seems to be broken: not ok 19 - conditional include, $HOME expansion not ok 21 - conditional include, relative path Both Mac and Linux. The problem seems to be the line git config test.two >actual && and git config test.four >actual && In both cases the config

Re: [PATCH v2 1/2] pkt-line: add packet_writel() and packet_read_line_gently()

[snip] Would packet_write_lines make more sense ? Just goes to prove that there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. :) The feedback on V1 was: "I am hesitant to take a function that does not take any "list" type argument and

Re: [PATCH v2 1/2] pkt-line: add packet_writel() and packet_read_line_gently()

On 30.03.17 18:01, Ben Peart wrote: >> From: Torsten Bögershausen [mailto:tbo...@web.de] >> >> >> Does this work ? >> I would have expected >> packet_writel(fd, "line one", "line two", "line n"), NULL; Typo. Should h

Re: t1503 broken ?

On 03/25/2017 02:05 PM, Duy Nguyen wrote: On Sat, Mar 25, 2017 at 07:26:14PM +0700, Duy Nguyen wrote: On Sat, Mar 25, 2017 at 6:46 PM, Duy Nguyen <pclo...@gmail.com> wrote: On Sat, Mar 25, 2017 at 5:46 PM, Torsten Bögershausen <tbo...@web.de> wrote: ./t1305-config-incl

Re: [BUG?] iconv used as textconv, and spurious ^M on added lines on Windows

On 30.03.17 21:35, Jakub Narębski wrote: > Hello, > > Recently I had to work on a project which uses legacy 8-bit encoding > (namely cp1250 encoding) instead of utf-8 for text files (LaTeX > documents). My terminal, that is Git Bash from Git for Windows is set > up for utf-8. > > I wanted for

Re: File names are considered case insensitive in a folder. (aBcd.py ==AbcD.py) Inbox x

On 17/03/17 10:28, Vish Gite wrote: Hello, Git 2.10.1 on Apple mac is treating different(uppercase/lowercase) files as same name(e.g ABCD.py and abcd.py) In a project where file name is same but case is different, either ABCD.py or abcd.py. There is always one of these files is modified.

Re: Commiting files larger than 4 GB on Windows

On 2017-03-15 17:13, Jeff King wrote: > On Wed, Mar 15, 2017 at 11:59:52AM -0400, Jeff King wrote: > >> I agree that detecting the situation in the meantime is a good idea. >> The patch above probably handles the bulk-checkin code path, I'd guess. >> It might be nice to have similar checks in

Re: Commiting files larger than 4 GB on Windows

On 15/03/17 22:29, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: The real "show stopper" is at the end. ... == And it seams as if zlib is the limitation here. Unless we include the zlib source code into Git and redefine uLong, is

Re: [PATCH v4] http.postbuffer: allow full range of ssize_t values

On 03.04.17 19:30, David Turner wrote: > Unfortunately, in order to push some large repos, the http postbuffer > must sometimes exceed two gigabytes. On a 64-bit system, this is OK: > we just malloc a larger buffer. > > This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the >

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

On 2017-04-09 21:11, Lars Schneider wrote: [] > + > +packet: git> command=smudge > +packet: git> pathname=path/testfile.dat > +packet: git> delay-able=1 > +packet: git> > +packet: git> CONTENT > +packet: git> >

Re: [BUG?] iconv used as textconv, and spurious ^M on added lines on Windows

On 2017-03-31 21:44, Jakub Narębski wrote: > W dniu 31.03.2017 o 14:38, Torsten Bögershausen pisze: >> On 30.03.17 21:35, Jakub Narębski wrote: >>> Hello, >>> >>> Recently I had to work on a project which uses legacy 8-bit encoding >>> (namely cp1

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

On 2017-04-11 21:50, Lars Schneider wrote: [] >> packet: git> command=smudge >> packet: git> pathname=path/testfile.dat >> packet: git> delay-id=1 >> packet: git> >> packet: git> CONTENT >> packet: git> >> packet: git<

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

I think I meant to write "big pidfiles" there. With xsize_t() gc would die when seeing a pidfile whose size doesn't fit into size_t. The version I sent just ignores such files. However, it would choke on slightly smaller files that happen to not fit into memory. And no reasonable pidfile

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

On 2017-04-19 22:02, René Scharfe wrote: > Am 19.04.2017 um 21:09 schrieb Torsten Bögershausen: >> On 2017-04-19 19:28, René Scharfe wrote: >> [] >> One or two minor comments inline >>> diff --git a/builtin/gc.c b/builtin/gc.c >>> index 2daede7820..4

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

On 2017-04-19 19:28, René Scharfe wrote: [] One or two minor comments inline > diff --git a/builtin/gc.c b/builtin/gc.c > index 2daede7820..4c1c01e87d 100644 > --- a/builtin/gc.c > +++ b/builtin/gc.c > @@ -228,21 +228,99 @@ static int need_to_gc(void) > return 1; > } > > +struct pidfile {

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

>> (Back to the roots) >> Which criteria do you have in mind: When should a filter process the blob >> and return it immediately, and when would it respond "delayed" ? > > See above: it's up to the filter. In case of Git LFS: delay if a network call > is required. > That make sense. I try to

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

Understood, thanks for the explanation. quiet is not quite any more.. Does the following fix help ? --- a/diff.c +++ b/diff.c @@ -2826,6 +2826,8 @@ int diff_populate_filespec(struct diff_filespec *s, unsigned int flags) enum safe_crlf crlf_warn = (safe_crlf == SAFE_CRLF_FAIL

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On 2017-03-03 18:47, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> Understood, thanks for the explanation. >> >> quiet is not quite any more.. >> >> Does the following fix help ? >> >> --- a/diff.c >> +++

Re: Git download

On 03/05/2017 09:26 PM, Cory Kilpatrick wrote: I have downloaded Git and cannot find the application on my Mac. Should I try to download it again? I don't think so. It could be helpful if we can get some more information: - Could you open the terminal application and type which git git

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

d" will not do any changes to the index, and >> "git diff -quiet" should exit 0. >> >> Add calls to would_convert_to_git() before blindly saying that a different >> size means different content. >> >> Reported-By: Mike Crowe <m...@mcrowe.com> &g

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On 2017-03-02 15:20, Mike Crowe wrote: > ll the solutions presented so far do cause a small change in behaviour > when using git diff --quiet: they may now cause warning messages like: > > warning: CRLF will be replaced by LF in crlf.txt. > The file will have its original line endings in your

Re: [PATCH v2 1/8] ref-filter: avoid using `unsigned long` for catch-all data type

On 02/04/17 21:06, Johannes Schindelin wrote: In its `atom_value` struct, the ref-filter source code wants to store different values in a field called `ul` (for `unsigned long`), e.g. timestamps. However, as we are about to switch the data type of timestamps away from `unsigned long` (because

Re: [PATCH v2 4/8] Specify explicitly where we parse timestamps

[] --- a/git-compat-util.h +++ b/git-compat-util.h @@ -319,6 +319,8 @@ extern char *gitdirname(char *); #define PRIo32 "o" #endif +#define parse_timestamp strtoul + Would #define parse_timestamp(a,b,c) strtoul((a),(b),(c)) be more strict ?

Re: [PATCH] http.postbuffer: make a size_t

On 30/03/17 22:29, David Turner wrote: Unfortunately, in order to push some large repos, the http postbuffer must sometimes exceed two gigabytes. On a 64-bit system, this is OK: we just malloc a larger buffer. Signed-off-by: David Turner --- cache.h | 1 + config.c

Re: t0025 flaky on OSX

On 2017-04-24 18:45, Lars Schneider wrote: > Hi, > > "t0025.3 - crlf=true causes a CRLF file to be normalized" failed > sporadically on next and master recently: > https://travis-ci.org/git/git/jobs/225084459#L2382 > https://travis-ci.org/git/git/jobs/223830505#L2342 > > Are you aware of a

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

On 08/01/2017 08:24 PM, Anthony Sottile wrote: Here's my minimal reproduction -- it's slightly far-fetched in that it involves*committing crlf* and then using `autocrlf=true` (commit lf, check out crlf). ``` #!/bin/bash set -ex rm -rf foo git init foo cd foo # Commit crlf into repository

Re: [PATCH 1/5] convert: initialize attr_action in convert_attrs

On Tue, Aug 15, 2017 at 02:53:01PM +0200, Martin Ågren wrote: > convert_attrs populates a struct conv_attrs. The field attr_action is > not set in all code paths, but still one caller unconditionally reads > it. Since git_check_attr always returns the same value, we'll always end > up in the same

Re: [PATCH 1/5] convert: initialize attr_action in convert_attrs

> > diff --git a/convert.c b/convert.c > > index 1012462e3..943d957b4 100644 > > --- a/convert.c > > +++ b/convert.c > > @@ -1040,7 +1040,6 @@ static void convert_attrs(struct conv_attrs *ca, > > const char *path) > > ca->crlf_action = git_path_check_crlf(ccheck + 4); > >

Re: Bug with ignorecase on Git and Cygwin

On Wed, Aug 16, 2017 at 11:50:47AM +, CHEVALLIER Yves wrote: > Hi, > > On Cygwin, the config value `ignorecase` is set to `true` during `git init` > and it is not possible to change the default value using templates. > > The issue was discovered while I was tracking a bunch of source

Re: [PATCH 1/9] Convert pack-objects to size_t

On Mon, Aug 14, 2017 at 08:31:50PM +0100, Ramsay Jones wrote: > > > On 14/08/17 18:08, Junio C Hamano wrote: > > Junio C Hamano writes: > > > >> One interesting question is which of these two types we should use > >> for the size of objects Git uses. > >> > >> Most of the

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

>I left it unsaid by mistake, but I think the right thing to use as >the "previous" to take hint from in the context of "git apply" is >what is in the working tree, i.e. the result of applying patch in >step (4) to create a file F in the sample scenario. >While applying patch in step (5),

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

Test from mutt

Re: [PATCH 1/9] Convert pack-objects to size_t

Thanks for working on this - unfortunatly the patch does not apply on git.git/master. Which baseline did you use ?

Re: [BUG] git am sometimes unable to apply git format-patch output file

On Sat, Aug 12, 2017 at 06:20:23PM +0200, Torsten Bögershausen wrote: > On Sat, Aug 12, 2017 at 07:02:59PM +0300, Soul Trace wrote: > > Hello. > > > > Using git i have found that git am command may sometimes fail to apply patch > > file which was created by the git am c

Re: [BUG] git am sometimes unable to apply git format-patch output file

On Sat, Aug 12, 2017 at 07:02:59PM +0300, Soul Trace wrote: > Hello. > > Using git i have found that git am command may sometimes fail to apply patch > file which was created by the git am command. > > > Steps to reproduce: Excellent, thanks so much for the detailed bug report. This kind of

Re: [PATCH/FIXUP 6/2] apply: clarify read_old_data() is about no-index case

On Wed, Aug 16, 2017 at 11:34:45AM -0700, Junio C Hamano wrote: > With the previous fixes to CRLF handling in place, read_old_data() > knows what it wants convert_to_git() to do with respect to CRLF. In > fact, this codepath is about applying a patch to a file in the > filesystem, which may not

Re: [PATCH 1/9] Convert pack-objects to size_t

On Wed, Aug 16, 2017 at 10:22:39PM +0200, Martin Koegler wrote: > On Mon, Aug 14, 2017 at 10:08:05AM -0700, Junio C Hamano wrote: > >It may help reducing the maintenance if we introduced obj_size_t > >that is defined to be size_t for now, so that we can later swap > >it to ofs_t or

Re: [PATCH/FIXUP 6/2] apply: clarify read_old_data() is about no-index case

On Thu, Aug 17, 2017 at 12:12:36AM -0700, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > > > Unless we re-define the meaning of "NULL" into "don't do CRLF conversions, > > like SAFE_CRLF_KEEP_CRLF does. > > My preference is not

Re: Git on macOS shows committed files as untracked

On 14/07/17 06:49, Lutz Roeder wrote: Using precomposeunicode still reproduces the issue: Repro steps: 1. Download https://www.dropbox.com/s/0q5pbpqpckwzj7b/gitstatusrepro.zip?dl=0 2. unzip gitstatusrepro.zip && cd gitstatusrepro 3. git reset --hard 4. git -c core.precomposeunicode=true

Re: Git on macOS shows committed files as untracked

ok strange The "box" with 04142F: Code point 4142F is unassigned and is outside any currently defined block range. So this is not valid Unicode, so we have a problem here under MacOS - not much Git can do about it. On Fri, Jul 14, 2017 at 4:41 AM, Torsten Bögershausen <tbo...@web.de

Re: Weirdness with git change detection

On 11/07/17 01:45, Peter Eckersley wrote: I have a local git repo that's in some weird state where changes appear to be detected by "git diff" and prevent operations like "git checkout" from switching branches, but those changes are not removed by a "git reset --hard" or "git stash". Here's

Re: Weirdness with git change detection

On 11/07/17 09:34, Jeff King wrote: On Tue, Jul 11, 2017 at 12:31:25AM -0700, Peter Eckersley wrote: I did try to test that hypothesis by editing the filter to be a no-op, but it's possible I go that wrong. My apologies for bugging the list! Actually I like this kind of feedback, to see

Re: Git on macOS shows committed files as untracked

On 13/07/17 01:15, Jeff King wrote: On Wed, Jul 12, 2017 at 06:21:28PM -0400, roeder@mailnull.com wrote: In Git on macOS (git version 2.13.2 | brew install git) the status command will show folders as untracked even though they are committed and checked out from the repository. Does not

Re: Bug with automated processing of git status results

On 30/06/17 11:09, Matthieu Moy wrote: Сергей Шестаков writes: I understand that we can turn off core.safecrlf, but it's inconvinient. Note that you can do that without actually changing the config file: git -c core.safecrlf=false status ... Beside that, I

Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)

On 01/07/17 09:39, Ævar Arnfjörð Bjarmason wrote: On Fri, Jun 30 2017, Junio C. Hamano jotted: * xz/send-email-batch-size (2017-05-23) 1 commit - send-email: --batch-size to work around some SMTP server limit "git send-email" learned to overcome some SMTP server limitation that does

Re: [PATCH] status: suppress additional warning output in plumbing modes

>On 30/06/17 18:28, Stefan Beller wrote: The patch makes a lot of sense - thanks for the fast reply. A question: does the header correspond to the patch ? < [PATCH] status: suppress additional warning output in plumbing modes > [PATCH] status: suppress CRLF warnings in porcelain modes (And

Re: Help needed for solving a few issues with building git

On 2017-07-03 15:18, Kaartic Sivaraam wrote: > Hello all, > > Building without localization support > > I tried to build git from source without localization support by adding > the following line to the Makefile, > > NO_GETTEXT=1 > May be make

Re: t0025 flaky on OSX

So all in all it seams as if there is a very old race condition here, which we "never" have seen yet. Moving the file to a different inode number fixes the test case, Git doesn't treat it as unchanged any more. Thanks a lot for investigating this! Would you mind posting the fix as patch?

Re: [PATCH] test-lib: abort when can't remove trash directory

[] - cd "$(dirname "$remove_trash")" && - rm -rf "$(basename "$remove_trash")" || - error "Tests passed but test cleanup failed; aborting" + cd "$(dirname "$TRASH_DIRECTORY")" && + rm -fr "$TRASH_DIRECTORY" ||

Re: t0025 flaky on OSX

On 2017-04-24 19:00, Torsten Bögershausen wrote: > On 2017-04-24 18:45, Lars Schneider wrote: >> Hi, >> >> "t0025.3 - crlf=true causes a CRLF file to be normalized" failed >> sporadically on next and master recently: >> https://travis-ci.org/git/git/jo

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

On 2017-04-30 09:53, René Scharfe wrote: > Am 30.04.2017 um 07:31 schrieb Torsten Bögershausen: >> Sorry, I was not looking careful enough, the macro `$GIT_UNZIP` >> gave the impression that an unzip provided by Git (or the Git test >> framework) was used :-( >> >>

Re: Bug: Git rename does not work if folder naming was changed from lower to upper case on OSX

after having committed folders with lower case naming, I decided to rename them to upper-case names. Expecting git to detect them as renamings, it started a new parallel hierarchy with new files, which I had to add/commit. It was a kinda strange behavior, which I fixed by rename the folder to

Re: [PATCH v1 1/1] correct apply for files commited with CRLF

On 08/02/2017 11:13 PM, Junio C Hamano wrote: tbo...@web.de writes: From: Torsten Bögershausen <tbo...@web.de> 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(

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

On 08/01/2017 10:58 PM, Anthony Sottile wrote: Here's where I'm hitting the problem described: https://github.com/pre-commit/pre-commit/issues/570 Note that `git -c core.autocrlf=false` apply patch fixes this situation, but breaks others. [] I wasn't thinking of that - and thanks for the

Re: [Patch size_t V3 01/19] delta: fix enconding size larger than an "uint" can hold

On Wed, Aug 16, 2017 at 10:16:13PM +0200, Martin Koegler wrote: > From: Martin Koegler > > The current delta code produces incorrect pack objects for files > 4GB. This may need a little bit more info (E.g. it does not fix anything on a 32 bit Linux) How about this:

Re: [Patch size_t V3 00/19] use size_t

On Wed, Aug 16, 2017 at 10:16:12PM +0200, Martin Koegler wrote: > From: Martin Koegler > > This patchset is for next [24db08a6e8fed761d3bace7f2d5997806e20b9f7]. I applied it succesfully, and run the test suite on a 32 bit system. The Laptop reported one brekage in

Re: What's cooking in git.git (Aug 2017, #04; Fri, 18)

> * tb/apply-with-crlf (2017-08-17) 3 commits > - SQUASH??? > - apply: file commited with CRLF should roundtrip diff and apply > - convert: add SAFE_CRLF_KEEP_CRLF > (this branch is tangled with jc/apply-with-crlf.) > > "git apply" that is used as a better "patch -p1" failed to apply a >

Re: t5551 hangs ?

On Tue, Aug 22, 2017 at 01:26:25AM -0400, Santiago Torres wrote: > Hello, Torsten. > > On Tue, Aug 22, 2017 at 07:10:59AM +0200, Torsten Bögershausen wrote: > > Hej, > > I found 2 threads about hanging t5551, one in 2016, and one question > > from Junio s

Re: Cannot checkout after setting the eol attribute

On Tue, Aug 22, 2017 at 01:49:18PM -0400, Ben Boeckel wrote: > Hi, > > I specified the `eol` attribute on some files recently and the behavior > of Git is very strange. > > Here is the set of commands to set up the repository used for the > discussion: > > git init > echo $'dos\r' > dos

Re: [PATCH v2 1/1] t0027: tests are not expensive; remove t0025

be retiered: s/retiered/retired/ The execution time for t0027 is 14 seconds under Linux, and 63 seconds under Mac Os X. And in case you ask, things are not going significantly faster using a SSD instead of a spinning disk. Signed-off-by: Torsten Bögershausen <tbo...@web.de> Thank you for t

Re: [PATCH] pathspec: die on empty strings as pathspec

On 23/06/17 20:04, Junio C Hamano wrote: Junio C Hamano writes: Sorry for my mess, see below I am not sure if we even want the dot there, but at least that is what the original author of the test intended to do when s/he decided to pass an empty string as the pathspec.

Re: EOL LF Windows auto.crlf issue

On 24/06/17 18:56, Filip Kucharczyk wrote: I'm on Windows 10. auto.crlf in .gitconfig is set to [core] autocrlf = true I've got a git (git version 2.13.1.windows.2) repo. A linux guy emails me a text with with line endings LF. I paste this file into my repo. Now every time I introduce changes

Re: [PATCH v5 4/5] convert: move multiple file filter error handling to separate function

On 2017-06-18 13:47, Lars Schneider wrote: > >> On 18 Jun 2017, at 09:20, Torsten Bögershausen <tbo...@web.de> wrote: >> >> >> On 2017-06-01 10:22, Lars Schneider wrote: >>> This is useful for the subsequent patch 'convert: add "status=dela

Re: [PATCH v2 4/6] fsmonitor: add test cases for fsmonitor extension

> diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh > new file mode 100755 > index 00..d3cffc758f > --- /dev/null > +++ b/t/t7519-status-fsmonitor.sh > @@ -0,0 +1,153 @@ > +#!/bin/sh > + > +test_description='git status with file system watcher' > + > +. ./test-lib.sh >

Re: [PATCH v4 4/4] convert: add "status=delayed" to filter process protocol

On 2017-05-22 15:50, Lars Schneider wrote: > +After Git received the pathnames, it will request the corresponding > +blobs again. These requests contain a pathname and an empty content > +section. The filter is expected to respond with the smudged content > +in the usual way as explained above. >

Re: [PATCH v4 4/4] convert: add "status=delayed" to filter process protocol

On 2017-05-22 15:50, Lars Schneider wrote: > + > +int async_query_available_blobs(const char *cmd, struct string_list > *delayed_paths) > +{ > + int err; > + char *line; > + struct cmd2process *entry; > + struct child_process *process; > + struct strbuf filter_status =

Re: [PATCH v6 6/6] clean: teach clean -d to preserve ignored paths

diff --git a/builtin/clean.c b/builtin/clean.c index d861f836a..937eb17b6 100644 --- a/builtin/clean.c +++ b/builtin/clean.c @@ -857,6 +857,38 @@ static void interactive_main_loop(void) } } +static void correct_untracked_entries(struct dir_struct *dir) +{ + int src, dst,

Re: Bug report: Corrupt pack file after committing a large file (>4 GB?)

On 2017-05-26 07:51, Yu-Hsuan Chen wrote: > Dear maintainer, > > There is a bug where committing a large file corrupts the pack file in > Windows. Steps to recreate are: > > 1. git init > 2. stage and commit a file larger than 4 GB (not entirely sure about this > size) > 3. git checkout -f > >

Re: Git Daemon on Windows fatal error.

On 31/05/17 21:10, Hector Santos wrote: Hi, I am relatively new to GIT (coming from CVS and SVN) and I am trying to setup "Git Daemon" on windows. I got it working for Local network communications: d:\local\wc5\testgit>git clone git://localhost/http clone10 Cloning into 'clone10'... remote:

Re: [PATCH v5 4/5] convert: move multiple file filter error handling to separate function

On 2017-06-01 10:22, Lars Schneider wrote: > This is useful for the subsequent patch 'convert: add "status=delayed" to > filter process protocol'. May be Collecting all filter error handling is useful for the subsequent patch 'convert: add "status=delayed" to filter process protocol'. > >

Re: [PATCH v2] doc: fix location of index in worktree scenatio

Thanks for working on this (and keeping me in cc) The commit head line does not fully match my expactions: "doc: fix location of index in worktree scenatio" "doc:" is OK, but is the "location of index" fixed ? Actually something that includes the important stuff: "doc" "fix" "normalize the line

Re: [PATCH v3] doc: do not use `rm .git/index` when normalizing line endings

On 14/06/17 00:15, Andreas Heiduk wrote: Looks good to me, one minor typo below When illustrating how to normalize the line endings, the documentation in gitattributes tells the user to `rm .git/index`. This is incorrect for two reasons: - Users shouldn't be instructed to mess around with

Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

On 14.06.17 09:42, Lars Schneider wrote: > >> * ls/filter-process-delayed (2017-06-01) 5 commits >> - convert: add "status=delayed" to filter process protocol >> - convert: move multiple file filter error handling to separate function >> - t0021: write "OUT" only on success >> - t0021: make

Re: [PATCH v2] doc: fix location of index in worktree scenatio

On 06/12/2017 06:06 PM, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: Thanks for working on this (and keeping me in cc) The commit head line does not fully match my expactions: "doc: fix location of index in worktree scenatio" "doc:" is OK, but

Re: [PATCH v2 1/9] t7300: skip untracked dirs containing ignored files

On 2017-05-05 12:46, Samuel Lijin wrote: > If git sees a directory which contains only untracked and ignored > files, clean -d should not remove that directory. It was recently > discovered that this is *not* true of git clean -d, and it's possible > that this has never worked correctly; this test

Re: [PATCH/RFC 1/1] t0027: Some tests are not expensive

On 01/05/17 05:07, Junio C Hamano wrote: tbo...@web.de writes: From: Torsten Bögershausen <tbo...@web.de> ... The execution time for the non-expansive part is 6..8 seconds under Linux, and 32 seconds under Mac Os X. Running the "expensive" version roughly doubles the time.

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

On 2017-04-24 19:22, René Scharfe wrote: > The first patch adds (expensive) tests, the next two are cleanups which > set the stage for the remaining two to actually implement zip64 support > for offsets and file sizes. > > Half of the series had been laying around for months, half-finished and >

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

On 30/04/17 00:28, René Scharfe wrote: Am 29.04.2017 um 23:00 schrieb Torsten Bögershausen: This fails here under Mac OS: commit 4cdf3f9d84568da72f1dcade812de7a42ecb6d15 Author: René Scharfe <l@web.de> Date: Mon Apr 24 19:33:34 2017 +0200 archive-zip: support files bigger th

Re: not uptodate. Cannot merge

On 2017-05-04 23:40, G. Sylvie Davies wrote: > Hi, > > My little bitbucket "cherry-pick" button is failing on Windows from a > "git reset --hard" blowing up. > > My situation: Git-2.10.2.windows.1 / Bitbucket-4.14.3 / Windows > 10-10.0-amd64. But I suspect even more recent Git will have the

Re: [PATCH v6 10/12] fsmonitor: add test cases for fsmonitor extension

On 2017-09-15 21:20, Ben Peart wrote: > +if [ "$1" != 1 ] > +then > + echo -e "Unsupported core.fsmonitor hook version.\n" >&2 > + exit 1 > +fi The echo -e not portable (It was detected by a tighter version of the lint script, which I have here, but not yet send to the list :-( This

Re: [PATCH v6 08/12] fsmonitor: add a test tool to dump the index extension

On 2017-09-18 15:38, Ben Peart wrote: > > > On 9/17/2017 4:02 AM, Junio C Hamano wrote: >> Ben Peart writes: >> >>> diff --git a/t/helper/test-dump-fsmonitor.c b/t/helper/test-dump-fsmonitor.c >>> new file mode 100644 >>> index 00..482d749bb9 >>> --- /dev/null

Re: [PATCH v6 08/12] fsmonitor: add a test tool to dump the index extension

> > Should I just make the variable type itself uintmax_t and then just skip > the cast altogether? I went with uint64_t because that is what > getnanotime returned. > That is a bit of taste question (or answer) Typically you declare the variables in the type you need, and this is uint64_t.

Re: is there a "symlink" option for cloning a repo in a separate filesystem?

On 2017-09-23 10:22, Robert P. J. Day wrote: > > reading "man git-clone", and i understand the mechanics of the local > protocol, so that if i run: > > $ git clone /path/to/repo > > then "files under .git/objects/ directory are hardlinked to save space > when possible." > > but if the

Re: [PATCH 1/4] git-compat-util.h: xsize_t() - avoid -Wsign-compare warnings

On 2017-09-21 18:46, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > git-compat-util.h | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/git-compat-util.h b/git-compat-util.h > index 9bc15b036..cedad4d58 100644 > ---

Re: [PATCH v1 1/1] test-lint: echo -e (or -E) is not portable

On Tue, Sep 19, 2017 at 01:37:14PM -0700, Jonathan Nieder wrote: > Torsten Bögershausen <tbo...@web.de> wrote: > > > Some implementations of `echo` support the '-e' option to enable > > backslash interpretation of the following string. > > As an addition, th

Re: Line ending normalization doesn't work as expected

On Fri, Oct 06, 2017 at 09:33:31AM +0900, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > > > Before we put this into stone: > > Does it make sense to say "renormalize" instead of "rehash" ? > > (That term does exist alre

Re: Line ending normalization doesn't work as expected

On 2017-10-03 19:23, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 11:26 AM, Torsten Bögershausen <tbo...@web.de> wrote: >> The short version is, that the instructions on Github are outdated. >> This is the official procedure (since 2016, Git v2.12 or so) >> But it

Re: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.

On Fri, Sep 08, 2017 at 12:00:50PM -0600, Kevin Willford wrote: > When using the sparse checkout feature the git reset command will add > entries to the index that will have the skip-worktree bit off but will > leave the working directory empty. File data is lost because the index > version of

Re: Empty directories in Git: Current guidance for historical commits?

On 2017-09-05 14:47, wafflec...@openmail.cc wrote: > > Hello, > > Per the FAQ it's clear that Git (by current design) does not track empty > directories:  > https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F > > That's fine and I can fix that for my code going forward

Re: Line ending normalization doesn't work as expected

On 2017-10-03 17:00, Robert Dailey wrote: > I'm on Windows using Git for Windows v2.13.1. Following github's > recommended process for fixing line endings after adding a > `.gitattributes` file[1], I run the following: > > $ rm .git/index && git reset > > Once I run `git status`, I see that no

t5551 hangs ?

Hej, I found 2 threads about hanging t5551, one in 2016, and one question from Junio somewhen in 2017. I have it reproducable here: - Debian 8, 64 bit - SSD - Half-modern processor ;-) The last thing I can see is: ok 29 - test allowanysha1inwant with unreachable --- A simplified ps -ef

Re: [PATCH] Documentation: mention that `eol` can change the dirty status of paths

On Wed, Aug 23, 2017 at 05:17:41PM -0400, Ben Boeckel wrote: > When setting the `eol` attribute, paths can change their dirty status > without any change in the working directory. This can cause confusion > and should at least be mentioned with a remedy. > > Signed-off-by: Ben Boeckel

Re: Cannot checkout after setting the eol attribute

On Tue, Aug 22, 2017 at 03:44:41PM -0400, Ben Boeckel wrote: > On Tue, Aug 22, 2017 at 21:13:18 +0200, Torsten Bögershausen wrote: > > When you set the text attribute (in your case "eol=crlf" implies text) > > then the file(s) -must- be nomalized and commited so that the

Re: [PATCH v3] Documentation: mention that `eol` can change the dirty status of paths

On 2017-08-31 15:19, Ben Boeckel wrote: > This attribute sets a specific line-ending style to be used in the > working directory. It enables end-of-line conversion without any > -content checks, effectively setting the `text` attribute. > +content checks, effectively setting the `text`

Re: Line ending normalization doesn't work as expected

On Wed, Oct 04, 2017 at 11:26:55AM -0500, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano <gits...@pobox.com> wrote: > > Torsten Bögershausen <tbo...@web.de> writes: > > > >>> $ git rm -r --cached . && git add . > >&

Re: Line ending normalization doesn't work as expected

> builtin/add.c | 42 +- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/builtin/add.c b/builtin/add.c > index 5d5773d5cd..264f84dbe7 100644 > --- a/builtin/add.c > +++ b/builtin/add.c > @@ -26,6 +26,7 @@ static const char * const

Re: core.safecrlf warning is confusing[improvement suggestion?]

On Wed, Nov 22, 2017 at 11:01:22AM +0900, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> 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.) >

<    6   7   8   9   10   11   12   13   >