Re: [PATCH v2 4/5] convert: generate large test files only once

On 07/27/2016 02:06 AM, larsxschnei...@gmail.com wrote: From: Lars Schneider Generate a more interesting large test file with random characters in between and reuse this test file in multiple tests. Run tests formerly marked as EXPENSIVE every time but with a

Re: [PATCH v10 12/12] bisect--helper: `get_terms` & `bisect_terms` shell function in C

On 07/25/2016 06:53 PM, Junio C Hamano wrote: Pranit Bauva writes: >>> +enum terms_defined { >>> + TERM_BAD = 1, >>> + TERM_GOOD = 2, >>> + TERM_NEW = 4, >>> + TERM_OLD = 8 >>> +}; >>> + >> >> What does TERM stand for ? The terms (words)

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

On 07/22/2016 05:49 PM, larsxschnei...@gmail.com wrote: From: Lars Schneider Git's clean/smudge mechanism invokes an external filter process for every single blob that is affected by a filter. If Git filters a lot of blobs then the startup time of the external

Re: [PATCH v10 12/12] bisect--helper: `get_terms` & `bisect_terms` shell function in C

On 07/20/2016 11:47 PM, Pranit Bauva wrote: Reimplement the `get_terms` and `bisect_terms` shell function in C and add `bisect-terms` subcommand to `git bisect--helper` to call it from git-bisect.sh . In the shell version, the terms were identified by strings but in C version its done by bit

Re: Looking for help to understand external filter driver code

