Re: [PATCH 3/7] fixup! compat/regex: update the gawk regex engine from upstream

Am 05.05.2017 um 00:00 schrieb Ævar Arnfjörð Bjarmason: --- compat/regex/regcomp.c | 356 + 1 file changed, 209 insertions(+), 147 deletions(-) diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c index d8bde06f1a..a1fb2e400e 100644 ---

[RFC PATCH 02/10] Move textconv_object to be with other textconv methods

Signed-off-by: Jeff Smith --- builtin.h | 2 -- builtin/blame.c| 28 builtin/cat-file.c | 1 + diff.c | 23 +++ diff.h | 7 +++ 5 files changed, 31 insertions(+), 30 deletions(-)

[RFC PATCH 06/10] Move fake_working_tree_commit() to lib

Signed-off-by: Jeff Smith --- Makefile| 1 + builtin/blame.c | 198 +-- commit-fake.c | 200 commit-fake.h | 9 +++ 4 files changed, 211 insertions(+),

[RFC PATCH 00/10] Add blame to libgit

In adding blame functionality to cgit, I do not wish to duplicate huge portions of builtin/blame.c there. I would rather shift its core functionality into libgit.a -- which cgit already uses -- and in cgit I can focus on the web presentation aspect. I was able to split three separate cohesive

[RFC PATCH 07/10] Break out scoreboard a little better

Signed-off-by: Jeff Smith --- builtin/blame.c | 149 +++- 1 file changed, 93 insertions(+), 56 deletions(-) diff --git a/builtin/blame.c b/builtin/blame.c index c873cc2..dc7600c 100644 --- a/builtin/blame.c +++

[RFC PATCH 01/10] Remove unneeded dependency on blob.h from blame

Signed-off-by: Jeff Smith --- builtin/blame.c | 1 - 1 file changed, 1 deletion(-) diff --git a/builtin/blame.c b/builtin/blame.c index 07506a3..42c56eb 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -8,7 +8,6 @@ #include "cache.h" #include "refs.h" #include

[RFC PATCH 10/10] Move scoreboard init and setup to lib

Signed-off-by: Jeff Smith --- builtin/blame.c | 274 scoreboard.c| 273 +++ scoreboard.h| 2 + 3 files changed, 275 insertions(+), 274 deletions(-) diff

[RFC PATCH 08/10] Split blame scoreboard into its own file

Signed-off-by: Jeff Smith --- Makefile|1 + builtin/blame.c | 1358 +-- scoreboard.c| 1296 scoreboard.h| 74 +++ 4 files changed, 1372

[RFC PATCH 09/10] Break out scoreboard init and setup

Signed-off-by: Jeff Smith --- builtin/blame.c | 264 +--- scoreboard.h| 1 + 2 files changed, 140 insertions(+), 125 deletions(-) diff --git a/builtin/blame.c b/builtin/blame.c index 0af99e3..3bde5a6 100644 ---

[RFC PATCH 04/10] Remove unused parameter from get_origin()

Signed-off-by: Jeff Smith --- builtin/blame.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/builtin/blame.c b/builtin/blame.c index c419981..cc46f56 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -449,9 +449,7 @@ static struct

[RFC PATCH 03/10] Add some missing definitions to header files

Signed-off-by: Jeff Smith --- object.h| 2 ++ pathspec.h | 4 refs.h | 3 +++ tree-walk.h | 2 ++ 4 files changed, 11 insertions(+) diff --git a/object.h b/object.h index f52957d..9737582 100644 --- a/object.h +++ b/object.h @@ -1,6 +1,8 @@ #ifndef OBJECT_H

[RFC PATCH 05/10] Split blame origin into its own file

Signed-off-by: Jeff Smith --- Makefile| 1 + builtin/blame.c | 151 +--- origin.c| 62 +++ origin.h| 101 + 4 files changed, 165

git error

hi, I used the command below,there's an error,please help me to solve it ! Thank you ~ git push Best Regards~ ada Wang

[L10N] Kickoff for Git 2.13.0 l10n round 2

