Am 18.05.19 um 16:13 schrieb Dr. Adam Nielsen:
> - - If the pattern ends with a slash, it is removed for the
> - purpose of the following description, but it would only find
> + - A slash `/` is used as a directory separator. A leading and trailing
> + slash have special meaning and are explain
Am 18.05.19 um 14:58 schrieb Ax Da:
> You can rename files like this:
> git mv File.txt file.txt
On a case-insensitive, case-preserving filesystem, a case-only rename
operation is better performed in two steps that do not just change the case:
git mv File.txt file.txtx
git mv file.txtx file.txt
Am 17.05.19 um 23:43 schrieb Dr. Adam Nielsen:
>> Another thing that I noticed is that its not mentioned anywhere that
>> the pattern use a slash as a directory separator (instead of a
>> backslash), its only clear from the examples. Maybe its worth to
>> mention it in the "PATTERN FORMAT" section.
Am 17.05.19 um 14:19 schrieb LI, BO XUAN:
> On Fri, May 17, 2019 at 7:34 AM Junio C Hamano wrote:
>>
>> Johannes Sixt writes:
>>
>>> I'd prefer to keep this list at the minimum necessary as long as it is
>>> hard-coded in C.
>>
>> Ye
> The word_regex pattern finds identifiers, integers, floats and
> operators, according to the Rust Reference Book.
>
> Cc: Johannes Sixt
In this code base, Cc: footers are disliked.
> Signed-off-by: Marc-André Lureau
> ---
> diff --git a/t/t4018/rust-trait b/t/t4018/ru
Am 16.05.19 um 22:29 schrieb Johannes Sixt:
> Am 15.05.19 um 20:34 schrieb marcandre.lur...@redhat.com:
>> + "[a-zA-Z_][a-zA-Z0-9_]*"
>> +
>> "|[-+_0-9.eE]+(f32|f64|u8|u16|u32|u64|u128|usize|i8|i16|i32|i64|i128|isize)?"
>
> I assume
Am 15.05.19 um 20:34 schrieb marcandre.lur...@redhat.com:
> From: Marc-André Lureau
>
> This adds xfuncname and word_regex patterns for Rust, a quite
> popular programming language. It also includes test cases for the
> xfuncname regex (t4018) and updated documentation.
>
> The word_regex patter
Am 16.05.19 um 11:19 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> In Matlab, is %%% followed by space at the beginning of a line
>> *commonly* used for something different? If I were to make a guess, I
>> would say no. If I'm right, it does not hurt to merge
Am 16.05.19 um 00:44 schrieb brian m. carlson:
> On Tue, May 14, 2019 at 05:12:39PM +0200, Johannes Schindelin wrote:
>> On Tue, 14 May 2019, brian m. carlson wrote:
>>> +/*
>>> + * Return 1 if a hook exists at path (which may be modified) using
>>> access(2)
>>> + * with check (which should be F_
Am 15.05.19 um 13:43 schrieb Ævar Arnfjörð Bjarmason:
>
> On Wed, May 15 2019, Mike Hommey wrote:
>
>> Hi,
>>
>> I started getting a weird error message during some test case involving
>> git-cinnabar, which is a remote-helper to access mercurial
>> repositories.
>>
>> The error says:
>> fatal: m
Am 15.05.19 um 08:15 schrieb LI, BO XUAN:
> On Wed, May 15, 2019 at 1:57 PM Johannes Sixt wrote:
>>
>> Am 11.05.19 um 06:13 schrieb Boxuan Li:
>>> Octave pattern is almost the same as matlab. Besides,
>>> octave also uses '%%%' or '##
Am 11.05.19 um 06:13 schrieb Boxuan Li:
> Octave pattern is almost the same as matlab. Besides,
> octave also uses '%%%' or '##' to begin code sections.
>
> @@ -60,6 +60,11 @@ PATTERNS("java",
> PATTERNS("matlab",
>"^[[:space:]]*((classdef|function)[[:space:]].*)$|^%%[[:space:]].*$",
>
Am 14.05.19 um 14:56 schrieb Duy Nguyen:
> On Tue, May 14, 2019 at 7:24 AM brian m. carlson
> wrote:
>> diff --git a/builtin/am.c b/builtin/am.c
>> index 912d9821b1..340eacbd44 100644
>> --- a/builtin/am.c
>> +++ b/builtin/am.c
>> @@ -441,24 +441,8 @@ static int run_applypatch_msg_hook(struct am_s
Am 10.05.19 um 02:14 schrieb Elijah Newren:
> Hi Johannes,
>
> On Thu, May 9, 2019 at 1:46 PM Johannes Schindelin
> wrote:
>>
>> Hi Junio & Elijah,
>>
>> On Thu, 9 May 2019, Junio C Hamano wrote:
>>
>>> * en/fast-export-encoding (2019-05-07) 5 commits
>>> - fast-export: do automatic reencoding o
Am 01.05.19 um 00:41 schrieb Johannes Schindelin:
> On Tue, 30 Apr 2019, Johannes Sixt wrote:
>> Am 29.04.19 um 23:56 schrieb İsmail Dönmez via GitGitGadget:
>>> diff --git a/config.mak.uname b/config.mak.uname
>>> index e7c7d14e5f..a9edcc5f0b 100644
>>&
Am 01.05.19 um 00:33 schrieb Johannes Schindelin:
> On Tue, 30 Apr 2019, Johannes Sixt wrote:
>> Am 30.04.19 um 01:17 schrieb Johannes Schindelin:
>>> You're right, this is confusing, especially since Git for Windows 2.x does
>>> not have that bug.
>>
>
[had to add Dscho as recipient manually, mind you]
Am 29.04.19 um 23:56 schrieb İsmail Dönmez via GitGitGadget:
> From: =?UTF-8?q?=C4=B0smail=20D=C3=B6nmez?=
>
> Enable DEP (Data Execution Prevention) and ASLR (Address Space Layout
> Randomization) support. This applies to both 32bit and 64bit b
Am 30.04.19 um 01:17 schrieb Johannes Schindelin:
> On Mon, 29 Apr 2019, Eric Sunshine wrote:
>> On Mon, Apr 29, 2019 at 6:04 PM Thomas Braun via GitGitGadget
>>> diff --git a/Documentation/config/sendpack.txt
>>> b/Documentation/config/sendpack.txt
>>> @@ -0,0 +1,5 @@
>>> +sendpack.sideband::
>>>
Am 26.04.19 um 22:58 schrieb brian m. carlson:
> On Thu, Apr 25, 2019 at 09:40:34PM +0200, Johannes Sixt wrote:
> I would like to point out that we still have to perform an executability
> check before we run the hook or we'll get errors printed to the user.
That's fine. On W
Am 25.04.19 um 02:55 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Furthermore, basing a decision on whether a file is executable won't
>> work on Windows as intended. So, it is better to aim for an existence check.
>
> That is a good point.
>
> So it
Am 24.04.19 um 04:27 schrieb Junio C Hamano:
> "brian m. carlson" writes:
>> +static int has_hook(struct strbuf *path, int strip)
>> +{
>> +if (access(path->buf, X_OK) < 0) {
>
> Does ".git/post-commit" that is not an executable exist?
>
> It was perfectly fine for find_hook() to say "there
Am 15.04.19 um 21:20 schrieb Randall S. Becker:
> What is strange is that GIT_SSH_COMMAND='/usr/bin/ssh -v' should not
> execute if we are just looking at an object path. It should be broken
> into '/usr/bin/ssh' and '-v' otherwise spawn* or exec* will not
> execute it. I'm still trying to understa
Am 15.04.19 um 01:29 schrieb Eric Sunshine:
> On Sun, Apr 14, 2019 at 5:10 PM Thomas Gummerer wrote:
>> + strbuf_remove(&line, 0, 4);
>> + if (!strcmp(filename_a.buf, "/dev/null")) {
>> + strbuf_addstr(&buf, "new fil
Am 05.04.19 um 19:25 schrieb Denton Liu:
> On Fri, Apr 05, 2019 at 04:55:37PM +0200, Johannes Schindelin wrote:
>> On Mon, 1 Apr 2019, Denton Liu wrote:
>>> +test_rebase() {
>>> + expected="$1" &&
>>> + shift &&
>>> + test_expect_success "git rebase $@" "
>>> + git checkout master &
Am 03.04.19 um 09:32 schrieb Junio C Hamano:
> Denton Liu writes:
>
>> This is the first use of the '%n$' style of printf format in the
>> *.[ch] files in our codebase, but it's supported by POSIX[1] and there
>> are existing uses for it in po/*.po files, so hopefully it won't cause
>
> The latt
Am 25.03.19 um 07:40 schrieb Jeffrey Walton:
> I'm working on a low-resource dev-board. It is missing a lot of
> utilities to save space. I'm building Git 2.20 from sources. Make is
> failing due to '/bin/sh: 1: msgfmt: not found'. I don't cross-compile
> because that's a bigger pain in the ass tha
Am 18.03.19 um 17:15 schrieb Ævar Arnfjörð Bjarmason:
> +Using this option may optimize for disk space at the expense of
> +runtime performance. See the `--depth` and `--window` documentation in
> +linkgit:git-repack[1]. It is not recommended that this option be used
> +to improve performance for a
Am 16.03.19 um 23:09 schrieb Robert P. J. Day:
> On Sat, 16 Mar 2019, Johannes Sixt wrote:
>
>> Am 16.03.19 um 13:22 schrieb Robert P. J. Day:
>>> as a working example, i looked at the top-level .gitattributes file
>>> in the git source code itself, which open
Am 16.03.19 um 13:22 schrieb Robert P. J. Day:
> as a working example, i looked at the top-level .gitattributes file
> in the git source code itself, which opens with:
>
> * whitespace=!indent,trail,space
> *.[ch] whitespace=indent,trail,space diff=cpp
> *.sh whitespace=indent,trail,space
Am 16.03.19 um 10:49 schrieb Johannes Schindelin via GitGitGadget:
> diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh
> index 3e0a61db23..918bc323ab 100755
> --- a/t/t7519-status-fsmonitor.sh
> +++ b/t/t7519-status-fsmonitor.sh
> @@ -346,4 +346,14 @@ test_expect_success UNTRAC
Am 13.03.19 um 17:35 schrieb Jeff King:
> On Wed, Mar 13, 2019 at 05:11:44PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> As a further improvement, is there a good reason for why we wouldn't
>> pass something down to the oid machinery to say "we're only interested
>> in commits". I have a WIP series so
Am 12.03.19 um 22:01 schrieb Ævar Arnfjörð Bjarmason:
>
> On Tue, Mar 12 2019, Andreas Schwab wrote:
>
>> On Mär 12 2019, Junio C Hamano wrote:
>>
>>> I however think it may be worth making sure that our docs do not
>>> encourage "diff A..B" and teach "diff A B" when comparing two
>>> endpoints.
Am 10.03.19 um 23:41 schrieb Anthony Sottile:
> git init longname-repo
> cd longname-repo
> touch f
> git add ..\longna~1\f
>
...
>
> C:\Users\Anthony\AppData\Local\Temp\t\pre-commit-hooks\longname-repo>git
> add ..\longna~1\f
> fatal: ..\longna~1\f: '..\longna~1\f' is outside repository
This ha
Am 28.02.19 um 22:43 schrieb Manuel Guilamo:
> I accidentally executed git reset —hard in a project that doesn’t
> have any commits yet. git erased everything, everything I’ve worked
> the past week, I believe this is not a desired behavior, considering
> I’m not able to undo that action, because g
Am 27.02.19 um 19:50 schrieb Randall S. Becker:
> On February 27, 2019 13:18, Michal Suchánek wrote:
>> What are your requirements, exactly?
> Source code and comments contain SJIS content. The requirement is to
> be able to move seamlessly in and out of git, and have git show/diff/log
> display SJ
Am 14.02.19 um 09:22 schrieb Viresh Kumar:
> Hello,
>
> I am not sure if it is a bug or not, but the output I got wasn't what
> I was looking for. And so looking for some help. I was looking to send
> pull request [1] to PM maintainer and was generating the request
> against his tree [2], which al
Am 12.02.19 um 18:24 schrieb Junio C Hamano:
>>> diff --git a/t/t5562-http-backend-content-length.sh
>>> b/t/t5562-http-backend-content-length.sh
>>> @@ -143,14 +143,14 @@ test_expect_success GZIP 'push gzipped empty' '
>>> test_expect_success 'CONTENT_LENGTH overflow ssite_t' '
>>> NOT_F
Am 10.02.19 um 00:29 schrieb Jeff King:
> On Sat, Feb 09, 2019 at 09:39:43AM +0100, Johannes Sixt wrote:
>> dd of="$objdir/info/commit-graph" bs=1 seek="$zero_pos" count=0 &&
>> -dd if=/dev/zero of="$objdir/info/commit-graph" bs=1
Am 09.02.19 um 19:25 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> How many bytes are needed here? yes() in test-lib.sh generates only 99
>> 'y', if I am not mistaken.
>
> I think we will not use "yes" in the end for this topic, which makes
>
Am 08.02.19 um 23:07 schrieb randall.s.bec...@rogers.com:
> From: "Randall S. Becker"
>
> Replaced subtest 15 (CONTENT_LENGTH overflow ssite_t) use of /dev/zero
> with yes and a translation of its result to a stream of NULL. This is
> a more portable solution.
>
> Signed-off-by: Randall S. Becke
/dev/zero elsewhere, do you want to wrap it up in a patch as part of
> that?
Please do not use yes to generate an infinite amount of bytes. Our
implementation of yes() in test-lib.sh generates only 99 lines.
Perhaps do this.
- 8< -
Subject: [PATCH] t5318: avoid /dev/zero
Some
Am 08.02.19 um 19:03 schrieb Jeff King:
> On Fri, Feb 08, 2019 at 12:49:59PM -0500, Randall S. Becker wrote:
>> Would you object to something like this:
>>
>> if [ ! -e /dev/zero ]; then
>> # use shred or some other mechanism (still trying to figure out a
>> solution)
>> else
>> # existi
Am 06.02.19 um 12:56 schrieb Johannes Schindelin:
> On Tue, 5 Feb 2019, Johannes Sixt wrote:
>> Am 05.02.19 um 12:06 schrieb Johannes Schindelin:
>>> The real examples are much more mundane, and very different from what you
>>> suspected, e.g. inserting the tag heade
Am 05.02.19 um 12:06 schrieb Johannes Schindelin:
> The real examples are much more mundane, and very different from what you
> suspected, e.g. inserting the tag header before the tag message in
> `create_tag()` in `builtin/tag.c`. Basically, it is building up a strbuf
> for the sake of calling `st
Am 04.02.19 um 11:38 schrieb Johannes Schindelin:
> On Mon, 4 Feb 2019, Johannes Sixt wrote:
>
>> Am 03.02.19 um 17:51 schrieb Johannes Sixt:
>>> strbuf_vinsertf inserts a formatted string in the middle of an existing
>>> strbuf value.
>>
>> Quite frankl
Am 03.02.19 um 17:51 schrieb Johannes Sixt:
> strbuf_vinsertf inserts a formatted string in the middle of an existing
> strbuf value.
Quite frankly, this is a really unusual operation, and I'd prefer to get
rid of it. There is only one call, and it looks like it only wants to be
lazy a
the number of characters available in the allocated space
behind the final string. This does not make any sense at all.
Fix it to pass the length of the inserted string plus one for the NUL.
(The functions saves and restores the character that the NUL occupies.)
Signed-off-by: Johannes Sixt
Am 10.01.19 um 04:28 schrieb Jiang Xin:
SZEDER Gábor 于2019年1月9日周三 下午8:56写道：
Use something like
find .git/objects -type f | grep -v pack >out &&
test_must_be_empty out
instead, so we get an informative error message on failure.
if `grep -v pack` return empty output, it will return erro
Am 09.01.19 um 01:44 schrieb Stephen P. Smith:
On Tuesday, January 8, 2019 2:27:22 PM MST Johannes Sixt wrote:
Am 31.12.18 um 01:31 schrieb Stephen P. Smith:
+
+TODAY_REGEX='[A-Z][a-z][a-z] [012][0-9]:[0-6][0-9] .0200'
The $...REGEX expansions must be put in double-quotes to pr
Am 31.12.18 um 01:31 schrieb Stephen P. Smith:
+check_human_date () {
+ time=$1
+ expect=$2
+ test_expect_success "check date ($format:$time)" '
+ echo "$time -> $expect" >expect &&
+ TZ=${zone:-$TZ} test-tool date show:"$format" "$time" >actual &&
+
Am 02.01.19 um 00:19 schrieb SZEDER Gábor:
Alas, it has been reported that NetBSD's /bin/sh does complain about
them:
./test-lib.sh: 327: Syntax error: Bad substitution
where line 327 contains the first ${BASH_VERSINFO[0]} array access.
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0f1
Am 28.12.18 um 00:45 schrieb brian m. carlson:
On Thu, Dec 27, 2018 at 08:55:27PM +0100, Johannes Sixt wrote:
But why do you add another U+FEFF on the way to UTF-8? There is one in the
incoming UTF-16 data, and only *that* one must be converted. If there is no
U+FEFF in the UTF-16 data, the
Am 27.12.18 um 17:43 schrieb brian m. carlson:
On Thu, Dec 27, 2018 at 11:06:17AM +0100, Johannes Sixt wrote:
It worries me that theoretical correctness is regarded higher than existing
practice. I do not care a lot what some RFC tells what programs should do if
the majority of the software
Am 27.12.18 um 03:17 schrieb brian m. carlson:
We've recently fielded several reports from unhappy Windows users about
our handling of UTF-16, UTF-16LE, and UTF-16BE, none of which seem to be
suitable for certain Windows programs.
In an effort to communicate the reasons for our behavior more
eff
Am 13.12.18 um 07:25 schrieb Johannes Sixt:
Am 13.12.18 um 03:48 schrieb Junio C Hamano:
So,... what's the conclusion? The patch in the context of my tree
would be a no-op, and we'd need a prerequisite change to the support
function to accompany this patch to be effective?
Correc
Am 13.12.18 um 03:48 schrieb Junio C Hamano:
So,... what's the conclusion? The patch in the context of my tree
would be a no-op, and we'd need a prerequisite change to the support
function to accompany this patch to be effective?
Correct, that is my conclusion.
-- Hannes
Am 12.12.18 um 01:42 schrieb Steven Penny:
On Tue, Dec 11, 2018 at 7:39 AM Johannes Schindelin wrote:
- pc-windows
- pc-win
- win
I find all of those horrible.
one windows triplet in use is "x86_64-pc-windows", used by Rust:
https://forge.rust-lang.org/other-installation-methods.html
which
Am 11.12.18 um 12:25 schrieb Johannes Schindelin:
On Mon, 10 Dec 2018, Johannes Sixt wrote:
diff --git a/compat/mingw.c b/compat/mingw.c
index 34b3880b29..4d009901d8 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -928,11 +928,19 @@ unsigned int sleep (unsigned int seconds)
char
Am 10.12.18 um 20:04 schrieb Johannes Schindelin via GitGitGadget:
The idea was brought up by Paul Morelle.
To be honest, this idea of rescheduling a failed exec makes so much sense
that I wish we had done this from the get-go.
The status quo was actually not that bad a decision, because it ma
Am 10.12.18 um 19:47 schrieb Johannes Schindelin via GitGitGadget:
From: Johannes Schindelin
When specifying an absolute path without a drive prefix, we convert that
path internally. Let's make sure that we handle that case properly, too
;-)
This fixes the command
git clone https://gi
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
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
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 fin
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
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 turn
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
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 i
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 eol=
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 e
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* sh
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 (be
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 '-' lin
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 reposit
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
---
compat
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
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 a
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 o
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 64-bit
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 l
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 alrea
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 n
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
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
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 different
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 c
The pick 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 +++
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
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
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 pat
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
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 dem
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
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
---
diff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(
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 corre
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
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 exp
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 datestam
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
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 wan
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 o
101 - 200 of 1357 matches
Mail list logo