On 07/20/2016 12:01 AM, Lars Schneider wrote: On 19 Jul 2016, at 23:33, Junio C Hamano wrote: Lars Schneider writes: Git writes --> 4 byte filename length Git writes --> filename string Why limit to 32GB? Perhaps NUL termination is more

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On 07/15/2016 12:38 AM, Jeff King wrote: On Thu, Jul 14, 2016 at 03:30:58PM -0700, Junio C Hamano wrote: If we move to time_t everywhere, I think we'll need an extra TIME_T_IS_64BIT, but we can cross that bridge when we come to it. Likewise I think we'll need SIZE_T_IS_64BIT eventually (for

Re: [PATCH v4 3/5] archive-tar: write extended headers for file sizes >= 8GB

On 07/14/2016 06:48 PM, Johannes Sixt wrote: Am 30.06.2016 um 11:09 schrieb Jeff King: +/* + * This is the max value that a ustar size header can specify, as it is fixed + * at 11 octal digits. POSIX specifies that we switch to extended headers at + * this size. + */ +#define USTAR_MAX_SIZE

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

On 07/13/2016 12:20 AM, Joey Hess wrote: Torsten Bögershausen wrote re jh/clean-smudge-annex: The thing is that we need to check the file system to find .gitatttibutes, even if we just did it 1 nanosecond ago. So the .gitattributes is done 3 times: -1 would_convert_to_git_filter_fd( -2

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

yet, so right now both topics are stalled and waiting for an action from you. Yes, the code looks good to me. And the commit message does explain what is going on. For my taste, these 3 lines don't explain too much,may be remove them ? > The test update was taken from a series by Torsten Bög

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 07/08/2016 06:36 PM, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: I dunno. I really do not like that extra sha1 argument added all over the callchain by this patch. Or did you mean other calls to add_cacheinfo()? I didn't mean too much - the whole call

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 07/07/16 20:43, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> This is the call stack: >> >> merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1, >>const char *path,

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 07/07/16 20:43, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: This is the callstack: merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh, int options) { struct cache_ent

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 2016-07-06 16.57, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> At some point inside the merge, Git calls read-cache.c/ce_compare_data(), >> to check if the path named "file" is clean. >> According to the tree informat

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 2016-07-02 00.11, Junio C Hamano wrote: [snip] diff --git a/read-cache.c b/read-cache.c index a3ef967..c109b6d 100644 --- a/read-cache.c +++ b/read-cache.c @@ -163,7 +163,9 @@ static int ce_compare_data(const struct cache_entry *ce, struct stat *st) if (fd >= 0) {

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 29.06.16 18:14, Junio C Hamano wrote: > tbo...@web.de writes: > >> From: Torsten Bögershausen <tbo...@web.de> >> >> The following didn't work as expected: > > Sorry for being slow (not in response but in understanding), but > let's examine the expe

Re: [PATCH v4 0/6] worktree lock/unlock

>On 03.06.16 14:19, Nguyễn Thái Ngọc Duy wrote: Minor problem: t2028 fails, when the test is run from a directory that is a softlink. (In my case /Users/tb/projects/git/git.pu is a softlink to /Users/tb/NoBackup/projects/git/git.pu/ [master (root-commit) 2519212] init Author: A U Thor

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

On 22/06/16 23:09, Joey Hess wrote: Torsten Bögershausen wrote: There is a conflict in pu: "jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index" (And currently pu didn't compile) I'm sending a v4 of jh/clean-smudge-annex that is rebased on to

Re: [PATCH] t7800 readlink not found

On 06/21/2016 08:39 PM, Junio C Hamano wrote: Armin Kunaschik <megabr...@googlemail.com> writes: On Tue, May 31, 2016 at 7:51 AM, Junio C Hamano <gits...@pobox.com> wrote: Torsten Bögershausen <tbo...@web.de> writes: diff --git a/t/t7800-difftool.sh b/t/t7800-difftoo

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

There is a conflict in pu: "jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index" (And currently pu didn't compile) (I will hopefully be able to do a separate review of the smudge/clean patch) (And jo...@joeyh.name is not reachable from web.de) -- To unsubscribe from

Re: problems installing GIT on my MAC OS X 10.11.5

On 14.06.16 18:45, Maria Jose Fernandez wrote: > From http://git-scm.com/download/mac I clicked to download manually. > Then it goes to > https://sourceforge.net/projects/git-osx-installer/files/git-2.8.1-intel-universal-mavericks.dmg/download?use_mirror=autoselect > I found the git -

Re: problems installing GIT on my MAC OS X 10.11.5

On 14.06.16 18:06, Konstantin Khomoutov wrote: > On Tue, 14 Jun 2016 16:56:15 +0100 > Maria Jose Fernandez wrote: > >> I am doing a data science course and need to download GIT but for >> some reason I can’t installed it. I called Apple but they couldn’t >> help and

Re: [PATCH 3/4] dir: introduce file_size() to check the size of file

>> So what I understand, you want something like this: >> >> +ssize_t file_size_not_zero(const char *filename) >> +{ >> + struct stat st; >> + if (stat(filename, ) < 0) >> + return -1; >> + return !!st.st_size); >> +} > > For the purpose of bisect_reset(), Yes. BTW

Re: [PATCH 3/4] dir: introduce file_size() to check the size of file

On 06/08/2016 09:57 AM, Pranit Bauva wrote: Hey Eric, On Wed, Jun 8, 2016 at 1:07 PM, Eric Sunshine wrote: On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva wrote: dir: introduce file_size() to check the size of file At times we require to see if

Re: What's cooking in git.git (Jun 2016, #02; Mon, 6)

* mh/connect (2016-06-06) 10 commits - connect: [host:port] is legacy for ssh - connect: move ssh command line preparation to a separate function - connect: actively reject git:// urls with a user part - connect: change the --diag-url output to separate user and host - connect: make

Re: Minor Bug in Renaming Branches

On 06/06/2016 09:35 PM, Stefan Beller wrote: On Mon, Jun 6, 2016 at 12:17 PM, Torsten Bögershausen <tbo...@web.de> wrote: A limitation is introduced by Mac OS and Windows: BRANCH/NAME and branch/name refer to the same object in the file system. As a workaround, you can pack the branch

Re: Minor Bug in Renaming Branches

On 06.06.16 19:52, Samuel Lijin wrote: > Hi, > > Not quite sure where to submit bug reports about Git, this was the > best I could find, so if there's a better place to do this, please let > me know and I will. > > The short of this issue is that on Mac and Windows, if a branch has a > slash in

Re: [PATCH] cherry-pick: allow to pick to unborn branches

On 06.06.16 15:23, Michael J Gruber wrote: > Currently, cherry-pick allows tp pick single commits to an empty HEAD Typo: ^^ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: What's cooking in git.git (Jun 2016, #01; Thu, 2)

On 04.06.16 18:24, Junio C Hamano wrote: > Can we have a final submission to be queued? Yes Thanks for the improvements and the discussions. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: What's cooking in git.git (Jun 2016, #01; Thu, 2)

On 2016-06-04 07.14, Mike Hommey wrote: > On Fri, Jun 03, 2016 at 04:47:33PM -0700, Junio C Hamano wrote: >> Mike Hommey writes: >> >>> In fact, the parser doesn't even reject the one that is considered >>> invalid (the first). >> >> My question was what the desired behaviour

Re: [PATCH] t1308: do not get fooled by symbolic links to the source tree

On 06/03/2016 08:53 AM, Johannes Sixt wrote: Am 03.06.2016 um 08:10 schrieb Jeff King: On Fri, Jun 03, 2016 at 08:05:56AM +0200, Johannes Sixt wrote: -name=$(pwd)/.gitconfig +name=$HOME/.gitconfig I haven't tested this, yet, but my guess is that this breaks on Windows: test-config

Re: What's cooking in git.git (Jun 2016, #01; Thu, 2)

On 06/03/2016 01:13 AM, Mike Hommey wrote: On Thu, Jun 02, 2016 at 03:52:41PM -0700, Junio C Hamano wrote: * mh/connect (2016-06-01) 9 commits - connect: move ssh command line preparation to a separate function - connect: actively reject git:// urls with a user part - connect: change the

Re: What's cooking in git.git (May 2016, #09; Tue, 31) t1308 broken

It seams as ./t1308-config-set.sh is broken, when the the directory is a soft link: -name=/home/tb/NoBackup/projects/git/git.pu/t/trash directory.t1308-config-set/.gitconfig +name=/home/tb/projects/git/git.pu/t/trash directory.t1308-config-set/.gitconfig scope=global key=foo.bar not ok 28 -

Re: [PATCH] t7800 readlink not found

On 05/31/2016 02:26 AM, Armin Kunaschik wrote: On 05/27/2016 06:19 AM, David Aguilar wrote: On Wed, May 25, 2016 at 11:33:33AM +0200, Armin Kunaschik wrote: Would you mind submitting a patch so that we can support these tests when running on AIX/HP-UX? I don't feel comfortable to submit

Re: [PATCH v8 0/9] connect: various cleanups

On 28.05.16 07:33, Mike Hommey wrote: > On Sat, May 28, 2016 at 07:02:01AM +0200, Torsten Bögershausen wrote: >> On 27.05.16 23:59, Mike Hommey wrote: >>> On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote: >>>> On 27.05.16 04:27, Mike Homme

Re: [PATCH v8 0/9] connect: various cleanups

On 27.05.16 23:59, Mike Hommey wrote: > On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote: >> On 27.05.16 04:27, Mike Hommey wrote: >>> Changes from v7: >>> - Fixed comments. >>> >>> Mike Hommey (9): All in all, a great improvement.

Re: [PATCH v8 0/9] connect: various cleanups

On 27.05.16 04:27, Mike Hommey wrote: > Changes from v7: > - Fixed comments. > > Mike Hommey (9): > connect: document why we sometimes call get_port after > get_host_and_port > connect: call get_host_and_port() earlier > connect: re-derive a host:port string from the separate host and

Re: [PATCH v7 1/9] connect: document why we sometimes call get_port after get_host_and_port

On 05/26/2016 01:34 AM, Mike Hommey wrote: On Tue, May 24, 2016 at 06:44:26AM +0200, Torsten Bögershausen wrote: On 05/23/2016 11:30 PM, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: get_host_and_port

Re: [BUG] can not escape sharps in git config file

On 05/24/2016 01:23 PM, Jean-Noël Avila wrote: My mistake, sorry for the noise, JFTR: * only double quotes can fully escape a string (it is safer to enclose the whole value in double quotes) * backslashes have to be doubled because they are interpreted by git So [filter "kicad_sch"]

Re: Odd Difference Between Windows Git and Standard Git

On 05/24/2016 01:57 PM, Johannes Schindelin wrote: Hi, On Tue, 24 May 2016, Torsten Bögershausen wrote: On 05/23/2016 08:52 PM, Junio C Hamano wrote: Johannes Schindelin <johannes.schinde...@gmx.de> writes: Of course, if you are doing network mount between systems with and without fi

Re: Odd Difference Between Windows Git and Standard Git

On 05/23/2016 08:52 PM, Junio C Hamano wrote: Johannes Schindelin writes: Of course, if you are doing network mount between systems with and without filemode support, the result would depend on where you did the "git init", so that would not help. Which means that

Re: [PATCH v7 1/9] connect: document why we sometimes call get_port after get_host_and_port

On 05/23/2016 11:30 PM, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: get_host_and_port(_host, ); +/* get_host_and_port may not return a port even when +* there is one: In the [host:port]:pat

Re: [PATCH v7 1/9] connect: document why we sometimes call get_port after get_host_and_port

On 05/22/2016 10:03 AM, Mike Hommey wrote: On Sun, May 22, 2016 at 08:07:05AM +0200, Torsten Bögershausen wrote: On 22.05.16 01:17, Mike Hommey wrote: Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/connect.c b/con

Re: [PATCH v7 1/9] connect: document why we sometimes call get_port after get_host_and_port

On 22.05.16 01:17, Mike Hommey wrote: > Signed-off-by: Mike Hommey > --- > connect.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/connect.c b/connect.c > index c53f3f1..caa2a3c 100644 > --- a/connect.c > +++ b/connect.c > @@ -742,6 +742,12 @@ struct

Re: Odd Difference Between Windows Git and Standard Git

On 20.05.16 17:23, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >>>> What does >>>> git diff >>>> say ? >>> >>> Great question. For all the unexpected files it says the >>> same thing: >>

Re: Odd Difference Between Windows Git and Standard Git

On 20.05.16 16:28, Jon Forrest wrote: > > > On 5/20/2016 7:19 AM, Torsten Bögershausen wrote: > >>> Great question. For all the unexpected files it says the >>> same thing: >>> >>> old mode 100755 >>> new mode 100644 >>

Re: Odd Difference Between Windows Git and Standard Git

On 20.05.16 15:48, Jon Forrest wrote: > > > On 5/20/2016 6:19 AM, Torsten Bögershausen wrote: >> On 20.05.16 03:48, Jon Forrest wrote: >>> I'm running Git version 2.8.2 built from source on Ubuntu 16.04. >>> I'm using a repository that's stored on Dropbox.

Re: Odd Difference Between Windows Git and Standard Git

On 20.05.16 03:48, Jon Forrest wrote: > I'm running Git version 2.8.2 built from source on Ubuntu 16.04. > I'm using a repository that's stored on Dropbox. I'm the only person > accessing this repo. Everything works great. > > For reasons unrelated to Git, I decided to try Git for Windows, > so I

Re: [PATCH v4 2/2] convert: ce_compare_data() checks for a sha1 of a path

On 18.05.16 06:26, Torsten Bögershausen wrote: > On 05/17/2016 08:58 PM, Junio C Hamano wrote: >> tbo...@web.de writes: >> >>> #define HASH_WRITE_OBJECT 1 >>> #define HASH_FORMAT_CHECK 2 >>> +#define HASH_CE_HAS_SHA1 4 >> >> How does o

Re: [PATCH v4 2/2] convert: ce_compare_data() checks for a sha1 of a path

On 05/17/2016 08:58 PM, Junio C Hamano wrote: tbo...@web.de writes: #define HASH_WRITE_OBJECT 1 #define HASH_FORMAT_CHECK 2 +#define HASH_CE_HAS_SHA1 4 How does one pronounce the words in this constant? Does it make a listener understand what this constant means? How about

Re: [PATCH 1/3] mv: free memory at the end if desired

>[PATCH 1/3] mv: free memory at the end if desired s/desired/DEVELOPER/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/1] CRLF-Handling: bug fix around ce_compare_data()

On 05/16/2016 06:13 PM, Junio C Hamano wrote: Wait a minute, please. I only asked the reason why you did it that way and mentioned that the end result seemed equivalent. "The end result seems equivalent" does not automatically mean "therefore you must avoid changing the code." If you still

Re: [PATCH] crlf: Add test showing double warning on commit

On 14.05.16 20:45, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> Do we need to run diff_populate_filespec() twice when src==dst ? > > Of course we do. > > src and dst may have the same path, but are coming from different > places (src

Re: [PATCH] crlf: Add test showing double warning on commit

On 14.05.16 20:45, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> Do we need to run diff_populate_filespec() twice when src==dst ? > > Of course we do. > > src and dst may have the same path, but are coming from different > places (src

Re: [PATCH v2 29/33] refs: resolve symbolic refs first

On 13.05.16 14:33, Michael Haggerty wrote: > Torsten, thanks for the report. Peff, thanks for the analysis. I didn't follow all the details. The new "pu" passes with no errors on all of my test systems :-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a

Re: [PATCH v2] diff: run arguments through precompose_argv

On 13.05.16 22:41, Alexander Rinass wrote: > When running diff commands, a pathspec containing decomposed > unicode code points is not converted to precomposed unicode form > under Mac OS X, but we normalize the paths in the index and the > history to precomposed form on that platform. As a

Re: Bug report: Duplicate CRLF rewrite warnings on commit

On 13.05.16 18:43, Junio C Hamano wrote: > Adam Dinwoodie writes: > >> If you use .gitattributes to enable CRLF->LF rewriting, then commit a >> file that would have its line endings rewritten, the "CRLF will be >> replaced by LF" warning is printed several times over; I'd

Re: t5551 hangs ?

On 12.05.16 05:16, Jeff King wrote: > On Wed, May 11, 2016 at 10:03:45PM +0200, Torsten Bögershausen wrote: > >>> If you are, can you confirm that it's actually hanging, and not just >>> slow? On my system, test 26 takes about a minute to run (which is why we &g

Re: t5551 hangs ?

On 11.05.16 19:31, Jeff King wrote: > On Wed, May 11, 2016 at 07:13:56PM +0200, Torsten Bögershausen wrote: > >> On 10.05.16 09:08, Johannes Schindelin wrote: >> - I'm not sure, if this is the right thread to report on - >> >> It seems as if t5551 is hanging ?

t5551 hangs ?

On 10.05.16 09:08, Johannes Schindelin wrote: - I'm not sure, if this is the right thread to report on - It seems as if t5551 is hanging ? This is the last line from the log: ok 25 - large fetch-pack requests can be split across POSTs I have 7 such processes running: /trash

Re: [PATCH v9 2/6] convert.c: stream and early out

On 09.05.16 22:29, Junio C Hamano wrote: > tbo...@web.de writes: > >> +if (stats->stat_bits & earlyout) >> +break; /* We found what we have been searching for */ > > Are we sure if our callers are only interested in just one bit at a > time? Otherwise, if we want

Re: t6044 broken on pu

On 08.05.16 20:20, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> May a simple >> printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" >> >> be an option ? > If you were to do that, at least have the decency to make it more >

Re: t6044 broken on pu

On 08.05.16 04:21, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> That's true, but the test passes anyway. > You can also remove the body of the test and replace it with "true" > and say "the test passes anyway". Changing

Re: t6044 broken on pu

On 2016-05-07 14.19, Andreas Schwab wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> The "seq" is not understood by all shells, >> using printf fixes this, >> >> index 20a3ffe..48d964e 100755 >> --- a/t/t6044-merge-unrelated-ind

t6392 broken on pu (Mac OS X)

These tests fail here under Mac OS, they pass under Linux: commit ff3d9b660a4b6e9d3eeb664ce1febe717adff737 I haven't had a chance to dig further. expecting success: git for-each-ref --format="%(if)%(authorname)%(then)%(authorname): %(refname)%(end)" >actual && cat >expect <<-\EOF

t6044 broken on pu

The "seq" is not understood by all shells, using printf fixes this, index 20a3ffe..48d964e 100755 --- a/t/t6044-merge-unrelated-index-changes.sh +++ b/t/t6044-merge-unrelated-index-changes.sh @@ -20,7 +20,7 @@ test_description="merges with unrelated index changes" # Commit E: renames

Re: [PATCH] precompose-utf8: fix typo of "sequences"

On 2016-05-06 13.55, Li Peng wrote: > Fix a typo in comment. Thanks -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 10/10] ce_compare_data() did not respect conversion

> Let's separate 01-04/10 into a different topic and give it its own > name; tb/convert-eol-autocrlf was the name I picked primarily for > 07/10 but 01-04/10 are not about that fix. Both 02 and 04 are about > autocrlf (the former is "core.eol is irrelevant when core.autocrlf > is there", the

Re: [PATCH v4 01/11] add fetch-pack --diag-url tests for some corner cases

On 05.05.16 23:52, Mike Hommey wrote: > On Wed, May 04, 2016 at 07:48:30AM +0900, Mike Hommey wrote: >> On Tue, May 03, 2016 at 09:07:41AM -0700, Junio C Hamano wrote: >>> Mike Hommey writes: >>> t5603-clone-dirname uses url patterns that are not tested with

Re: Portability of git shell scripts?

On 04.05.16 20:17, Armin Kunaschik wrote: > Hi list, > > I'm trying to compile/test/use git 2.8.2 on AIX 6.1 with no bash available. > /bin/sh is a hard link to /bin/ksh which is a ksh88, a posix shell. > Is this supposed to work? > > As an example: make test fails on nearly every t34* test and

Re: [PATCH v8 10/10] ce_compare_data() did not respect conversion

On 05/03/2016 08:31 PM, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: This will probably take some time, so that's why I asked if 1/10..4/10 could proceed as is ? Sure, I wasn't saying 1-4 looked wrong at all. I was wondering why the ones in the middle, especi

Re: [PATCH v4 01/11] add fetch-pack --diag-url tests for some corner cases

On 2016-05-03 18.07, Junio C Hamano wrote: > Mike Hommey writes: > >> t5603-clone-dirname uses url patterns that are not tested with >> fetch-pack --diag-url, and it would be useful if they were. >> >> Interestingly, some of those tests, involving both a port and a >>

Re: [PATCH v4 09/11] connect: use "-l user" instead of "user@" on ssh command line

On 2016-05-03 10.50, Mike Hommey wrote: > While it is not strictly necessary, it makes the connect code simpler > when there is user. > That commit message does't tell too much, I think. Besides that, I'm sure it will break (at least) my ssh wrapper scripts, which rely on user@host to be passed

Re: [PATCH v4 08/11] connect: change the --diag-url output to separate user and host

On 2016-05-03 10.50, Mike Hommey wrote: > Signed-off-by: Mike Hommey > --- > connect.c | 6 ++ > t/t5500-fetch-pack.sh | 14 -- > 2 files changed, 14 insertions(+), 6 deletions(-) > > diff --git a/connect.c b/connect.c > index e95e385..2c5b722

Re: [PATCH v4 01/11] add fetch-pack --diag-url tests for some corner cases

On 2016-05-03 10.50, Mike Hommey wrote: > diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh > index e5f83bf..1f0133f 100755 > --- a/t/t5500-fetch-pack.sh > +++ b/t/t5500-fetch-pack.sh > @@ -569,12 +569,27 @@ check_prot_host_port_path () { > test_cmp expected actual > } > > -for r

Re: [PATCH v8 10/10] ce_compare_data() did not respect conversion

On 2016-05-02 21.33, Junio C Hamano wrote: > Junio C Hamano writes: > Let's step back a bit and make sure we are on the same page. I > think this "series" conflates a bit too many things into a single > topic. > > * The comparison between the index and the working tree, i.e.

Re: [PATCH 2/6] connect: uniformize and group CONNECT_DIAG_URL handling code

On 05/02/2016 10:31 AM, Mike Hommey wrote: On Mon, May 02, 2016 at 06:56:54AM +0200, Torsten Bögershausen wrote: On 05/01/2016 08:02 AM, Mike Hommey wrote: + if (flags & CONNECT_DIAG_URL) { printf("Diag: url=%s\n", url ? url : "NULL");

Re: [PATCH 2/6] connect: uniformize and group CONNECT_DIAG_URL handling code

On 05/01/2016 08:02 AM, Mike Hommey wrote: + if (flags & CONNECT_DIAG_URL) { printf("Diag: url=%s\n", url ? url : "NULL"); printf("Diag: protocol=%s\n", prot_name(protocol)); printf("Diag: hostandport=%s\n", hostandport ? hostandport :

Re: [PATCH v8 10/10] ce_compare_data() did not respect conversion

On 29.04.16 23:09, Junio C Hamano wrote: > Well, didn't I do exactly the above much earlier and discarded it > because that breaks the definition of "diff"? Or is this doing > something differently? Yes, and I try to sneak it in anyway ;-) I spend some time debugging how to get t6038 passed,

Re: [PATCH 2/6] connect: uniformize and group CONNECT_DIAG_URL handling code

On 01.05.16 08:02, Mike Hommey wrote: > The CONNECT_DIAG_URL code for PROTO_GIT and PROTO_SSH were different in > subtle ways. Yes, and there (historical) reasons for that. The first implementation did support IPV6 with SSH: commit 5ba884483fe1a5f9ce1ce5e3c5e1c37c0fd296c4 [PATCH] GIT: Try

Re: [PATCH 1/6] connect: remove get_port()

On 2016-05-01 08.02, Mike Hommey wrote: > get_port() is only used as a fallback when get_host_and_port() does not > return a port. But get_port() does the same search as > get_host_and_port(), except get_host_and_port() starts from the end of > the host, respecting square brackets for ipv6

Re: [RFC PATCH 2/3] connect: group CONNECT_DIAG_URL handling code

On 29.04.16 02:43, Mike Hommey wrote: > get_host_and_port(_host, ); > + if (!port) > + port = get_port(ssh_host); I'm not sure, if this is an improvement or not. The original intention was, to check what the parser did, before going out to the

Re: [PATCH v7 07/10] convert: unify the "auto" handling of CRLF

UNDEFINED case to return EOL_CRLF here? > >> case CRLF_AUTO_INPUT: >> +return EOL_LF; One of the compilers claimed that UNDEFINED was not handled in switch-case. A Warning may be better ? >> case CRLF_TEXT: >> case CRLF_AUTO: >>

Re: How to have EOL=LF and keep binary files auto-detection?

On 25.04.16 16:11, Kirill Likhodedov wrote: > Hi, > > I wonder if it is possible both to have LFs in all and only text files in > working trees, and keep Git’s binary files auto-detection? > > To be more precise: > * we want all text files to be checked out in LF; > * we don’t want force

Re: [PATCH] convert.c: fix some sparse warnings

On 04/24/2016 07:14 PM, Ramsay Jones wrote: Sparse complains thus: SP convert.c convert.c:178:24: warning: Using plain integer as NULL pointer convert.c:239:28: warning: dubious: !x & y Signed-off-by: Ramsay Jones --- Hi Torsten, When you next

Re: [PATCH v6 01/10] t0027: Make more reliable

On 2016-04-23 00.03, Junio C Hamano wrote: > tbo...@web.de writes: > >> From: Torsten Bögershausen <tbo...@web.de> >> Subject: Re: [PATCH v6 01/10] t0027: Make more reliable > > "Make more reliable" does not sound very grammatical. > >> Make

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

* tb/convert-eol-autocrlf (2016-04-19) 4 commits - convert.c: ident + core.autocrlf didn't work - t0027: test cases for combined attributes - convert: allow core.autocrlf=input and core.eol=crlf - t0027: avoid false "unchanged" due to lstat() matching after a change Setting core.autocrlf

Re: [PATCH v5 3/4] t0027: test cases for combined attributes

>> Currently "* text=auto eol=lf" does the same as "* text eol=lf", >> as the eol attribute overrides "text=auto", this will change in >> future. > Will change in future in what way? In patch 5/4? > > Yes, kind of. I'm fighting to get the test passed under Windows, and if this 4/4 could make it

Re: [PATCH] upload-pack: Exit when server finishes sending shallow-update in stateless RPC mode

On 04/12/2016 06:55 AM, Stan Hu wrote: In the stateless RPC case, the server should respond to the client's depth request with the set of commits which are no deeper than the desired depth. Once this finishes, the server should terminate and receive the reply in another POST request. Previously

Re: [PATCH 1/3] index-helper: fix UNIX_PATH_MAX redefinition error on cygwin

On 04/11/2016 12:59 AM, Ramsay Jones wrote: The header mentions cygwin, but changes it for linux, BSD and Mac OS as well. Is this intentional ? Signed-off-by: Ramsay Jones --- git-compat-util.h | 17 - index-helper.c| 4 ++-- read-cache.c

Re: [PATCH 3/3] index-helper: take extra care with readlink

On 04/11/2016 01:03 AM, Ramsay Jones wrote: It took me a few minutes to convince myself that, if index-helper is the only writer for the symlink, that the call to readlink would result in a properly NULL terminated string. This relies on the Minor nit: s/NULL/NUL/ -- To unsubscribe from this

Re: [PATCH v2 05/21] t6030: generalize test to not rely on current implementation

On 10.04.16 15:18, Stephan Beyer wrote: Some nit-comments inline > --- > t/t6030-bisect-porcelain.sh | 167 > ++-- > 1 file changed, 85 insertions(+), 82 deletions(-) > > diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh > index

Re: Rename case insensitive

On 08.04.16 12:01, chenjinlei wrote: > > I’m encounter a problem due to my own stupidity… > #1 I pushed a project named Android to my repository. > #2 I `mv Android android`, cause I think it’s no good to use the uppercase as > my project name. > #3 I pushed it to my repository again… > > I

Re: [PATCH] diff: run arguments through precompose_argv

disease: The combining diaresis should combine with the o, not >> the g. Here is a correct line to copy-and-paste if you like: >> >> Thanks-to: Torsten Bögershausen <tbo...@web.de> >> >> -- Hannes > > Thanks for reviewing and catching the NFD encoding error.

Re: [PATCH v1] correct blame for files commited with CRLF

On 05.04.16 23:12, Junio C Hamano wrote: > tbo...@web.de writes: > >> +git config core.autocrlf true && >> +mv crlfinrepo tmp && >> +git checkout crlfinrepo && >> +rm tmp && > > Why not just "rm -f crlfinrepo" and "git checkout crlfinrepo"? The intention was to get a new inode

Re: [PATCH] diff: run arguments through precompose_argv

te if you like: > > Thanks-to: Torsten Bögershausen <tbo...@web.de> > > -- Hannes Good eyes. And thanks to Alexander for doing this patch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org M

Re: [PATCH v2 6/7] correct blame for files commited with CRLF

Thanks for all the comments. I just reallized that t6038 is broken, which I didn't notice before :-( Please feel free to kick out tb/safe-crlf-output-fix from pu, until I have looked into the breakage and found a fix. -- To unsubscribe from this list: send the line "unsubscribe git" in the

Re: [PATCH 1/2] imap-send.c: implements the GIT_CURL_DEBUG environment variable

On 01.04.16 12:44, Elia Pinto wrote: > Implements the GIT_CURL_DEBUG environment variable to allow a greater > degree of detail of GIT_CURL_VERBOSE, in particular the complete > transport header and all the data payload exchanged. > It might be useful if a particular situation could require a more

Re: [PATCH v1 6/7] correct blame for files commited with CRLF

directory $ git status# Show files that will be normalized $ git add -u $ git add .gitattributes $ git commit -m "Introduce end-of-line normalization" (or run "dos2unix" filename) commit a604db36bb946000776514c220964f32979c8756 Author: Torsten Bögersha

Re: [PATCH v1 6/7] correct blame for files commited with CRLF

On 29.03.16 19:21, Junio C Hamano wrote: > tbo...@web.de writes: > >> From: Torsten Bögershausen <tbo...@web.de> >> >> git blame reports lines as not "Not Committed Yet" when they have >> CRLF in the index, CRLF in the worktree and e.g. core.autocrlf

Re: [PATCH 00/19] index-helper, watchman

On 2016-03-09 19.36, David Turner wrote: > This is a rebase and extension of Duy's work on git index-helper and > watchman support. > Somewhere we need to tweak something: t7900 do all fail under Mac OS, because the index-helper is not build. The best would be to have a precondition when running

<    1   2   3   4   5   6   7   8   9   10   >