Re: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

Am 15.01.2018 um 03:37 schrieb Randall S. Becker: On January 14, 2018 4:33 PM, I wrote: The exotic error code coming back from perl is 162. I can muck with it, if there was a value more useful to git. * 553 } else if (WIFEXITED(status)) { * 554 code =

Re: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

Am 14.01.2018 um 17:50 schrieb Randall S. Becker: Follow-up: This looks like the completion code from perl on NonStop is not the same as expected by git in the case of failures. I need to debug this to get more details to the team. We have had completion issues before relating to interpretation

Re: [PATCH] run-command.c: print env vars when GIT_TRACE is set

Am 11.01.2018 um 11:07 schrieb Jeff King: The output for a single command is pretty shell-like due to the quoting: $ GIT_TRACE=1 ./git upload-pack . >/dev/null [...]run_command: 'git-upload-pack' '.' You could copy and paste that to a shell if you wanted. And with environment variables,

Re: [PATCH] t3900: add some more quotes

Am 10.01.2018 um 10:58 schrieb Beat Bolli: In 89a70b80 ("t0302 & t3900: add forgotten quotes", 2018-01-03), quotes were added to protect against spaces in $HOME. In the test_when_finished hander, two files are deleted which must be quoted individually. Signed-off-by: Beat Bolli

Re: [PATCH] Prototype PATH_MAX length detection in tests, demonstrated in t0001-init.sh

Am 10.01.2018 um 01:12 schrieb Randall S. Becker: > On January 9, 2018 6:01 PM, Johannes Sixt wrote: > I'm encountering strange warnings, while looking into the details of what > test t0001 fails in spots. These include: > #24 warning: templates not found x00...[lots of

Re: [git-for-windows] Re: [ANNOUNCE] Git v2.16.0-rc1

Am 10.01.2018 um 18:37 schrieb Johannes Schindelin: On Tue, 9 Jan 2018, Junio C Hamano wrote: Johannes Schindelin writes: diff --git a/t/t0021/rot13-filter.pl b/t/t0021/rot13-filter.pl index f1678851de9..470107248eb 100644 --- a/t/t0021/rot13-filter.pl +++

Re: [PATCH] Prototype PATH_MAX length detection in tests, demonstrated in t0001-init.sh

Am 09.01.2018 um 19:12 schrieb Randall S. Becker: This patch create a configuration variable PATH_MAX that corresponds with the value in limits.h. The value of PATH_MAX, if supplied, is added to BASIC_CFLAGS and will validate with limits.h. PATH_MAX is also added to GIT-BUILD-OPTIONS and is

Re: [PATCH] oidset: don't return value from oidset_init

Am 09.01.2018 um 00:26 schrieb Junio C Hamano: Thomas Gummerer writes: c3a9ad3117 ("oidset: add iterator methods to oidset", 2017-11-21) introduced a 'oidset_init()' function in oidset.h, which has void as return type, but returns an expression. ... diff --git a/oidset.h

Re: [PATCH v5 00/34] Add directory rename detection to git

Am 03.01.2018 um 22:02 schrieb Elijah Newren: On Wed, Jan 3, 2018 at 2:57 AM, Johannes Sixt <j...@kdbg.org> wrote: I tested the series on Windows recently. It requires the patch below. I don't know whether this is indicating some portability issues of grep (^ being used in the middle o

Re: [PATCH v5 00/34] Add directory rename detection to git

rty file at z/c ++ grep -q stuff x/b y/a y/c y/c~HEAD z/c grep: y/c: Invalid request code error: last command exited with $?=2 not ok 94 - 11d-check: Avoid losing not-uptodate with rename + D/F conflict I haven't debugged this any further, yet. ---- 8< ---- From: Johannes Sixt <j...@kdbg.org>

Re: [PATCH 4/4] branch: add '--show-description' option

Am 01.01.2018 um 23:54 schrieb SZEDER Gábor: 'git branch' has an option to edit a branch's description, but lacks the option to show that description. Therefore, add a new '--show-description' option to do just that, as a more user-friendly alternative to 'git config --get

Re: Improved error handling (Was: [PATCH 1/2] sequencer: factor out rewrite_file())

Am 24.12.2017 um 15:54 schrieb Jeff King: On Sat, Nov 18, 2017 at 10:01:45AM +0100, Johannes Sixt wrote: Yeah, I have mixed feelings on that. I think it does make the control flow less clear. At the same time, what I found was that handlers like die/ignore/warn were the thing that gave

Re: [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory

Am 25.12.2017 um 01:28 schrieb Ævar Arnfjörð Bjarmason: +create_test_file() { + file=$1 + + case $file in + # `touch .` will succeed but obviously not do what we intend + # here. + ".") + return 1 + ;; + # We cannot create a file

Re: [PATCH 6/6] wildmatch test: create & test files on disk in addition to in-memory

Am 24.12.2017 um 12:06 schrieb Ævar Arnfjörð Bjarmason: On Sun, Dec 24 2017, Johannes Sixt jotted: Am 23.12.2017 um 22:30 schrieb Ævar Arnfjörð Bjarmason: + printf '%s' '$text' >expect && There are no single-quotes in any $text instances, right

Re: [PATCH 6/6] wildmatch test: create & test files on disk in addition to in-memory

Am 23.12.2017 um 22:30 schrieb Ævar Arnfjörð Bjarmason: > Signed-off-by: Ævar Arnfjörð Bjarmason > --- > a[]b | 0 > t/t3070-wildmatch.sh | 336 > --- > 2 files changed, 319 insertions(+), 17 deletions(-) >

Re: [PATCH v1] convert: add support for 'encoding' attribute

Am 18.12.2017 um 11:13 schrieb Torsten Bögershausen: Just to confirm my missing knowledge here: Does this mean, that git-gui and gitk can decode/reencode the content of a file/blob, when the .gitattributes say so ? No. I think they parse the output of git-diff et.al., split it per file, and

Re: [PATCH v1] convert: add support for 'encoding' attribute

Am 12.12.2017 um 01:59 schrieb Junio C Hamano: Stepping back a bit, what does this thing do you are introducing? And what does the other thing do that J6t is using, that would get confused with this new one? What does the other one do? "Declare that the contents of this path is in this

Re: [PATCH v1] convert: add support for 'encoding' attribute

Am 12.12.2017 um 00:42 schrieb Lars Schneider: BTW: I am curios, can you share what encoding you use? My main use case is UTF-16 and I was surprised that I haven't found a single public repo on github.com with "encoding=utf-16" Shift-JIS and CP1252. These are used for Windows resource files

Re: [PATCH v1] convert: add support for 'encoding' attribute

Am 11.12.2017 um 16:50 schrieb lars.schnei...@autodesk.com: From: Lars Schneider Git and its tools (e.g. git diff) expect all text files in UTF-8 encoding. Git will happily accept content in all other encodings, too, but it might not be able to process the text (e.g.

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

I am sorry for not responding in detail. I think we've reached a mutual understanding of our workflows. Though, from the ideas you tossed around most recently, you seem to want to make git-commit into a kitchen-sink for everything. I have my doubts that this will be a welcome change. Just

Re: [PATCH v4 1/4] Makefile: generate Perl header from template file

Am 05.12.2017 um 22:35 schrieb Junio C Hamano: > Dan Jacques writes: > >> Thanks for checking! The patch that you quoted above looks like it's from >> this "v4" thread; however, the patch that you are diffing against in your >> latest reply seems like it is from an earlier

Re: [PATCH v4 1/4] Makefile: generate Perl header from template file

Am 01.12.2017 um 18:25 schrieb Johannes Sixt: > Am 01.12.2017 um 18:13 schrieb Johannes Schindelin: >> Hi Hannes, >> >> On Fri, 1 Dec 2017, Johannes Sixt wrote: >> >>> Am 29.11.2017 um 16:56 schrieb Dan Jacques: >>>> @@ -1989,6 +1986,15 @@ GIT-PE

Re: [PATCH v4 1/4] Makefile: generate Perl header from template file

Am 01.12.2017 um 18:13 schrieb Johannes Schindelin: Hi Hannes, On Fri, 1 Dec 2017, Johannes Sixt wrote: Am 29.11.2017 um 16:56 schrieb Dan Jacques: @@ -1989,6 +1986,15 @@ GIT-PERL-DEFINES: FORCE echo "$$FLAGS" >$@; \ fi +GIT-PERL-HEADER: $(PERL_HEADER_

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Am 30.11.2017 um 00:10 schrieb Igor Djordjevic: On 29/11/2017 20:11, Johannes Sixt wrote: With git-post, I make a fixup commit commit on the integration branch, then `git post B && git merge B`: ...A...C <- topics A, C \ \ ---o---o---o-

Re: [PATCH v4 1/4] Makefile: generate Perl header from template file

Am 29.11.2017 um 16:56 schrieb Dan Jacques: @@ -1989,6 +1986,15 @@ GIT-PERL-DEFINES: FORCE echo "$$FLAGS" >$@; \ fi +GIT-PERL-HEADER: $(PERL_HEADER_TEMPLATE) GIT-PERL-DEFINES perl/perl.mak Makefile + $(QUIET_GEN)$(RM) $@ && \ + INSTLIBDIR=`MAKEFLAGS=

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Am 28.11.2017 um 02:15 schrieb Igor Djordjevic: On 27/11/2017 22:54, Johannes Sixt wrote: I my opinion, putting the focus on integration merge commits and the desire to automate the re-merge step brings in a LOT of complexity in the implementation for a very specific use-case that does

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Am 26.11.2017 um 23:35 schrieb Igor Djordjevic: Approach discussed here could have a few more useful applications, but one seems to be standing out the most - in case where multiple topic branches are temporarily merged for integration testing, it could be very useful to be able to post "hotfix"

Re: [PATCH 2/2] Reduce performance cost of the trace if trace category is disabled

Am 19.11.2017 um 01:42 schrieb gennady.kup...@gmail.com: +#define trace_printf_key(key, ...) \ + do {\ + if (trace_pass_fl(key)) \ +

Re: Improved error handling (Was: [PATCH 1/2] sequencer: factor out rewrite_file())

Am 17.11.2017 um 23:33 schrieb Jeff King: On Mon, Nov 06, 2017 at 05:13:15PM +0100, Simon Ruderich wrote: On Sat, Nov 04, 2017 at 10:07:00PM -0400, Jeff King wrote: Yes, I think what you've written here (and below) is quite close to the error_context patches I linked elsewhere in the thread.

Re: Consequences of CRLF in index?

Thank you for the clarification, it's much appreciated. -- Hannes

Re: Consequences of CRLF in index?

Am 26.10.2017 um 13:01 schrieb Lars Schneider: On 26 Oct 2017, at 09:09, Johannes Sixt <j...@kdbg.org> wrote: Am 25.10.2017 um 14:19 schrieb Johannes Schindelin: I envy you for the blessing of such a clean C++ source that you do not have any, say, Unix shell script in it. Try this, an

Re: Consequences of CRLF in index?

Am 25.10.2017 um 14:19 schrieb Johannes Schindelin: I envy you for the blessing of such a clean C++ source that you do not have any, say, Unix shell script in it. Try this, and weep: $ printf 'echo \\\r\n\t123\r\n' >a1 $ sh a1 a1: 2: a1: 123: not found I was bitten

Re: Consequences of CRLF in index?

Am 24.10.2017 um 19:48 schrieb Lars Schneider: I've migrated a large repo (110k+ files) with a lot of history (177k commits) and a lot of users (200+) to Git. Unfortunately, all text files in the index of the repo have CRLF line endings. In general this seems not to be a problem as the project

Re: [PATCH v2 1/1] completion: add remaining flags to checkout

Am 24.10.2017 um 15:19 schrieb Thomas Braun: In the commits 1fc458d9 (builtin/checkout: add --recurse-submodules switch, 2017-03-14), 08d595dc (checkout: add --ignore-skip-worktree-bits in sparse checkout mode, 2013-04-13) and 32669671 (checkout: introduce --detach synonym for "git checkout

Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

Am 17.10.2017 um 01:01 schrieb Rafael Ascensao: This is worth discussing, though not my preference. The picture to "pick cherries" has become quite common, and now that we use it for the name of the command, "cherry-pick", the direction of flow is quite obvious and strongly implied: from

Re: Does Git build things during 'make install"?

Am 16.10.2017 um 10:23 schrieb Junio C Hamano: > Johannes Sixt <j...@kdbg.org> writes: > >> Yes, running "sudo make install" is a nightmare. sudo clears the path, >> and the git command is not found by the make invoked with root >> permissions. This chang

Re: Does Git build things during 'make install"?

Am 16.10.2017 um 07:05 schrieb Jeffrey Walton: My script to build Git dies during cleanup. Cleanup removes the downloaded tarball and the unpacked directory: ** Cleanup ** rm: cannot remove 'git-2.14.2/perl/blib/lib/.exists': Permission denied rm: cannot remove

Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

Am 13.10.2017 um 12:51 schrieb Ævar Arnfjörð Bjarmason: On Thu, Oct 05 2017, Johannes Sixt jotted: Am 05.10.2017 um 21:33 schrieb Stefan Beller: * Is it a good design choice to have a different command, just because the target branch is [not] checked out? I would not want to make

Re: [PATCH v1 1/1] completion: add remaining flags to checkout

Am 12.10.2017 um 18:50 schrieb Johannes Sixt: Am 12.10.2017 um 14:20 schrieb Thomas Braun: +    --force --ignore-skip-worktree-bits --ignore-other-worktrees Destructive and dangerous options are typically not offered by command completion. You should omit all three in the line above

Re: [PATCH v1 1/1] completion: add remaining flags to checkout

Am 12.10.2017 um 14:20 schrieb Thomas Braun: In the commits 1d0fa898 (checkout: add --ignore-other-wortrees, 2015-01-03), 1fc458d9 (builtin/checkout: add --recurse-submodules switch, 2017-03-14), 870ebdb9 (checkout: add --progress option, 2015-11-01), 08d595dc (checkout: add

Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

Am 05.10.2017 um 21:33 schrieb Stefan Beller: On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j...@kdbg.org> wrote: +git-post(1) +=== + +NAME + +git-post - Apply a commit on top of a branch that is not checked out Contrasted to: git-cherry-pick - Apply the changes intr

[PATCH/RFC] git-post: the opposite of git-cherry-pick

Add a new command that can be used to copy an arbitrary commit to a branch that is not checked out. Signed-off-by: Johannes Sixt <j...@kdbg.org> --- I have been using this command since years, but got around to write a man page and tests only now. I hope the man page makes sense. I don'

Re: [PATCH 3/3] sub-process: allocate argv on the heap

Am 04.10.2017 um 06:59 schrieb Junio C Hamano: Johannes Sixt <j...@kdbg.org> writes: Am 03.10.2017 um 21:57 schrieb Thomas Gummerer: diff --git a/sub-process.c b/sub-process.c index 6dde5062be..4680af8193 100644 --- a/sub-process.c +++ b/sub-process.c @@ -77,7 +77,9 @@ int subprocess

Re: [PATCH 3/3] sub-process: allocate argv on the heap

Am 03.10.2017 um 21:57 schrieb Thomas Gummerer: diff --git a/sub-process.c b/sub-process.c index 6dde5062be..4680af8193 100644 --- a/sub-process.c +++ b/sub-process.c @@ -77,7 +77,9 @@ int subprocess_start(struct hashmap *hashmap, struct subprocess_entry *entry, co { int err;

Re: what is git's position on "classic" mac -only end of lines?

Am 01.10.2017 um 21:29 schrieb Bryan Turner: On Sun, Oct 1, 2017 at 10:52 AM, Robert P. J. Day wrote: sorry for more pedantic nitpickery, but i'm trying to write a section on how to properly process mixtures of EOLs in git, and when i read "man git-config",

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Am 26.09.2017 um 20:54 schrieb Stefan Beller: +test_expect_success 'submodule update - command in .gitmodules is ignored' ' + test_when_finished "git -C super reset --hard HEAD^" && + + git -C super config -f .gitmodules submodule.submodule.update "!false" && + git -C super

Re: [PATCH] t7406: submodule..update command must not be run from .gitmodules

Am 26.09.2017 um 00:50 schrieb Stefan Beller: submodule..update can be assigned an arbitrary command via setting it to "!command". When this command is found in the regular config, Git ought to just run that command instead of other update mechanisms. However if that command is just found in

Re: [PATCH] git: add --no-optional-locks option

Am 21.09.2017 um 06:32 schrieb Jeff King: diff --git a/Documentation/git.txt b/Documentation/git.txt index 6e3a6767e5..8dd3ae05ae 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -159,6 +159,10 @@ foo.bar= ...`) sets `foo.bar` to the empty string which ` git config Add

Re: [Patch size_t V3 11/19] Use size_t for config parsing

Am 16.08.2017 um 22:16 schrieb Martin Koegler: > +int git_parse_size_t(const char *value, size_t *ret) > +{ > + uintmax_t tmp; > + if (!git_parse_unsigned(value, , > maximum_signed_value_of_type(size_t))) > + return 0; > + *ret = tmp; > + return 1; > +} > + I think

Re: How to force a push to succeed?

Am 23.08.2017 um 00:26 schrieb Jeffrey Walton: You know, I look at how fucked up yet another simple workflow is, and all I can do is wonder. It is absolutely amazing. Its like the project goes out of its way to make simple tasks difficult. No, no. So simple your task might look, in the end you

Re: [RFC 0/3] imap-send curl tunnelling support

Am 21.08.2017 um 09:27 schrieb Nicolas Morey-Chaisemartin: (Sent a reply from my phone while out of town but couldn't find it so here it is again) It's available on my github: https://github.com/nmorey/git/tree/dev/curl-tunnel The series had been stlighly changed since the patch were posted,

mk-dontmerge/size-t-on-next test failure

I observe the test failure below in t0040-parse-options.sh. It bisects to 1a7909b25eb4ab3071ce4290115618e2582eadaa "Convert pack-objects to size_t". It looks like git_parse_size_t() needs a fix. This is on Windows, 32 bit. size_t, int and long are all 32 bits wide. expecting success:

Re: Git *accepts* a branch name, it can't identity in the future?

Am 20.08.2017 um 09:51 schrieb Kaartic Sivaraam: I made a small assumption in the script which turned out to be false. I thought the unicode prefixes I used corresponded to only two bytes. This lead to the issue. The unicode character '✓' corresponds to three characters and as a result instead

Re: [PATCH 2/5] pack-objects: take lock before accessing `remaining`

Am 15.08.2017 um 14:53 schrieb Martin Ågren: When checking the conditional of "while (me->remaining)", we did not hold the lock. Calling find_deltas would still be safe, since it checks "remaining" (after taking the lock) and is able to handle all values. In fact, this could (currently) not

Re: [PATCH] t1002: stop using sum(1)

t capture the same thing? E.g., does it need a '! test_cmp frotz.M frotz &&' line? In the context that you stripped a 'diff frotz frotz1' occurs, i.e., a check for the expected content of the file whose content changes. Together with the new test_cmp lines, the new text is a stricter c

Re: [PATCH] tree-walk: convert fill_tree_descriptor() to object_id

Am 12.08.2017 um 09:14 schrieb René Scharfe: - Initialize a `tree_desc` and decode its first entry given the sha1 of - a tree. Returns the `buffer` member if the sha1 is a valid tree - identifier and NULL otherwise. + Initialize a `tree_desc` and decode its first entry

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

Am 07.08.2017 um 12:02 schrieb Johannes Schindelin: On Sun, 6 Aug 2017, Johannes Sixt wrote: Am 06.08.2017 um 01:00 schrieb Johannes Schindelin: * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/ git-for-windows/busybox-w32/commit/9480dca7c]. What

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

Am 06.08.2017 um 01:00 schrieb Johannes Schindelin: Dear Git users, It is my pleasure to announce that Git for Windows 2.14.0 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.13.3 (July 13th 2017) Thank you so much! One question, though: New

Re: reftable: new ref storage format

Am 16.07.2017 um 12:03 schrieb Jeff King: On Sun, Jul 16, 2017 at 10:07:57AM +0200, Johannes Sixt wrote: Am 14.07.2017 um 22:08 schrieb Jeff King: The implementation on this doesn't seem overly complex. My main concerns are what we're asking from the filesystem in terms of atomicity, and what

Re: reftable: new ref storage format

Am 14.07.2017 um 22:08 schrieb Jeff King: The implementation on this doesn't seem overly complex. My main concerns are what we're asking from the filesystem in terms of atomicity, and what possible races there are. One of the failure modes is that on Windows a file cannot be deleted while it

Re: [FEATURE] git-commit option to prepend filename to commit message

Am 15.07.2017 um 16:19 schrieb John J Foerch: The feature would be a command line option for git commit that would automatically prepend the ": " to the commit message. Write a prepare-commit-msg hook: https://www.kernel.org/pub/software/scm/git/docs/githooks.html#_prepare_commit_msg --

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

nteresting for other reasons. Johannes Sixt: It would be very nice to get those patches on-list. I don't think it's worth to swamp the list with the patches at this time. Interested parties can find them here: https://github.com/j6t/git.git c-plus-plus I may continue the work, slowly a

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

Am 12.07.2017 um 03:26 schrieb brian m. carlson: On Tue, Jul 11, 2017 at 07:24:07AM +0200, Johannes Sixt wrote: I can revive the patches if there is interest. I'd be interested in at least a pointer to them if you have one. I think it might allow us to take advantage of desirable features

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

Am 11.07.2017 um 02:05 schrieb brian m. carlson: On Mon, Jul 10, 2017 at 09:57:40PM +0200, Johannes Sixt wrote: It's a pity, though, that you do not suggest something even more useful, such as C++14. I have tried compiling Git with a C++ compiler, so that I could test whether

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

Am 10.07.2017 um 22:38 schrieb Junio C Hamano: Johannes Sixt <j...@kdbg.org> writes: It's a pity, though, that you do not suggest something even more useful, such as C++14. I cannot tell if this part is tongue-in-cheek (especially the "++"), so I will ignore it to av

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

Am 10.07.2017 um 09:03 schrieb Jeff King: On Sun, Jul 09, 2017 at 10:05:49AM -0700, Junio C Hamano wrote: René Scharfe writes: I wonder when we can begin to target C99 in git's source, though. :) Let's get the ball rolling... Good to know that you do not resist moving to a

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Am 16.06.2017 um 20:43 schrieb Johannes Sixt: Am 16.06.2017 um 15:49 schrieb Johannes Schindelin: On Thu, 15 Jun 2017, Junio C Hamano wrote: diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh index 325ec75353..801bce25da 100755 --- a/t/t3420-rebase-autostash.sh +++ b/t

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Am 16.06.2017 um 15:49 schrieb Johannes Schindelin: On Thu, 15 Jun 2017, Junio C Hamano wrote: diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh index 325ec75353..801bce25da 100755 --- a/t/t3420-rebase-autostash.sh +++ b/t/t3420-rebase-autostash.sh @@ -45,7 +45,7 @@

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

Am 01.06.2017 um 09:44 schrieb Junio C Hamano: * nd/fopen-errors (2017-05-30) 14 commits - mingw_fopen: report ENOENT for invalid file names - SQUASH??? use test_i18ngrep and add it at the end - mingw: verify that paths are not mistaken for remote nicknames - log: fix memory leak in

Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

Am 30.05.2017 um 06:46 schrieb Junio C Hamano: Johannes Sixt <j...@kdbg.org> writes: Doesn't this need test_i18ngrep?: Good catch! It would be this one in warn_on_inaccessible: wrapper.c:581: warning_errno(_("unable to access '%s'"), path); But actually, I'm mo

Re: Error with Templates: Could not find templates on cloning but on creating

Am 29.05.2017 um 13:20 schrieb Mathias Artus: Hi, Today i've tried to set up a template directory. I added in the system wide gitconfig the following lines: [init] templatedir = "//OurServer/SomeDirectory/GitTemplate" Where //Ourserver is a Network Path. With

Re: [PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

Am 29.05.2017 um 22:40 schrieb Ævar Arnfjörð Bjarmason: On Mon, May 29, 2017 at 10:25 PM, Johannes Sixt <j...@kdbg.org> wrote: diff --git a/t/t5580-clone-push-unc.sh b/t/t5580-clone-push-unc.sh index b195f71ea9..fd719a209e 100755 --- a/t/t5580-clone-push-unc.sh +++ b/t/t5580-clone-push-

[PATCH 2/2] mingw_fopen: report ENOENT for invalid file names

the case and report ENOENT instead. Signed-off-by: Johannes Sixt <j...@kdbg.org> --- compat/mingw.c| 2 ++ t/t5580-clone-push-unc.sh | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/compat/mingw.c b/compat/mingw.c index 62109cc4e6..ce6fe8f46b 100644 --- a/

[PATCH 1/2] mingw: verify that paths are not mistaken for remote nicknames

d argument when fetching from a Windows path (in this case, D:\repo). [j6t: mark the new test as test_expect_failure] Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> Signed-off-by: Johannes Sixt <j...@kdbg.org> --- t/t5580-clone-push-unc.sh | 10 -- 1 file changed,

Re: [GSoC][PATCH v5 3/3] submodule: port subcommand foreach from shell to C

Am 27.05.2017 um 16:06 schrieb Ramsay Jones: To be more explicit, last Sunday I hacked into t7407 to show an example failure on cygwin (see patch below), but it passes on both Linux (expected) and cygwin! :( Perhaps you can see what I'm doing wrong? As long as the git.exe you are using here is

Re: [GSoC][PATCH v5 3/3] submodule: port subcommand foreach from shell to C

Am 26.05.2017 um 17:17 schrieb Prathamesh Chavan: + argv_array_pushf(_array, "path=%s", list_item->name); Not good! On Windows, environment variables are case insensitive. The environment variable "path" has a very special purpose, although it is generally spelled "PATH" (actually

[PATCH v3 2/2] Windows: do not treat a path with backslashes as a remote's nick name

ittest * branchHEAD -> FETCH_HEAD Signed-off-by: Johannes Sixt <j...@kdbg.org> --- Am 24.05.2017 um 07:45 schrieb Johannes Sixt: > Am 24.05.2017 um 00:08 schrieb Junio C Hamano: >> So in short: >> >> (1) Hannes's patches are good, but they solve a pro

Re: [PATCH 0/2] Fix warnings on access of a remote with Windows paths

Am 24.05.2017 um 00:08 schrieb Junio C Hamano: So in short: (1) Hannes's patches are good, but they solve a problem that is different from what their log messages say; the log message needs to be updated; (2) In nd/fopen-errors topic, we need a new patch that deals with

Re: [PATCH 0/2] Fix warnings on access of a remote with Windows paths

Am 23.05.2017 um 12:53 schrieb Johannes Schindelin: Hi Hannes (& Junio, see below), On Mon, 22 May 2017, Johannes Sixt wrote: Am 22.05.2017 um 13:59 schrieb Johannes Schindelin: On Sat, 20 May 2017, Johannes Sixt wrote: This small series fixes these warnings on Windows: C:\Temp\gittest

Re: [PATCH v3] ref-filter: trim end whitespace in subject

Am 22.05.2017 um 21:53 schrieb Jeff King: On Mon, May 22, 2017 at 09:47:59PM +0200, Johannes Sixt wrote: Am 22.05.2017 um 19:10 schrieb DOAN Tran Cong Danh: diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh index 5778c0afe..fa4441868 100755 --- a/t/t3203-branch-output.sh +++ b

Re: [PATCH v3] ref-filter: trim end whitespace in subject

Am 22.05.2017 um 19:10 schrieb DOAN Tran Cong Danh: diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh index 5778c0afe..fa4441868 100755 --- a/t/t3203-branch-output.sh +++ b/t/t3203-branch-output.sh @@ -13,7 +13,8 @@ test_expect_success 'make commits' ' test_expect_success

[PATCH v2 2/2] Windows: do not treat a path with backslashes as a remote's nick name

ove. Use is_dir_sep() to check for both slashes and backslashes on Windows. Signed-off-by: Johannes Sixt <j...@kdbg.org> --- This v2 writes your suggested comment in front of the loop (not just the 'if' because then I feel I would have to add braces). remote.c | 7 ++- 1 file changed, 6 i

[PATCH v2 1/2] mingw.h: permit arguments with side effects for is_dir_sep

a pointer. Example: is_dir_sep(*p++) Signed-off-by: Johannes Sixt <j...@kdbg.org> --- This v2 takes your commit message body because I like it better than mine. I did not change the subject because your suggestion sounded like the exact opposite of what this patch wants to achieve on

Re: [PATCH 0/2] Fix warnings on access of a remote with Windows paths

Am 22.05.2017 um 13:59 schrieb Johannes Schindelin: On Sat, 20 May 2017, Johannes Sixt wrote: This small series fixes these warnings on Windows: C:\Temp\gittest>git fetch C:\Temp\gittest warning: unable to access '.git/remotes/C:\Temp\gittest': Invalid argument warning: unable to access '.

Re: [PATCH 0/2] Fix warnings on access of a remote with Windows paths

Am 22.05.2017 um 16:01 schrieb Johannes Schindelin: On Mon, 22 May 2017, stefan.na...@atlas-elektronik.com wrote: Am 20.05.2017 um 08:28 schrieb Johannes Sixt: This small series fixes these warnings on Windows: C:\Temp\gittest>git fetch C:\Temp\gittest warning: unable to access '.git/remo

Re: [PATCH] mingw: simplify PATH handling

Am 20.05.2017 um 17:29 schrieb René Scharfe: -static char *path_lookup(const char *cmd, char **path, int exe_only) +static char *path_lookup(const char *cmd, int exe_only) { + const char *path; char *prog = NULL; int len = strlen(cmd); int isexe = len >= 4 &&

Re: [Bug] git branch -v has problems with carriage returns

Am 19.05.2017 um 23:55 schrieb Atousa Duprat: I have tried to repro this issue but git goes out of its way to store the commit messages using unix end-of-line format. I think that git itself cannot create a repo exhibiting this problem. Here is a recipe to reproduce the error: git init

[PATCH 0/2] Fix warnings on access of a remote with Windows paths

HEAD -> FETCH_HEAD The fix is in the second patch; the first patch is a preparation that allows to write the fix in my preferred style. Johannes Sixt (2): mingw.h: permit arguments with side effects for is_dir_sep Windows: do not treat a path with backslashes as a remote's nick name

[PATCH 2/2] Windows: do not treat a path with backslashes as a remote's nick name

ove. Use is_dir_sep() to check for both slashes and backslashes on Windows. Signed-off-by: Johannes Sixt <j...@kdbg.org> --- remote.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/remote.c b/remote.c index 9584af366d..9501357c06 100644 --- a/remote.c +++ b/remote.c @@

[PATCH 1/2] mingw.h: permit arguments with side effects for is_dir_sep

The implementation of is_dir_sep in git-compat-util.h uses an inline function. Use one also for the implementation in compat/mingw.h to support non-trivial argument expressions. Signed-off-by: Johannes Sixt <j...@kdbg.org> --- compat/mingw.h | 6 +- 1 file changed, 5 insertions

Re: [PATCH 00/23] Prepare to separate out a packed_ref_store

Am 17.05.2017 um 14:05 schrieb Michael Haggerty: This patch series is the next leg on a journey towards reading `packed-refs` using `mmap()`, the most interesting aspect of which is that we will often be able to avoid having to read the whole `packed-refs` file if we only need a subset of

Re: t5400 failure on Windows

eceive-pack command such that it does not even open the trace file. Signed-off-by: Johannes Sixt <j...@kdbg.org> --- t/t5400-send-pack.sh | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh index 3331e0f534..d375d7110d 100755

Re: [PATCH v1 2/5] Teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

Am 17.05.2017 um 16:26 schrieb Ben Peart: On 5/16/2017 3:13 PM, Johannes Sixt wrote: Am 16.05.2017 um 19:17 schrieb Ben Peart: OK, now I'm confused as to the best path for adding a get_be64. This one is trivial: #define get_be64(p)ntohll(*(uint64_t *)(p)) I cringe when I see a cast

Re: [PATCH v1 2/5] Teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

Am 16.05.2017 um 19:17 schrieb Ben Peart: OK, now I'm confused as to the best path for adding a get_be64. This one is trivial: #define get_be64(p)ntohll(*(uint64_t *)(p)) I cringe when I see a cast like this. Unless you can guarantee that p is char* (bare or signed or unsigned), you

Re: t5400 failure on Windows

Am 16.05.2017 um 00:24 schrieb Jeff King: 4. There is something racy and unportable about both programs writing to the same trace file. It's opened with O_APPEND, which means that each write should atomically position the pointer at the end of the file. Is it possible

t5400 failure on Windows

I observe the following failure on Windws with origin/next, in t5400-send-pack.sh +++ diff -u expect refs --- expect Mon May 15 06:54:59 2017 +++ refsMon May 15 06:54:59 2017 @@ -1,4 +1,3 @@ 5285e1710002a06a379056b0d21357a999f3c642 refs/heads/master

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

Am 13.05.2017 um 00:36 schrieb Junio C Hamano: Thanks, all three patches look good. Will queue. Let's merge them to 'next' soonish and eventually down to 'master' and 'maint'. The patches change translated strings. You should probably wait for an update of their translations before you

Re: [PATCH] C style: use standard style for "TRANSLATORS" comments

Am 11.05.2017 um 23:20 schrieb Ævar Arnfjörð Bjarmason: diff --git a/builtin/notes.c b/builtin/notes.c index 7b891471c4..fb856e53b6 100644 --- a/builtin/notes.c +++ b/builtin/notes.c @@ -340,8 +340,10 @@ static struct notes_tree *init_notes_check(const char *subcommand, ref = (flags &

Re: [PATCH 8/8] pathspec: convert parse_pathspec to take an index

Am 11.05.2017 um 03:48 schrieb Junio C Hamano: But perhaps you are right---it may be wrong for the contents of the current index (or any index) to affect how a pathspec element is parsed in the first place. If the current code (before this series) uses the_index only for error checking, we may

Re: [PATCH] fixup! use perl instead of sed

Am 09.05.2017 um 19:00 schrieb Ævar Arnfjörð Bjarmason: Finally, you can just use -i like you did with sed, no need for the tempfile: Nope. Some implementations of perl attempt to remove the file that it has just opened. That doesn't work on Windows. You have to supply a backup file name as

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