Hi, Git v2.13.0-rc2 introduced 4 new messages, let's start round 2 for Git 2.13.0 l10n. You can get it from the usual place: https://github.com/git-l10n/git-po/ As how to update your XX.po and help to translate Git, please see "Updating a XX.po file" and other sections in “po/README" file.

hope you remember me???

Hello dear, I am Miss Makena Jelani. hope you remember me? is been a long time, where have you been. well, contact me so we can talk Makena.

Re: [PATCH] archive-tar: fix a sparse 'constant too large' warning

On 04/05/17 10:26, Johannes Schindelin wrote: > Hi Ramsay, > > On Thu, 4 May 2017, Ramsay Jones wrote: > >> diff --git a/archive-tar.c b/archive-tar.c >> index 319a5b1c7..6dddc0cff 100644 >> --- a/archive-tar.c >> +++ b/archive-tar.c >> @@ -33,7 +33,7 @@ static int

Re: What's cooking in git.git (May 2017, #01; Mon, 1)

On 01/05/17 06:35, Junio C Hamano wrote: > > * nd/fopen-errors (2017-04-23) 17 commits > - warn_failure_to_open_read_optional_path(): a new helper > - t1308: add a test case on open a config directory > - config.c: handle error on failing to fopen() > - xdiff-interface.c: report errno on

Re: Delta compression hooks

On 2017-05-04 07:57 PM, Stefan Beller wrote: On Thu, May 4, 2017 at 3:48 PM, Soni L. wrote: Can we get delta compression hooks? I'm working with voxel data as my source code (it's a long story...) and git doesn't handle changing lines of voxels very well. Example, I

Re: Delta compression hooks

On Thu, May 4, 2017 at 3:48 PM, Soni L. wrote: > Can we get delta compression hooks? I'm working with voxel data as my source > code (it's a long story...) and git doesn't handle changing lines of voxels > very well. > > Example, I have something from position (0,0,0) to

Delta compression hooks

Can we get delta compression hooks? I'm working with voxel data as my source code (it's a long story...) and git doesn't handle changing lines of voxels very well. Example, I have something from position (0,0,0) to position (0,10,0) and I replace it with something else. Git doesn't handle

[PATCH 6/7] fixup! compat/regex: update the gawk regex engine from upstream

--- compat/regex/regex.h | 120 +--- compat/regex/regexec.c | 242 + 2 files changed, 193 insertions(+), 169 deletions(-) diff --git a/compat/regex/regex.h b/compat/regex/regex.h index 61c9683872..b602b5567f 100644 ---

[PATCH 7/7] fixup! compat/regex: update the gawk regex engine from upstream

--- compat/regex/intprops.h | 448 compat/regex/verify.h | 286 +++ 2 files changed, 734 insertions(+) create mode 100644 compat/regex/intprops.h create mode 100644 compat/regex/verify.h diff --git

[PATCH 3/7] fixup! compat/regex: update the gawk regex engine from upstream

--- compat/regex/regcomp.c | 356 + 1 file changed, 209 insertions(+), 147 deletions(-) diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c index d8bde06f1a..a1fb2e400e 100644 --- a/compat/regex/regcomp.c +++ b/compat/regex/regcomp.c @@

[PATCH 5/7] fixup! compat/regex: update the gawk regex engine from upstream

--- compat/regex/regex_internal.c | 118 +- compat/regex/regex_internal.h | 118 ++ 2 files changed, 144 insertions(+), 92 deletions(-) diff --git a/compat/regex/regex_internal.c b/compat/regex/regex_internal.c index

[PATCH 4/7] fixup! compat/regex: update the gawk regex engine from upstream

