[PATCH] git-rebase.txt: update note about directory rename detection and am

n. Update it now. Signed-off-by: Elijah Newren Signed-off-by: Johannes Sixt --- Documentation/git-rebase.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 41631df6e4..7bea21e8e3 100644 --- a/Documen

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 05.12.18 um 20:29 schrieb Frank Schäfer: Am 02.12.18 um 22:22 schrieb Johannes Sixt: Am 02.12.18 um 20:31 schrieb Frank Schäfer: With other words: "If CR comes immediately before a LF, do the following with *all* lines: after the CR if eol=lf but do not after the CR if eol=crlf.&q

Re: [PATCH] rebase docs: fix incorrect format of the section Behavioral Differences

Am 05.12.18 um 16:37 schrieb Elijah Newren: On Tue, Dec 4, 2018 at 11:40 PM Junio C Hamano wrote: Johannes Sixt writes: Please let me deposit my objection. This paragraph is not the right place to explain what directory renme detection is and how it works under the hood. "works

Re: [PATCH] rebase docs: fix incorrect format of the section Behavioral Differences

Am 05.12.18 um 07:20 schrieb Elijah Newren: On Tue, Dec 4, 2018 at 7:54 PM Junio C Hamano wrote: Elijah Newren writes: Gah, when I was rebasing on your patch I adopted your sentence rewrite but forgot to remove the "sometimes". Thanks for catching; correction: -- 8< -- Subject: [PATCH

Re: [PATCH] rebase docs: fix incorrect format of the section Behavioral Differences

Am 04.12.18 um 22:24 schrieb Elijah Newren: + The am backend sometimes does not because it operates on +"fake ancestors" that involve trees containing only the files modified +in the patch. Without accurate tree information, directory rename +detection cannot safely operate and is thus

Re: [PATCH] rebase docs: fix incorrect format of the section Behavioral Differences

Am 03.12.18 um 21:42 schrieb Martin Ågren: On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote: I actually did not test the result, because I don't have the infrastructure. I've tested with asciidoc and Asciidoctor, html and man-page. Looks good. Thank you so much! -- Hannes

[PATCH] rebase docs: fix incorrect format of the section Behavioral Differences

subsections instead of a list. Signed-off-by: Johannes Sixt --- Cf. https://git-scm.com/docs/git-rebase#_behavioral_differences I actually did not test the result, because I don't have the infrastructure. The sentence "The am backend sometimes does not" is not very useful, but is not

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 02.12.18 um 20:31 schrieb Frank Schäfer: Am 29.11.18 um 03:11 schrieb Junio C Hamano: [...] This was misspoken a bit. Let's revise it to When producing a colored output (not limited to whitespace error coloring of diff output) for contents that are not marked as

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 27.11.18 um 00:31 schrieb Junio C Hamano: Johannes Sixt writes: Am 26.11.18 um 04:04 schrieb Junio C Hamano: ... this goes too far, IMO. It is the pager's task to decode control characters. It was tongue-in-cheek suggestion to split a CR into caret-em on our end, but we'd get essentially

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 26.11.18 um 04:04 schrieb Junio C Hamano: It appears to me that what Frank sees is not "^M highlighted for whitespace breakage appears only on postimage lines, while ^M is shown but not highlighted on preimage lines". My reading of the above is "Not just without highlight, ^M is just *NOT*

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 25.11.18 um 15:03 schrieb Frank Schäfer: Am 24.11.18 um 23:07 schrieb Johannes Sixt: I don't think that there is anything to fix. If you have a file with CRLF in it, but you did not declare to Git that CRLF is the expected end-of-line indicator, then the CR *is* trailing whitespace (because

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 24.11.18 um 15:51 schrieb Frank Schäfer: Am 23.11.18 um 22:47 schrieb Johannes Sixt: Am 23.11.18 um 19:19 schrieb Frank Schäfer: The CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF. It shows up as expected in '-' lines when the ending

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 23.11.18 um 19:19 schrieb Frank Schäfer: The CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF. It shows up as expected in '-' lines when the ending of the removed line is CR only. It also always shows up as expected in '+' lines. Is your

Re: [PATCH 1/1] mingw: replace an obsolete link with the superseding one

Am 15.11.18 um 12:22 schrieb Johannes Schindelin via GitGitGadget: From: Johannes Schindelin The MSDN documentation has been superseded by Microsoft Docs (which is backed by a repository on GitHub containing many, many files in Markdown format). Signed-off-by: Johannes Schindelin ---

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Am 07.11.18 um 21:41 schrieb Jeff King: On Wed, Nov 07, 2018 at 07:52:28PM +0100, Johannes Sixt wrote: Do I understand correctly, that you use a leading slash as an indicator to construct a path relative to system_path(). How about a "reserved" user name? For example, [htt

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Am 07.11.18 um 12:23 schrieb Johannes Schindelin: On Tue, 6 Nov 2018, Johannes Sixt wrote: Am 06.11.18 um 15:53 schrieb Johannes Schindelin via GitGitGadget: Even if a path looks like a POSIX paths, i.e. it starts with a directory separator, but not with drive-letter-colon, it still has

Re: [PATCH 1/1] Windows: force-recompile git.res for differing architectures

Am 07.11.18 um 02:32 schrieb Junio C Hamano: Johannes Sixt writes: On Linux, when I recompile for a different architecture, CFLAGS would change, so I would have thought that GIT-CFLAGS were the natural choice for a dependency. Don't they change in this case on Windows, too? Depending on GIT

Re: [PATCH 1/1] Windows: force-recompile git.res for differing architectures

Am 06.11.18 um 15:55 schrieb Johannes Schindelin via GitGitGadget: From: Johannes Schindelin When git.rc is compiled into git.res, the result is actually dependent on the architecture. That is, you cannot simply link a 32-bit git.res into a 64-bit git.exe. Therefore, to allow 32-bit and

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Am 06.11.18 um 15:53 schrieb Johannes Schindelin via GitGitGadget: From: Johannes Schindelin On Windows, an absolute POSIX path needs to be turned into a Windows one. If I were picky, I would say that in a pure Windows application there cannot be POSIX paths to begin with. Even if a path

Re: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues

Am 05.11.18 um 08:01 schrieb Johannes Sixt: Am 05.11.18 um 00:26 schrieb Junio C Hamano: OK, thanks.  It seems that the relative silence after this message is a sign that the resulting patch after squashing is what everybody is happey with? I'm not 100% happy. I see the patch is already

Re: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues

Am 05.11.18 um 00:26 schrieb Junio C Hamano: OK, thanks. It seems that the relative silence after this message is a sign that the resulting patch after squashing is what everybody is happey with? I'm not 100% happy. I'll resend a squashed patch, but it has to wait as I have to catch a train

Re: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues

Am 03.11.18 um 09:14 schrieb Carlo Arenas: On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote: + timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout - elapsed); nitpick: cast to DWORD instead of int No; timeout is of type int; after an explicit type cast we don't want to h

Re: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues

Am 02.11.18 um 15:47 schrieb Steve Hoelzer: > On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt wrote: >> >> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget: >>> @@ -614,7 +618,7 @@ restart: >>> >>> if (!rc && orig_timeout &am

Re: [PATCH 3/3] tests: optionally skip `git rebase -p` tests

Am 01.11.18 um 07:12 schrieb Junio C Hamano: "Johannes Schindelin via GitGitGadget" writes: The `--preserve-merges` mode of the `rebase` command is slated to be deprecated soon, ... Is everybody on board on this statement? I vaguely recall that some people wanted to have something

Re: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues

Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget: From: Steve Hoelzer From Visual Studio 2015 Code Analysis: Warning C28159 Consider using 'GetTickCount64' instead of 'GetTickCount'. Reason: GetTickCount() overflows roughly every 49 days. Code that does not take that into account

[PATCH v2 sg/test-rebase-editor-fix] t3404-rebase-interactive: test abbreviated commands

commands are optional in the FAKE_LINES variable, but when used, they do end up in the insn sheet. Test them, too. Signed-off-by: Johannes Sixt --- v2: - updated commit message - patch text is unchanged t/lib-rebase.sh | 4 ++-- t/t3404-rebase-interactive.sh | 10 +- 2

Re: [PATCH sg/test-rebase-editor-fix] t3404-rebase-interactive: test abbreviated commands

Am 25.10.18 um 22:54 schrieb Johannes Sixt: Test each short command at least once. The commands changed here are chosen such that - tests do not have a prerequisite, - the 'git rebase' command is not guarded by test_must_fail. The pick commands are optional noise words in the FAKE_LINES

[PATCH sg/test-rebase-editor-fix] t3404-rebase-interactive: test abbreviated commands

Test each short command at least once. The commands changed here are chosen such that - tests do not have a prerequisite, - the 'git rebase' command is not guarded by test_must_fail. The pick commands are optional noise words in the FAKE_LINES variable. Test them, too. Signed-off-by: Johannes

[PATCH 3/2] rebase -i: recognize short commands without arguments

The sequencer instruction 'b', short for 'break', is rejected: error: invalid line 2: b The reason is that the parser expects all short commands to have an argument. Permit short commands without arguments. Signed-off-by: Johannes Sixt --- I'll send a another patch in a moment that tests

Re: What's cooking in git.git (Oct 2018, #04; Fri, 19)

Am 19.10.18 um 08:02 schrieb Junio C Hamano: * js/diff-notice-has-drive-prefix (2018-10-19) 1 commit - diff: don't attempt to strip prefix from absolute Windows paths "git diff /a/b/c /a/d/f" noticed these are full paths with shared leading prefix "/a", but failed to notice a similar fact

[PATCH v2] diff: don't attempt to strip prefix from absolute Windows paths

should be changed from == '/' to is_dir_sep() or not. It turns out not to be necessary. That code only ever investigates paths that have undergone pathspec normalization, after which there are only forward slashes even on Windows. Signed-off-by: Johannes Sixt --- v2: - added a test that demonstrates the proble

Re: [PATCH] diff: don't attempt to strip prefix from absolute Windows paths

Am 18.10.18 um 20:49 schrieb Stefan Beller: > On Thu, Oct 18, 2018 at 11:38 AM Johannes Sixt wrote: > >> There is one peculiarity, though: [...] > > The explanation makes sense, and the code looks good. > Do we want to have a test for this niche case? > Good point. Tha

[PATCH] diff: don't attempt to strip prefix from absolute Windows paths

ot. It turns out not to be necessary. That code only ever investigates paths that have undergone pathspec normalization, after which there are only forward slashes even on Windows. Signed-off-by: Johannes Sixt --- diff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dif

Re: [PATCH] zlib.c: use size_t for size

Am 13.10.18 um 04:46 schrieb Jeff King: But no, right before that we have this line: offset -= win->offset; So offset is in fact no longer its original meaning of "offset into the packfile", but is now an offset of the specific request into the window we found. So I think it's

Re: [PATCH v3 4/7] revision.c: begin refactoring --topo-order logic

Am 12.10.18 um 08:33 schrieb Junio C Hamano: "Derrick Stolee via GitGitGadget" writes: +struct topo_walk_info {}; + +static void init_topo_walk(struct rev_info *revs) +{ + struct topo_walk_info *info; + revs->topo_walk_info = xmalloc(sizeof(struct topo_walk_info)); + info =

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

Am 10.10.18 um 07:43 schrieb Junio C Hamano: We haven't seen much complaints and breakages reported against the two big "rewrite in C" topics around "rebase"; perhaps it is a good time to merge them to 'next' soonish to cook them for a few weeks before moving them to 'master'? Please let me

Re: What's so special about objects/17/ ?

Am 07.10.18 um 21:06 schrieb Ævar Arnfjörð Bjarmason: Picking any one number is explained in the comment. I'm asking why 17 in particular not for correctness reasons but as a bit of historical lore, and because my ulterior is to improve the GC docs. The number in that comic is 4 (and no

Re: What's so special about objects/17/ ?

Am 07.10.18 um 20:28 schrieb Ævar Arnfjörð Bjarmason: In 2007 Junio wrote (https://public-inbox.org/git/7vr6lcj2zi@gitster.siamese.dyndns.org/): +static int need_to_gc(void) +{ + /* + * Quickly check if a "gc" is needed, by estimating how + * many loose objects

Re: What's cooking in git.git (Sep 2018, #04; Thu, 20)

Am 21.09.18 um 07:22 schrieb Junio C Hamano: > The tip of 'next' hasn't been rewound yet. The three GSoC "rewrite > in C" topics are still unclassified in this "What's cooking" report, > but I am hoping that we can have them in 'next' sooner rather than > later. I got an impression that Dscho

Re: [Question] Signature calculation ignoring parts of binary files

Am 12.09.18 um 21:16 schrieb Randall S. Becker: I feel really bad asking this, and I should know the answer, and yet. I have a binary file that needs to go into a repo intact (unchanged). I also have a program that interprets the contents, like a textconv, that can output the relevant portions

Re: [PATCH v2 2/2] mingw: fix mingw_open_append to work with named pipes

Am 10.09.18 um 19:05 schrieb Jeff Hostetler via GitGitGadget: diff --git a/compat/mingw.c b/compat/mingw.c index 858ca14a57..f87376b26a 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -341,6 +341,19 @@ int mingw_mkdir(const char *path, int mode) return ret; } +/* + * Calling

Re: [PATCH] Revert "Merge branch 'sb/submodule-core-worktree'" (was Re: Old submodules broken in 2.19rc1 and 2.19rc2)

Am 08.09.2018 um 04:04 schrieb Junio C Hamano: > Jonathan Nieder writes: > >> It is late in the release cycle, so revert the whole 3-patch series. >> We can try again later for 2.20. >> >> Reported-by: Allan Sandfeld Jensen >> Helped-by: Stefan Beller >> Signed-off-by: Jonathan Nieder >> ---

Re: [PATCH 2/2] mingw: fix mingw_open_append to work with named pipes

Am 08.09.2018 um 11:26 schrieb Johannes Sixt: Am 07.09.2018 um 20:19 schrieb Jeff Hostetler via GitGitGadget: diff --git a/compat/mingw.c b/compat/mingw.c index 858ca14a57..ef03bbe5d2 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -355,7 +355,7 @@ static int mingw_open_append(wchar_t const

Re: [PATCH 2/2] mingw: fix mingw_open_append to work with named pipes

Am 07.09.2018 um 20:19 schrieb Jeff Hostetler via GitGitGadget: From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- compat/mingw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/compat/mingw.c b/compat/mingw.c index 858ca14a57..ef03bbe5d2 100644 --- a/compat/mingw.c

Re: [PATCH] config: fix commit-graph related config docs

Am 22.08.2018 um 15:16 schrieb Derrick Stolee: diff --git a/Documentation/config.txt b/Documentation/config.txt index 1c42364988..f846543414 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -917,7 +917,11 @@ core.notesRef:: This setting defaults to "refs/notes/commits",

Re: Do not raise conflict when a code in a patch was already added

Am 20.08.2018 um 19:40 schrieb Phillip Wood: On 20/08/2018 11:22, Konstantin Kharlamov wrote: It's spectacular, that content of one of inserted conflict markers is empty, so all you have to do is to remove the markers, and use `git add` on the file, and then `git rebase --continue` Its a lot

Re: [PATCH] mingw: enable atomic O_APPEND

Am 14.08.2018 um 00:37 schrieb Jeff King: And then you can do something like: for size in 4097 8193 16385 32769 65537 131073 262145 524289 1048577; do >out ;# clean up from last run echo "Trying $size..." timeout 5 ./write $size out if ! ./check $size I used your

Re: [PATCH] mingw: enable atomic O_APPEND

Am 13.08.2018 um 22:20 schrieb Junio C Hamano: Johannes Sixt writes: The Windows CRT implements O_APPEND "manually": on write() calls, the file pointer is set to EOF before the data is written. Clearly, this is not atomic. And in fact, this is the root cause of failures observe

[PATCH] mingw: enable atomic O_APPEND

unusal error ENOSYS is reported if an unsupported mode is encountered. Diagnosed-by: Johannes Schindelin Helped-by: Jeff Hostetler Signed-off-by: Johannes Sixt --- compat/mingw.c | 41 +++-- 1 file changed, 39 insertions(+), 2 deletions(-) diff --git a/compat/ming

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Am 10.08.2018 um 18:51 schrieb Jeff Hostetler: On 8/10/2018 12:15 PM, Johannes Sixt wrote: Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget: I reported a couple of times that t5552 is not passing reliably. It has now reached next, and will no doubt infect master soon

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget: I reported a couple of times that t5552 is not passing reliably. It has now reached next, and will no doubt infect master soon. Turns out that it is not a Windows-specific issue, even if it occurs a lot more often on Windows

Re: [PATCH v2] t/test-lib: make `test_dir_is_empty` more robust

Am 05.08.2018 um 06:20 schrieb William Chargin: While the `test_dir_is_empty` function appears correct in most normal use cases, it can fail when filenames contain newlines. This patch changes the implementation to use `ls -A`, which is specified by POSIX. The output should be empty exactly if

First test of t5552 fails on Windows

I'm testing origin/next on Windows with a few other topics on top. The first test fails like this. Do you see what is wrong? Where should I start looking? Is it perhaps that upload-pack is responding too soon so that fetch does not send 'have c1'? this is the console output

Re: [PATCH v2] pack-objects: fix performance issues on packing large deltas

Am 22.07.2018 um 10:04 schrieb Nguyễn Thái Ngọc Duy: + if (size < pack->oe_delta_size_limit) { + e->delta_size_ = size; + e->delta_size_valid = 1; + } else { + packing_data_lock(pack); + if (!pack->delta_size) +

Re: [PATCH 7/9] vscode: use 8-space tabs, no trailing ws, etc for Git's source code

Am 23.07.2018 um 15:52 schrieb Johannes Schindelin via GitGitGadget: From: Johannes Schindelin This adds a couple settings for the .c/.h files so that it is easier to conform to Git's conventions while editing the source code. Signed-off-by: Johannes Schindelin --- contrib/vscode/init.sh |

Re: [PATCH 0/3] rebase -r: support octopus merges

Am 12.07.2018 um 18:26 schrieb Junio C Hamano: Johannes Schindelin writes: A much more meaningful measure would be: how many octopus merge commits have been pushed to GitHub in the past two weeks. I don't think I have the technical means to answer that question, though. It does not mean that

Re: [PATCH v2 1/2] t3418: add testcase showing problems with rebase -i and strategy options

Am 27.06.2018 um 19:27 schrieb Elijah Newren: On Wed, Jun 27, 2018 at 9:54 AM, Junio C Hamano wrote: Having said that, it would be simpler for at least the latter to write it using a single-shot environment assignment, perhaps? I.e. PATH=./test-bin:$PATH git rebase --continue &&

Re: [PATCH 29/29] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells

Am 27.06.2018 um 04:15 schrieb Elijah Newren: On Tue, Jun 26, 2018 at 2:01 PM, Jeff King wrote: On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote: Some of these dangers can be de-thoothed during the linting phase by defining do-nothing shell functions: cp () { :; } mv

Re: [PATCH 17/29] t: use test_must_fail() instead of checking exit code manually

Am 26.06.2018 um 20:14 schrieb Eric Sunshine: On Tue, Jun 26, 2018 at 2:06 PM Johannes Sixt wrote: Hence, these lines should actually be p4 help client && ! p4 help nosuchcommand Thanks for the comment; you're right, of course. I'll certai

Re: [PATCH 17/29] t: use test_must_fail() instead of checking exit code manually

Am 26.06.2018 um 11:21 schrieb Eric Sunshine: On Tue, Jun 26, 2018 at 4:58 AM Elijah Newren wrote: On Tue, Jun 26, 2018 at 12:29 AM, Eric Sunshine wrote: + p4 help client && + test_must_fail p4 help nosuchcommand same question? Same answer. Not shown in this

Re: Unexpected ignorecase=false behavior on Windows

Am 22.06.2018 um 14:04 schrieb Marc Strapetz: On Windows, when creating following repository: $ git init $ echo "1" > file.txt $ git add . $ git commit -m "initial import" $ ren file.txt File.txt $ git config core.ignorecase false This is a user error. core.ignorecase is *not* an instruction

Re: want option to git-rebase

Am 19.06.2018 um 03:06 schrieb Jonathan Nieder: Ian Jackson wrote[1]: git-rebase leaves entries like this in the reflog: c15f4d5391 HEAD@{33}: rebase: checkout c15f4d5391ff07a718431aca68a73e672fe8870e It would be nice if there were an option to control this message. Particularly, when

Re: git-gui ignores core.hooksPath

Am 11.06.2018 um 23:58 schrieb Stefan Beller: On Mon, Jun 4, 2018 at 10:48 PM Bert Wesarg wrote: the last time this topic came up, Stefan (in Cc) offered to volunteer. Stefan, is this offer still open? I would support this. After I made this offer, I started looking at the code base more and

Re: [RFC PATCH v1] telemetry design overview (part 1)

Am 09.06.2018 um 22:43 schrieb Johannes Schindelin: On Sat, 9 Jun 2018, Johannes Sixt wrote: When you want usage data, ask your users for feedback. Look over their shoulders. But do not ask the software itself to gather usage data. It will be abused. Do not offer open source software that has

Re: [RFC PATCH v1] telemetry design overview (part 1)

Am 09.06.2018 um 08:51 schrieb Jeff King: I actually think this could be useful for normal users, too. We have GIT_TRACE for dumping debug output, and we sometimes ask users to turn it on to help diagnose a problem (not to mention that we use it ourselves). The BIG difference is in "we ask the

Re: [RFC PATCH v1] telemetry design overview (part 1)

Am 09.06.2018 um 00:20 schrieb Ævar Arnfjörð Bjarmason: On Fri, Jun 08 2018, Johannes Sixt wrote: Am 08.06.2018 um 18:00 schrieb Thomas Braun: I for my part would much rather prefer that to be a compile time option so that I don't need to check on every git update on windows if this is now

Re: GDPR compliance best practices?

Am 08.06.2018 um 04:53 schrieb Theodore Y. Ts'o: And of course, that's the other thing you seem to fundamentally not understand about how git works. Every developer in the world working on that open source project has their own copy. Everyone here understands how Git works, of course.

Re: [RFC PATCH v1] telemetry design overview (part 1)

Am 08.06.2018 um 18:00 schrieb Thomas Braun: I for my part would much rather prefer that to be a compile time option so that I don't need to check on every git update on windows if this is now enabled or not. This exactly my concern, too! A compile-time option may make it a good deal less

Re: [RFC PATCH v1] telemetry design overview (part 1)

Am 07.06.2018 um 16:53 schrieb g...@jeffhostetler.com: From: Jeff Hostetler I've been working to add code to Git to optionally collect telemetry data. The goal is to be able to collect performance data from Git commands and allow it to be aggregated over a user community to find "slow

Re: how exactly can git config section names contain periods?

Am 03.06.2018 um 11:53 schrieb Robert P. J. Day: if i wanted to do something this admittedly awkward, would using periods give me some benefit related to, i don't know, regex matching, as compared to using a different character? or am i just way overthinking this? is anyone out there actually

Re: is there a reason pre-commit.sample uses "git diff-index"?

Am 31.05.2018 um 19:27 schrieb Robert P. J. Day: On Thu, 31 May 2018, Duy Nguyen wrote: git diff-index is "plumbing", designed for writing scripts. "git diff" on the other hand is for users and its behavior may change even if it breaks backward compatibility. ah, this was a philosophical

Re: [PATCH 5/5] merge-recursive: simplify handle_change_delete

Am 19.05.2018 um 04:07 schrieb Elijah Newren: There is really no need for four branches of nearly identical messages when we can store the differences into small variables before printing. Oh, there is a reason for the repeated message text: translations! Please do not play sentence Lego with

Re: Git log range reverse bug

Am 16.05.2018 um 20:19 schrieb Mehdi Zeinali: Git Version: Version: 2.14.2 When reversing a range in git log, it does not start from the expected commit: --reverse does not change the meaning A..B to B..A or something. For a particular A..B specification, the set of commits selected when

Re: [PATCH v2 17/28] t4014: abstract away SHA-1-specific constants

Am 13.05.2018 um 04:24 schrieb brian m. carlson: Adjust the test so that it computes values for blobs instead of using hard-coded hashes. Signed-off-by: brian m. carlson --- t/t4014-format-patch.sh | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-)

[PATCH v2] git: add -P as a short option for --no-pager

that the output remains visible in the terminal. For this, the option --no-pager can be used. But it is a bit cumbersome to type, even when command completion is available. Provide a short option, -P, to make the option easier accessible. Signed-off-by: Johannes Sixt <j...@kdbg.org> --- Given the po

Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]

Am 01.05.2018 um 13:57 schrieb Johannes Schindelin: Hi Hannes, On Mon, 30 Apr 2018, Johannes Sixt wrote: Am 30.04.2018 um 05:25 schrieb Junio C Hamano: * js/no-pager-shorthand (2018-04-25) 1 commit - git: add -N as a short option for --no-pager "git --no-pager cmd" did not

Re: [PATCH 2/6] t1406: prepare for the refs code to fail with BUG()

Am 30.04.2018 um 00:17 schrieb Johannes Schindelin: t1406 specifically verifies that certain code paths fail with a BUG: ... message. In the upcoming commit, we will convert that message to be generated via BUG() instead of die("BUG: ..."), which implies SIGABRT instead of a regular exit code.

Re: [PATCH v1] test-drop-caches: simplify delay loading of NtSetSystemInformation

Am 30.04.2018 um 16:26 schrieb Ben Peart: @@ -82,8 +83,6 @@ static int cmd_dropcaches(void) { HANDLE hProcess = GetCurrentProcess(); HANDLE hToken; - HMODULE ntdll; - DWORD(WINAPI *NtSetSystemInformation)(INT, PVOID, ULONG); SYSTEM_MEMORY_LIST_COMMAND

js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]

Am 30.04.2018 um 05:25 schrieb Junio C Hamano: * js/no-pager-shorthand (2018-04-25) 1 commit - git: add -N as a short option for --no-pager "git --no-pager cmd" did not have short-and-sweet single letter option. Now it does. Will merge to 'next'. I consider your argument that -N is

Re: [PATCH] git: add -N as a short option for --no-pager

Am 25.04.2018 um 11:21 schrieb Phillip Wood: On 24/04/18 17:59, Johannes Sixt wrote: In modern setups, less, the pager, uses alternate screen to show the content. When it is closed, it switches back to the original screen, and all content is gone. Are you setting LESS explicitly

Re: [PATCH] git: add -N as a short option for --no-pager

Am 25.04.2018 um 09:41 schrieb Johannes Schindelin: Hi Hannes, On Wed, 25 Apr 2018, Johannes Sixt wrote: Am 25.04.2018 um 02:05 schrieb Junio C Hamano: Johannes Sixt <j...@kdbg.org> writes: It is not uncommon to request that the output remains visible in the terminal. I ran `g

Re: [PATCH] git: add -N as a short option for --no-pager

Am 25.04.2018 um 02:05 schrieb Junio C Hamano: Johannes Sixt <j...@kdbg.org> writes: It is not uncommon to request that the output remains visible in the terminal. For this, the option --no-pager can be used. But it is a bit cumbersome to type, even when command completion is available. P

[PATCH] git: add -N as a short option for --no-pager

. But it is a bit cumbersome to type, even when command completion is available. Provide a short option, -N, to make the option easier accessible. Signed-off-by: Johannes Sixt <j...@kdbg.org> --- Documentation/git.txt | 3 ++- git.c | 4 ++-- 2 files changed, 4 insertions(+), 3 del

squash! Merge branch 'ps/test-chmtime-get'

Junio, you may want to squash this into your merge commit of branch ps/test-chmtime-get (today it is fa57c0871fc9) -- Hannes diff --git a/t/helper/test-chmtime.c b/t/helper/test-chmtime.c index daeddc1cbc..aa22af48c2 100644 --- a/t/helper/test-chmtime.c +++ b/t/helper/test-chmtime.c @@ -25,7

Re: [RFC PATCH] ident: don't cache default date

author date nor the committer date are explicitly >>> set. 'commit' always passes the author date to commit_tree_extended() >>> and relied on the date caching to have the same committer and author >>> dates when neither was specified. Fix this by setting >>> GIT

Re: Bug: rebase -i creates committer time inversions on 'reword'

Am 15.04.2018 um 23:35 schrieb Junio C Hamano: Ah, do you mean we have an internal sequence like this, when "rebase --continue" wants to conclude an edit/reword? Yes, it's only 'reword' that is affected, because then subsequent picks are processed by the original process. - we figure out

Bug: rebase -i creates committer time inversions on 'reword'

I just noticed that all commits in a 70-commit branch have the same committer timestamp. This is very unusual on Windows, where rebase -i of such a long branch takes more than one second (but not more than 3 or so thanks to the builtin nature of the command!). And, in fact, if you mark some

Re: Windows > git.exe > the result of "git branch" does not always highlight the current branch

Am 09.04.2018 um 21:26 schrieb Hari Lubovac: It appears to be just a reporting issue. Probably not a big deal, but I thought I should report this, if it hasn't been noticed: when a branch is switched to by being named with non-original character-casing, then it's not clear which branch is

Re: js/runtime-prefix-windows, was Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)

Am 03.04.2018 um 15:12 schrieb Johannes Schindelin: On Fri, 30 Mar 2018, Junio C Hamano wrote: * js/runtime-prefix-windows (2018-03-27) 2 commits - mingw/msvc: use the new-style RUNTIME_PREFIX helper - exec_cmd: provide a new-style RUNTIME_PREFIX helper for Windows (this branch uses

Re: Need help debugging issue in git

Am 02.04.2018 um 02:36 schrieb Robert Dailey: I'm struggling with a bug that I found introduced in git v2.13.2. The bug was not reproducible in v2.13.1. The issue is that using arguments like "@{-1}" to aliases causes those curly braces to be removed, so once the command is executed after alias

Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git

Am 13.03.2018 um 21:39 schrieb Ævar Arnfjörð Bjarmason: Add a INSTALL_SYMLINKS option which if enabled, changes the default hardlink installation method to one where the relevant binaries in libexec/git-core are symlinked back to ../../bin, instead of being hardlinked. This new option also

Re: [PATCH 2/2] worktree: add: change to new worktree directory before running hook

Am 12.02.2018 um 04:15 schrieb Eric Sunshine: --- a/t/t2025-worktree-add.sh +++ b/t/t2025-worktree-add.sh @@ -454,20 +454,29 @@ post_checkout_hook () { test_when_finished "rm -f .git/hooks/post-checkout" && mkdir -p .git/hooks && write_script .git/hooks/post-checkout

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Am 09.02.2018 um 07:11 schrieb Sergey Organov: Johannes Schindelin writes: Let me explain the scenario which comes up plenty of times in my work with Git for Windows. We have a thicket of some 70 branches on top of git.git's latest release. These branches often

Re: [PATCH] t0050: remove the unused $test_case variable

Am 07.02.2018 um 09:07 schrieb Ævar Arnfjörð Bjarmason: On Wed, Feb 07 2018, Johannes Sixt jotted: Am 07.02.2018 um 00:13 schrieb Ævar Arnfjörð Bjarmason: The $test_case variable hasn't been used since decd3c0c28 ("t0050-*.sh: mark the rename (case change) test as passing", 2014-1

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

ke in the original --preserve-merges, and you bring with you to this new --recreate-merges... It's sad. Even more sad as solution is already known for years: bc00341838a8faddcd101da9e746902994eef38a Author: Johannes Sixt <j...@kdbg.org> Date: Sun Jun 16 15:50:42 2013 +0200

Re: [PATCH] t0050: remove the unused $test_case variable

Am 07.02.2018 um 00:13 schrieb Ævar Arnfjörð Bjarmason: The $test_case variable hasn't been used since decd3c0c28 ("t0050-*.sh: mark the rename (case change) test as passing", 2014-11-28) when its last user went away. Let's remove the "say" as well, since it's obvious from subsequent output

Re: [PATCH v7 17/31] merge-recursive: add a new hashmap for storing directory renames

Am 03.02.2018 um 22:34 schrieb Elijah Newren: > If anyone can find an > example of a real world open source repository (linux, webkit, git, > etc.) with a merge where n is greater than about 10, I'll be > surprised. git rev-list --parents --merges master | grep " .* .* .* .* .* .* .* .* .* .* "

Re: Git on Windows maps creation time onto changed time

Am 02.02.2018 um 00:10 schrieb Keith Goldfarb: Dear git, While tracking down a problem with a filesystem shared by Windows and Ubuntu, I came across the following code in compat/mingw.c (ming_fstat(), also in do_lstat()): if (GetFileInformationByHandle(fh, )) {

Re: [PATCH 00/37] removal of some c++ keywords

Am 29.01.2018 um 23:36 schrieb Brandon Williams: A while back there was some discussion of getting our codebase into a state where we could use a c++ compiler if we wanted to (for various reason like leveraging c++ only analysis tools, etc.). Johannes Sixt had a very large patch that achieved

Re: [PATCH 1/1] Mark messages for translations

Am 15.01.2018 um 06:44 schrieb Alexander Shopov: @@ -5,11 +5,11 @@ #include "run-command.h" const char git_usage_string[] = - "git [--version] [--help] [-C ] [-c name=value]\n" - " [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n" - " [-p

  1   2   3   4   5   6   7   8   9   10   >