--- compat/regex/regex.c | 32 ++-- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/compat/regex/regex.c b/compat/regex/regex.c index 5cb23e5d59..d6e525e567 100644 --- a/compat/regex/regex.c +++ b/compat/regex/regex.c @@ -1,5 +1,12 @@ +/* + * This is

[PATCH 2/7] compat/regex: update the gawk regex engine from upstream

Update the gawk regex engine from the upstream gawk.git as detailed in the README added in a previous change. This is from gawk.git's gawk-4.1.0-2558-gb2651a80 which is the same code as in the stable gawk-4.1.4 release, but with one trivial change on top added in commit 725d2f78 ("Add small regex

[PATCH 1/7] compat/regex: add a README with a maintenance guide

Add a README file to compat/regex describing how the copy of the gawk engine should be maintained. Since gawk's regex engine was originally imported in git.git in commit d18f76dccf ("compat/regex: use the regex engine from gawk for compat", 2010-08-17) the Git project has forked the upstream

[PATCH 0/7] Update the compat/regex engine from upstream

See the first patch for motivation & why. The only reason this has a cover letter is to explain the !fixup commits. IIRC the mailing list has a 100K limit, which this series would violate, so I split up the second commit. Consider all these !fixup commits to have by Signed-off-by, easier to say

Re: [PATCH] fast-export: deletion action first

The previous patch reorders the delete operations in fast-export (preceding any other one), keeps renaming as last operations to process (as original source code) and for any other operation it keeps the same order as "diff" The non deterministic reordering was one of the concerns when I first

[RESEND PATCH] diff: recurse into nested submodules for inline diff

When fd47ae6a5b (diff: teach diff to display submodule difference with an inline diff, 2016-08-31) was introduced, we did not think of recursing into nested submodules. When showing the inline diff for submodules, automatically recurse into nested submodules as well with inline submodule diffs.

not uptodate. Cannot merge

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 same problem. Now, I'm pretty far from Kansas here as

[PATCH] fast-export: deletion action first

The delete operations of the fast-export output should precede any addition belonging to the same commit, Addition and deletion with the same name entry could happen in case of file to directory and viceversa. As an equal comparison doesn't have any deterministic final order, it's better to keep

Re: [PATCH 0/5] Start of a journey: drop NO_THE_INDEX_COMPATIBILITY_MACROS

Hi, Junio C Hamano wrote: > Duy Nguyen writes: >> I attempted the same thing once or twice in the past, had the same >> impression and dropped it. But I think it's good to get rid of cache_* >> macros, at least outside builtin/ directory. > > One thing that needs to be kept

Mr Neil Trotter

Eine Spende von 1 Million Britische Pfund zu Ihnen in gutem Glauben

Re: [PATCH 0/5] Abide by our own rules regarding line endings

Hi Junio, On Thu, 4 May 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Well, a couple of comments about your comment: > > > > - we say "shell scripts", but we're sloppy there: they are "Unix shell > > scripts", as they are executed by Unix shells.

Re: [PATCH 00/10] RFC Partial Clone and Fetch

Hi again, Jeff Hostetler wrote: > In my original RFC there were comments/complaints that with > missing blobs we lose the ability to detect corruptions. My > proposed changes to index-pack and rev-list (and suggestions > for other commands like fsck) just disabled those errors. > Personally,

Re: [PATCH 0/5] Start of a journey: drop NO_THE_INDEX_COMPATIBILITY_MACROS

On Wed, May 3, 2017 at 7:48 PM, Junio C Hamano wrote: > Duy Nguyen writes: > In the long run we may want to drop the macros guarded by NO_THE_INDEX_COMPATIBILITY_MACROS. This converts a couple of them. >>> >>> Why? >> >> Well.. why did you add

Re: [PATCH v5] l10n: de.po: update German translation

Acked-by: Matthias Rüster Am 04.05.2017 um 19:08 schrieb Ralf Thielow: > Translate 96 new messages came from git.pot update in dfc182b (l10n: > git.pot: v2.13.0 round 1 (96 new, 37 removed)). > > Signed-off-by: Ralf Thielow > --- > po/de.po

Re: Proposal for missing blob support in Git repos

On 05/03/2017 09:29 PM, Junio C Hamano wrote: Jonathan Tan writes: I see the semantics as "don't write what you already have", where "have" means what you have in local storage, but if you extend "have" to what upstream has, then yes, you're right that this changes

[PATCH v5] l10n: de.po: update German translation

Translate 96 new messages came from git.pot update in dfc182b (l10n: git.pot: v2.13.0 round 1 (96 new, 37 removed)). Signed-off-by: Ralf Thielow --- po/de.po | 325 --- 1 file changed, 143 insertions(+), 182

Re: [PATCH 00/10] RFC Partial Clone and Fetch

On 5/3/2017 2:27 PM, Jonathan Nieder wrote: Hi, Jeff Hostetler wrote: Missing-Blob Support Let me offer up an alternative idea for representing missing blobs. This is differs from both of our previous proposals. (I don't have any code for this new proposal, I just

Re: Bug? git svn tag Authentication failed

Ethan Clevenger wrote: > Git version: 2.12.2.windows.2 > > `git svn tag 1.0` results in: Note, "git svn tag" uses the same backend code as "git svn branch", and there was a recent fix for that in commit e0688e9b28f2c5ff711460ee8b62077be5df2360 ("git svn: fix

Bug? git svn tag Authentication failed

Git version: 2.12.2.windows.2 `git svn tag 1.0` results in: > Copying https://plugins.svn.wordpress.org/gf-payment-continue/trunk at > r1651123 to https://plugins.svn.wordpress.org/gf-payment-continue/tags/1.0... > Authentication failed: No more credentials or we tried too many times. >

[ANNOUNCE] Git v2.13.0-rc2

A release candidate Git v2.13.0-rc2 is now available for testing at the usual places. It is comprised of 699 non-merge commits since v2.12.0, contributed by 59 people, 15 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

Re: [PATCH 0/5] Abide by our own rules regarding line endings

Johannes Schindelin writes: > Well, a couple of comments about your comment: > > - we say "shell scripts", but we're sloppy there: they are "Unix shell > scripts", as they are executed by Unix shells. As such, it is pretty > obvious that they favor Unix line

Re: git v2.13.0-rc0 test failures on cygwin

On Fri, Apr 28, 2017 at 03:20:21PM -0400, Devin Lehmacher wrote: > > > Test Summary Report > > > --- > > > t0301-credential-cache.sh(Wstat: 256 Tests: 29 > > > Failed: 6) > > > Failed tests: 12, 24-28 > > > Non-zero exit status: 1 > > > > Confirmed I'm

[PATCH v4 23/25] name-rev: avoid leaking memory in the `deref` case

When the `name_rev()` function is asked to dereference the tip name, it allocates memory. But when it turns out that another tip already described the commit better than the current one, we forgot to release the memory. Pointed out by Coverity. Signed-off-by: Johannes Schindelin

[PATCH v4 25/25] submodule_uses_worktrees(): plug memory leak

There is really no reason why we would need to hold onto the allocated string longer than necessary. Reported by Coverity. Signed-off-by: Johannes Schindelin --- worktree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/worktree.c b/worktree.c

[PATCH v4 24/25] show_worktree(): plug memory leak

The buffer allocated by shorten_unambiguous_ref() needs to be released. Discovered by Coverity. Signed-off-by: Johannes Schindelin --- builtin/worktree.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/builtin/worktree.c

[PATCH v4 15/25] pack-redundant: plug memory leak

Identified via Coverity. Signed-off-by: Johannes Schindelin --- builtin/pack-redundant.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/pack-redundant.c b/builtin/pack-redundant.c index 72c815844dd..cb1df1c7614 100644 --- a/builtin/pack-redundant.c +++

[PATCH v4 22/25] remote: plug memory leak in match_explicit()

The `guess_ref()` returns an allocated buffer of which `make_linked_ref()` does not take custody (`alloc_ref()` makes a copy), therefore we need to release the buffer afterwards. Noticed via Coverity. Signed-off-by: Johannes Schindelin --- remote.c | 5 +++-- 1 file

[PATCH v4 13/25] setup_bare_git_dir(): help static analysis

Coverity reported a memory leak in this function. However, it can only be called once, as setup_git_directory() changes global state and hence is not reentrant. Mark the variable as static to indicate that this is a singleton. Signed-off-by: Johannes Schindelin ---

[PATCH v4 16/25] mktree: plug memory leaks reported by Coverity

Signed-off-by: Johannes Schindelin --- builtin/mktree.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/builtin/mktree.c b/builtin/mktree.c index de9b40fc63b..da0fd8cd706 100644 --- a/builtin/mktree.c +++ b/builtin/mktree.c @@ -72,7 +72,7 @@

[PATCH v4 21/25] add_reflog_for_walk: avoid memory leak

We free()d the `log` buffer when dwim_log() returned 1, but not when it returned a larger value (which meant that it still allocated the buffer but we simply ignored it). While in the vicinity, make sure that the `reflogs` structure as well as the `branch` variable are released properly, too.

[PATCH v4 20/25] shallow: avoid memory leak

Reported by Coverity. Signed-off-by: Johannes Schindelin --- shallow.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/shallow.c b/shallow.c index 25b6db989bf..f9370961f99 100644 --- a/shallow.c +++ b/shallow.c @@ -473,11 +473,15 @@ static

[PATCH v4 17/25] fast-export: avoid leaking memory in handle_tag()

Reported by, you guessed it, Coverity. Signed-off-by: Johannes Schindelin --- builtin/fast-export.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/fast-export.c b/builtin/fast-export.c index e0220630d00..64617ad8e36 100644 --- a/builtin/fast-export.c

[PATCH v4 12/25] split_commit_in_progress(): simplify & fix memory leak

This function did a whole lot of unnecessary work, such as reading in four files just to figure out that, oh, hey, we do not need to look at them after all because the HEAD is not detached. Simplify the entire function to return early when possible, to read in the files only when necessary, and

[PATCH v4 14/25] setup_discovered_git_dir(): plug memory leak

The setup_explicit_git_dir() function does not take custody of the string passed as first parameter; we have to release it if we turned the value of git_dir into an absolute path. Signed-off-by: Johannes Schindelin --- setup.c | 9 +++-- 1 file changed, 7

[PATCH v4 19/25] line-log: avoid memory leak

Discovered by Coverity. Signed-off-by: Johannes Schindelin --- line-log.c | 1 + 1 file changed, 1 insertion(+) diff --git a/line-log.c b/line-log.c index a23b910471b..b9087814b8c 100644 --- a/line-log.c +++ b/line-log.c @@ -1125,6 +1125,7 @@ static int

[PATCH v4 18/25] receive-pack: plug memory leak in update()

Reported via Coverity. Signed-off-by: Johannes Schindelin --- builtin/receive-pack.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index f96834f42c9..48c07ddb659 100644 ---

[PATCH v4 11/25] checkout: fix memory leak

This change addresses part of the NEEDSWORK comment above the code, therefore the comment needs to be adjusted, too. Discovered via Coverity. Signed-off-by: Johannes Schindelin --- builtin/checkout.c | 17 + 1 file changed, 9 insertions(+), 8

[PATCH v4 10/25] cat-file: fix memory leak

Discovered by Coverity. Signed-off-by: Johannes Schindelin --- builtin/cat-file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/cat-file.c b/builtin/cat-file.c index 1890d7a6390..9af863e7915 100644 --- a/builtin/cat-file.c +++ b/builtin/cat-file.c @@

[PATCH v4 01/25] mingw: avoid memory leak when splitting PATH

In the (admittedly, concocted) case that PATH consists only of path delimiters, we would leak the duplicated string. Reported by Coverity. Signed-off-by: Johannes Schindelin --- compat/mingw.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v4 09/25] mailinfo & mailsplit: check for EOF while parsing

While POSIX states that it is okay to pass EOF to isspace() (and it seems to be implied that EOF should *not* be treated as whitespace), and also to pass EOF to ungetc() (which seems to be intended to fail without buffering the character), it is much better to handle these cases explicitly. Not

[PATCH v4 02/25] winansi: avoid use of uninitialized value

To initialize the foreground color attributes of "plain text", our ANSI emulation tries to infer them from the currently attached console while running the is_console() function. This function first tries to detect any console attached to stdout, then it is called with stderr. If neither stdout

[PATCH v4 00/25] Address a couple of issues identified by Coverity

I recently registered the git-for-windows fork with Coverity to ensure that even the Windows-specific patches get some static analysis love. While at it, I squashed a couple of obvious issues in the part that is not Windows-specific. Note: while this patch series squashes some of those issues,

[PATCH v4 03/25] winansi: avoid buffer overrun

When we could not convert the UTF-8 sequence into Unicode for writing to the Console, we should not try to write an insanely-long sequence of invalid wide characters (mistaking the negative return value for an unsigned length). Reported by Coverity. Signed-off-by: Johannes Schindelin

[PATCH v4 08/25] status: close file descriptor after reading git-rebase-todo

Reported via Coverity. Signed-off-by: Johannes Schindelin --- wt-status.c | 1 + 1 file changed, 1 insertion(+) diff --git a/wt-status.c b/wt-status.c index 03754849626..0a6e16dbe0f 100644 --- a/wt-status.c +++ b/wt-status.c @@ -1168,6 +1168,7 @@ static int

[PATCH v4 06/25] get_mail_commit_oid(): avoid resource leak

When we fail to read, or parse, the file, we still want to close the file descriptor and release the strbuf. Reported via Coverity. Signed-off-by: Johannes Schindelin --- builtin/am.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git

[PATCH v4 05/25] git_config_rename_section_in_file(): avoid resource leak

In case of errors, we really want the file descriptor to be closed. Discovered by a Coverity scan. Signed-off-by: Johannes Schindelin --- config.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/config.c b/config.c index

[PATCH v4 04/25] add_commit_patch_id(): avoid allocating memory unnecessarily

It would appear that we allocate (and forget to release) memory if the patch ID is not even defined. Reported by the Coverity tool. Signed-off-by: Johannes Schindelin --- patch-ids.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/patch-ids.c

[PATCH v4 07/25] difftool: address a couple of resource/memory leaks

This change plugs a couple of memory leaks and makes sure that the file descriptor is closed in run_dir_diff(). Spotted by Coverity. Signed-off-by: Johannes Schindelin --- builtin/difftool.c | 33 +++-- 1 file changed, 23 insertions(+),

Re: [PATCH v3] l10n: de.po: update German translation

2017-05-03 21:27 GMT+02:00 Christian Brabandt : > On Mi, 03 Mai 2017, Ralf Thielow wrote: > >> Ref or Reference is translated as "Referenz" while >> Rev or Revision is translated as "Commit" so I think >> the translation is correct. > > Oh right. I also noticed that sometimes

Re: [PATCH v4] l10n: de.po: update German translation

2017-05-03 19:29 GMT+02:00 Matthias Rüster : > Hi Ralf, > > thanks again for your work! > > >> >> #: ref-filter.c:565 >> -#, fuzzy, c-format >> +#, c-format >> msgid "format: %%(then) atom used after %%(else)" >> -msgstr "Format: %%(end) Atom fehlt" >> +msgstr

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

On Thu, May 4, 2017 at 1:32 PM, Johannes Schindelin wrote: > Hi Ævar, > > On Thu, 4 May 2017, Ævar Arnfjörð Bjarmason wrote: > >> So I think if your criteria for working on integrating v2 is users >> noticing it elsewhere and asking you for it you'll likely never

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

Hi Ævar, On Thu, 4 May 2017, Ævar Arnfjörð Bjarmason wrote: > So I think if your criteria for working on integrating v2 is users > noticing it elsewhere and asking you for it you'll likely never switch > to it. Speaking for myself, my biggest problem with your patch series is to find the time

Re: CYGWIN git cannot install python packages with pip

Hi, On Thu, 4 May 2017, ankostis wrote: > On 4 May 2017 at 11:47, Adam Dinwoodie wrote: > > Confirmed: the Cygwin project as a general rule doesn't support this > > sort of mixing of Windows and Cygwin tools. Either use Python and Git > > packages both provided by Cygwin,

Re: [PATCH v3 12/25] split_commit_in_progress(): fix memory leak

Hi René, On Wed, 3 May 2017, René Scharfe wrote: > Am 02.05.2017 um 18:02 schrieb Johannes Schindelin: > > Reported via Coverity. > > > > Signed-off-by: Johannes Schindelin > > --- > > wt-status.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) >

RE: Donation Award

Good Day, My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from part of our Jackpot Lottery of 50 Million Dollars, respond with your details for claims. We await your earliest response and God Bless you. Friedrich And Annand Mayrhofer. --- This email has been checked

Re: [PATCH v3 01/25] mingw: avoid memory leak when splitting PATH

Hi René, On Wed, 3 May 2017, René Scharfe wrote: > Am 02.05.2017 um 18:00 schrieb Johannes Schindelin: > > In the (admittedly, concocted) case that PATH consists only of colons, we > > would leak the duplicated string. > > Nit: It's about semicolons, right? At least that's what get_path_split

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

On Thu, May 4, 2017 at 11:11 AM, Johannes Schindelin wrote: > Hi Ævar, > > On Wed, 3 May 2017, Ævar Arnfjörð Bjarmason wrote: > >> [Just replying to you & Duy in the same mail, easier] > > It makes it harder on everybody else, though, as two slightly different >

Re: [PATCH v3 02/25] winansi: avoid use of uninitialized value

Hi René, On Wed, 3 May 2017, René Scharfe wrote: > Am 02.05.2017 um 18:01 schrieb Johannes Schindelin: > > > > diff --git a/compat/winansi.c b/compat/winansi.c > > index 793420f9d0d..fd6910746c8 100644 > > --- a/compat/winansi.c > > +++ b/compat/winansi.c > > @@ -105,6 +105,8 @@ static int

Re: CYGWIN git cannot install python packages with pip

On 4 May 2017 at 11:47, Adam Dinwoodie wrote: > Confirmed: the Cygwin project as a general rule doesn't support this > sort of mixing of Windows and Cygwin tools. Either use Python and Git > packages both provided by Cygwin, or both provided by Windows. > > Mixing and

RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required

My point was to ensure that where English is used on-screen it should make sense, which in this particular case it didn't (a French idiom which, on using an automatic translator, didn't make sense in English). The same of course applies to other languages used on-screen. I agree about

[PATCH v2 7/7] t4051: mark supporting files as requiring LF-only line endings

The test t4051-diff-function-context.sh passes on Linux when core.autocrlf=true even without marking its support files as LF-only, but they fail when core.autocrlf=true in Git for Windows' SDK. The reason is that `grep ... >file.c.new` will keep CR/LF line endings on Linux (obviously treating CRs

[PATCH v2 6/7] Fix the remaining tests that failed with core.autocrlf=true

The test suite is mainly developed on Linux and MacOSX, which is the reason that nobody thought to mark files as LF-only as needed. The symptom is a test suite that fails left and right when being checked out using Git for Windows (which defaults to core.autocrlf=true). Mostly, the problems stem

[PATCH v2 3/7] completion: mark bash script as LF-only

Without this change, the completion script does not work, as Bash expects its scripts to have line feeds as end-of-line markers (this is particularly prominent in quoted multi-line strings, where carriage returns would slip into the strings as verbatim characters otherwise). This change is

[PATCH v2 5/7] t4003, t4005, t4007 & t4008: handle CR/LF in t/README & t/diff-lib/README

Seeing as Git originates from the Linux ecosystem, it is understandable that the assumption of Unix line endings is deeply ingrained in Git's source code as well as its test suite. However, we must not force files that are otherwise unrelated to tests to have Unix line endings just to appease

[PATCH v2 4/7] t3901: move supporting files into t/t3901/

The current convention is to either generate files on the fly in tests, or to use supporting files taken from a t/t/ directory (where matches the test's number, or the number of the test from which we borrow supporting files). The test t3901-i18n-patch.sh was obviously introduced before

[PATCH v2 2/7] git-new-workdir: mark script as LF-only

Bash does not handle scripts with CR/LF line endings correctly, therefore they *have* to be forced to LF-only line endings. Funnily enough, this fixes t3000-ls-files-others and t1021-rerere-in-workdir when git.git was checked out with core.autocrlf=true, as these test still use git-new-workdir

[PATCH v2 1/7] Fix build with core.autocrlf=true

On Windows, the default line endings are denoted by a Carriage Return byte followed by a Line Feed byte, while Linux and MacOSX use a single Line Feed byte to denote a line ending. To help with this situation, Git introduced several mechanisms over the last decade, most prominently the

[PATCH v2 0/7] Abide by our own rules regarding line endings

[Cc:ing Jonathan Nieder, who reviewed the first iteration of this patch series, and Jeff Hostetler who is guilty of prodding me into finishing this patch series in the first place.] Over the past decade, there have been a couple of attempts to remedy the situation regarding line endings

Re: CYGWIN git cannot install python packages with pip

On Wed, May 03, 2017 at 04:32:15PM +0200, Johannes Schindelin wrote: > On Wed, 3 May 2017, ankostis wrote: > > > On 3 May 2017 11:47, Johannes Schindelin wrote: > > > On Tue, 2 May 2017, ankostis wrote: > > > > > >> On Windows, with Cygwin-git 02.12.2-1 the python command: > > >> [...] > > > > >

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

Le jeudi 4 mai 2017, 08:52:43 CEST Kerry, Richard a écrit : > > May I suggest that " The most approaching commands" doesn't make much sense > as English (I don't think a command can "approach"). > Perhaps it should be " The most appropriate commands". > > > Regards, > Richard. > Thank you

Re: [PATCH] __git_ps1: Don't kill shell if user types `set -e`

On 04/05/17 16:16, Ævar Arnfjörð Bjarmason wrote: > What's the real use-case here? If you do "set -e" in your shell you > also get e.g.: > > $ ls -l blah > ls: cannot access blah: No such file or directory > === Command terminated with exit status 2 (Thu May 4 11:16:03 2017) === >

Re: [PATCH] archive-tar: fix a sparse 'constant too large' warning

Hi Ramsay, On Thu, 4 May 2017, Ramsay Jones wrote: > diff --git a/archive-tar.c b/archive-tar.c > index 319a5b1c7..6dddc0cff 100644 > --- a/archive-tar.c > +++ b/archive-tar.c > @@ -33,7 +33,7 @@ static int write_tar_filter_archive(const struct archiver > *ar, > #if TIME_MAX == 0x >

Re: [PATCH v2] travis-ci: retry if Git for Windows CI returns HTTP error 502 or 503

Hi Lars, On Wed, 3 May 2017, Lars Schneider wrote: > The Git for Windows CI web app sometimes returns HTTP errors of > "502 bad gateway" or "503 service unavailable" [1]. We also need to > check the HTTP content because the GfW web app seems to pass through > (error) results from other Azure

Re: [PATCH] __git_ps1: Don't kill shell if user types `set -e`

On Thu, May 4, 2017 at 10:26 AM, Tom Hale wrote: > > On 17/04/17 11:24, Junio C Hamano wrote: >> "Tom \"Ravi\" Hale" writes: >> >> > If a user types `set -e` in an interactive shell, and is using __git_ps1 >> > to set >> > their prompt, the shell will die if the

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

Hi Ævar, On Wed, 3 May 2017, Ævar Arnfjörð Bjarmason wrote: > [Just replying to you & Duy in the same mail, easier] It makes it harder on everybody else, though, as two slightly different discussion points are conflated now. Also, no single online mail archive will be able to render the thread

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard wrote: > > May I suggest that " The most approaching commands" doesn't make much sense > as English (I don't think a command can "approach"). > Perhaps it should be " The most appropriate commands". I had the same concern,

  1   2   >