* [PATCH 3/3] color.c: Alias RGB colors 8-15 to aixterm colors
From: Eyal Soha @ 2020-01-10 15:05 UTC (permalink / raw)
To: peff, git; +Cc: Eyal Soha
In-Reply-To: <20200110150547.221314-1-shawarmakarma@gmail.com>
Signed-off-by: Eyal Soha <shawarmakarma@gmail.com>
---
color.c | 7 ++++++-
t/t4026-color.sh | 4 ++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/color.c b/color.c
index 4dbf12eff8..7f9f929fb6 100644
--- a/color.c
+++ b/color.c
@@ -132,11 +132,16 @@ static int parse_color(struct color *out, const char *name, int len)
else if (val < 0) {
out->type = COLOR_NORMAL;
return 0;
- /* Rewrite low numbers as more-portable standard colors. */
+ /* Rewrite 0-7 as more-portable standard colors. */
} else if (val < 8) {
out->type = COLOR_ANSI;
out->value = val + COLOR_FOREGROUND_ANSI;
return 0;
+ /* Rewrite 8-15 as more-portable aixterm colors. */
+ } else if (val < 16) {
+ out->type = COLOR_ANSI;
+ out->value = val - 8 + COLOR_FOREGROUND_BRIGHT_ANSI;
+ return 0;
} else if (val < 256) {
out->type = COLOR_256;
out->value = val;
diff --git a/t/t4026-color.sh b/t/t4026-color.sh
index 78c69de90a..c0b642c1ab 100755
--- a/t/t4026-color.sh
+++ b/t/t4026-color.sh
@@ -82,6 +82,10 @@ test_expect_success '0-7 are aliases for basic ANSI color names' '
color "0 7" "[30;47m"
'
+test_expect_success '8-15 are aliases for aixterm color names' '
+ color "12 13" "[94;105m"
+'
+
test_expect_success '256 colors' '
color "254 bold 255" "[1;38;5;254;48;5;255m"
'
--
2.24.1.591.g12029dc57d.dirty
^ permalink raw reply related
* [PATCH 2/3] color.c: Support bright aixterm colors
From: Eyal Soha @ 2020-01-10 15:05 UTC (permalink / raw)
To: peff, git; +Cc: Eyal Soha
In-Reply-To: <20200110150547.221314-1-shawarmakarma@gmail.com>
These colors are the bright variants of the 3-bit colors.
Signed-off-by: Eyal Soha <shawarmakarma@gmail.com>
---
color.c | 30 +++++++++++++++++++++++-------
t/t4026-color.sh | 8 ++++++++
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/color.c b/color.c
index 0549501f47..4dbf12eff8 100644
--- a/color.c
+++ b/color.c
@@ -29,6 +29,7 @@ enum {
COLOR_FOREGROUND_ANSI = 30,
COLOR_FOREGROUND_RGB = 38,
COLOR_FOREGROUND_256 = 38,
+ COLOR_FOREGROUND_BRIGHT_ANSI = 90,
};
/* Ignore the RESET at the end when giving the size */
@@ -68,13 +69,32 @@ static int get_hex_color(const char *in, unsigned char *out)
return 0;
}
-static int parse_color(struct color *out, const char *name, int len)
+static int parse_ansi_color(struct color *out, const char *name, int len)
{
/* Positions in array must match ANSI color codes */
static const char * const color_names[] = {
"black", "red", "green", "yellow",
"blue", "magenta", "cyan", "white"
};
+
+ int color_offset = COLOR_FOREGROUND_ANSI;
+ if (strncasecmp(name, "bright", 6) == 0) {
+ color_offset = COLOR_FOREGROUND_BRIGHT_ANSI;
+ name += 6;
+ len -= 6;
+ }
+ for (int i = 0; i < ARRAY_SIZE(color_names); i++) {
+ if (match_word(name, len, color_names[i])) {
+ out->type = COLOR_ANSI;
+ out->value = i + color_offset;
+ return 1;
+ }
+ }
+ return 0;
+}
+
+static int parse_color(struct color *out, const char *name, int len)
+{
char *end;
int i;
long val;
@@ -96,12 +116,8 @@ static int parse_color(struct color *out, const char *name, int len)
}
/* Then pick from our human-readable color names... */
- for (i = 0; i < ARRAY_SIZE(color_names); i++) {
- if (match_word(name, len, color_names[i])) {
- out->type = COLOR_ANSI;
- out->value = i + COLOR_FOREGROUND_ANSI;
- return 0;
- }
+ if (parse_ansi_color(out, name, len)) {
+ return 0;
}
/* And finally try a literal 256-color-mode number */
diff --git a/t/t4026-color.sh b/t/t4026-color.sh
index 671e951ee5..78c69de90a 100755
--- a/t/t4026-color.sh
+++ b/t/t4026-color.sh
@@ -30,6 +30,14 @@ test_expect_success 'attribute before color name' '
color "bold red" "[1;31m"
'
+test_expect_success 'aixterm bright fg color' '
+ color "brightred" "[91m"
+'
+
+test_expect_success 'aixterm bright bg color' '
+ color "green brightblue" "[32;104m"
+'
+
test_expect_success 'color name before attribute' '
color "red bold" "[1;31m"
'
--
2.24.1.591.g12029dc57d.dirty
^ permalink raw reply related
* [PATCH 1/3] color.c: Refactor color_output to use enums
From: Eyal Soha @ 2020-01-10 15:05 UTC (permalink / raw)
To: peff, git; +Cc: Eyal Soha
In-Reply-To: <20200110111516.GA474613@coredump.intra.peff.net>
Signed-off-by: Eyal Soha <shawarmakarma@gmail.com>
---
color.c | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/color.c b/color.c
index ebb222ec33..0549501f47 100644
--- a/color.c
+++ b/color.c
@@ -24,6 +24,13 @@ const char *column_colors_ansi[] = {
GIT_COLOR_RESET,
};
+enum {
+ COLOR_BACKGROUND_OFFSET = 10,
+ COLOR_FOREGROUND_ANSI = 30,
+ COLOR_FOREGROUND_RGB = 38,
+ COLOR_FOREGROUND_256 = 38,
+};
+
/* Ignore the RESET at the end when giving the size */
const int column_colors_ansi_max = ARRAY_SIZE(column_colors_ansi) - 1;
@@ -92,7 +99,7 @@ static int parse_color(struct color *out, const char *name, int len)
for (i = 0; i < ARRAY_SIZE(color_names); i++) {
if (match_word(name, len, color_names[i])) {
out->type = COLOR_ANSI;
- out->value = i;
+ out->value = i + COLOR_FOREGROUND_ANSI;
return 0;
}
}
@@ -112,7 +119,7 @@ static int parse_color(struct color *out, const char *name, int len)
/* Rewrite low numbers as more-portable standard colors. */
} else if (val < 8) {
out->type = COLOR_ANSI;
- out->value = val;
+ out->value = val + COLOR_FOREGROUND_ANSI;
return 0;
} else if (val < 256) {
out->type = COLOR_256;
@@ -166,23 +173,22 @@ int color_parse(const char *value, char *dst)
* already have the ANSI escape code in it. "out" should have enough
* space in it to fit any color.
*/
-static char *color_output(char *out, int len, const struct color *c, char type)
+static char *color_output(char *out, int len, const struct color *c, int offset)
{
switch (c->type) {
case COLOR_UNSPECIFIED:
case COLOR_NORMAL:
break;
case COLOR_ANSI:
- if (len < 2)
- BUG("color parsing ran out of space");
- *out++ = type;
- *out++ = '0' + c->value;
+ out += xsnprintf(out, len, "%d", c->value + offset);
break;
case COLOR_256:
- out += xsnprintf(out, len, "%c8;5;%d", type, c->value);
+ out += xsnprintf(out, len, "%d;5;%d", COLOR_FOREGROUND_256 + offset,
+ c->value);
break;
case COLOR_RGB:
- out += xsnprintf(out, len, "%c8;2;%d;%d;%d", type,
+ out += xsnprintf(out, len, "%d;2;%d;%d;%d",
+ COLOR_FOREGROUND_RGB + offset,
c->red, c->green, c->blue);
break;
}
@@ -280,13 +286,13 @@ int color_parse_mem(const char *value, int value_len, char *dst)
if (sep++)
OUT(';');
/* foreground colors are all in the 3x range */
- dst = color_output(dst, end - dst, &fg, '3');
+ dst = color_output(dst, end - dst, &fg, 0);
}
if (!color_empty(&bg)) {
if (sep++)
OUT(';');
/* background colors are all in the 4x range */
- dst = color_output(dst, end - dst, &bg, '4');
+ dst = color_output(dst, end - dst, &bg, COLOR_BACKGROUND_OFFSET);
}
OUT('m');
}
--
2.24.1.591.g12029dc57d.dirty
^ permalink raw reply related
* Re: Fwd: Add support for axiterm colors in parse_color
From: Eyal Soha @ 2020-01-10 15:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20200110111516.GA474613@coredump.intra.peff.net>
Thanks. I think that 3 patches are in order. The first will refactor
and add the enums. The second will add the aixterm colors. The last
will alias RGB 8-15 to aixterm colors.
What's the correct way to email those patches? I will try with
git-send-email. BTW, is "git help send-email" supposed to work?
Eyal
On Fri, Jan 10, 2020 at 6:15 AM Jeff King <peff@peff.net> wrote:
>
> On Thu, Jan 09, 2020 at 07:20:09PM -0500, Eyal Soha wrote:
>
> > > That said, I'm not entirely opposed to having more human-readable
> > > aliases. I'm not sure if it's worth using the 16-color version (e.g.,
> > > "ESC[91m" versus the 256-color version "ESC[38;5;9m"). It's possible it
> > > would be compatible with more terminals, and it is slightly fewer bytes.
> >
> > My motivation for this patch was to fix the github workflow log output
> > that doesn't support 8bit colors properly. Only the "ANSI" colors
> > 0-15 worked. None of the 8-bit colors worked except for 30-37, 40-47,
> > 90-97, and 100-107, which matched the ANSI colors. That is a very
> > broken color scheme! But that's how it displayed.
>
> That makes sense. I'm not too surprised to see a terminal that supports
> one but not the other.
>
> But I wonder if there are ones that go the other way around: supporting
> 256-color mode but not ANSI 90-97, etc. I doubt it, but I think it would
> be nice to split that change out into a separate commit in case we do
> run into problems.
>
> > Done. Here's a new patch!
>
> Thanks. The content here is looking pretty good (though I have a few
> comments below).
>
> Can you also format it as described in Documentation/SubmittingPatches
> and re-send? In particular, it needs a regular commit message and your
> signoff.
>
> > +enum {
> > + COLOR_BACKGROUND_OFFSET = 10,
> > + COLOR_FOREGROUND_ANSI = 30,
> > + COLOR_FOREGROUND_RGB = 38,
> > + COLOR_FOREGROUND_256 = 38,
> > + COLOR_FOREGROUND_BRIGHT_ANSI = 90,
> > +};
>
> The split in this enum mostly makes sense to me. It changes the meaning
> of "value" for COLOR_ANSI, but this is all local to color.c, so your
> changes to output_color() are all that's needed.
>
> It might be easier to follow the patch if switching to this enum came in
> a separate preparatory patch.
>
> > @@ -92,7 +100,13 @@ static int parse_color(struct color *out, const
> > char *name, int len)
> > for (i = 0; i < ARRAY_SIZE(color_names); i++) {
> > if (match_word(name, len, color_names[i])) {
> > out->type = COLOR_ANSI;
> > - out->value = i;
> > + out->value = i + COLOR_FOREGROUND_ANSI;
> > + return 0;
> > + }
> > + if (*name == '+' &&
> > + match_word(name+1, len-1, color_names[i])) {
> > + out->type = COLOR_ANSI;
> > + out->value = i + COLOR_FOREGROUND_BRIGHT_ANSI;
> > return 0;
> > }
>
> It would be slightly simpler and more efficient handle the "+" outside
> the loop, like:
>
> int offset = COLOR_FOREGROUND_ANSI;
> if (*name == '+') {
> offset = COLOR_FOREGROUND_BRIGHT_ANSI;
> name++;
> len--;
> }
>
> and then in the loop just set "out->value = i + offset".
>
> You'd probably want to hoist this out to a separate function since
> "name" needs to be unchanged in the later part of the function.
>
> I dunno. It's almost certainly an unmeasurable micro-optimization, but
> somehow the flow of it seems simpler to me.
>
> I also wondered if we'd want English aliases like "brightred" that some
> other systems use. It would be easy to add that to the check I showed
> above without having to repeat as much.
>
> > @@ -109,10 +123,15 @@ static int parse_color(struct color *out, const
> > char *name, int len)
> > else if (val < 0) {
> > out->type = COLOR_NORMAL;
> > return 0;
> > - /* Rewrite low numbers as more-portable standard colors. */
> > + /* Rewrite 0-7 as more-portable standard colors. */
> > } else if (val < 8) {
> > out->type = COLOR_ANSI;
> > - out->value = val;
> > + out->value = val + COLOR_FOREGROUND_ANSI;
> > + return 0;
> > + /* Rewrite 8-15 as more-portable aixterm colors. */
> > + } else if (val < 16) {
> > + out->type = COLOR_ANSI;
> > + out->value = val - 8 + COLOR_FOREGROUND_BRIGHT_ANSI;
>
> And I think this 8-15 handling might want to be a separate commit on
> top, just because it's possible it might regress some cases (though
> again, I do doubt it).
>
> > case COLOR_256:
> > - out += xsnprintf(out, len, "%c8;5;%d", type, c->value);
> > + out += xsnprintf(out, len, "%d;5;%d", COLOR_FOREGROUND_256 + offset,
> > + c->value);
>
> Looks like some unwanted tab/space conversion (here and elsewhere).
>
> > +test_expect_success 'axiterm bright fg color' '
> > + color "+red" "[91m"
>
> s/axi/aix/ (here and below).
>
> > +test_expect_success '8-15 are aliases for aixterm color names' '
> > + color "12 13" "[94;105m"
>
> Makes sense.
>
> -Peff
^ permalink raw reply
* Re: [PATCH v2 00/17] merge: learn --autostash
From: Phillip Wood @ 2020-01-10 14:44 UTC (permalink / raw)
To: Denton Liu, phillip.wood
Cc: Junio C Hamano, Git Mailing List, Alban Gruin,
Johannes Schindelin
In-Reply-To: <20200108060842.GA51465@generichostname>
Hi Denton
On 08/01/2020 06:08, Denton Liu wrote:
> Hi Phillip,
>
> Sorry for the late reply. I'm back in school so I've been pretty busy
> lately.
>
> On Tue, Dec 31, 2019 at 10:34:30AM +0000, Phillip Wood wrote:
>> For `merge --autostash` I think we need to consider the interaction of
>> `--no-commit` with `--autostash` as `stash pop` will refuse to run if the
>> merge modified any of the stashed paths.
>
> The only time when we run the `stash pop` is when we either commit the
> merge or abort it. With this in mind, what do you think of the following
> test cases? If they look good, I can squash them into the appropriate
> patch and send in a reroll.
Ah I misunderstood what happened with --autostash and --no-commit, the
tests basically look fine (I've got one comment below).
One other thing - if the user runs `git reset` or `git checkout
<branch>` then cleanup_branch_state() removes MERGE_HEAD, MERGE_MSG etc.
If we're not already doing so then I think we should remove
MERGE_AUTOSTASH as well or you can get into a situation where the user
does something like
git merge --autostash <something> # results in conflicts
git reset --hard <somewhere else>
git merge <something> # succeeds and confusingly pops previous stash
Running `git reset` doesn't make sense unless they want to discard the
stashed changes as well. This is a difference with rebase where you
cannot lose the stashed changes by running `git reset`, the only way
they can get lost is by running `rebase --quit`. We could always add a
warning about it throwing away the stashed changes in the future.
I still not keen on the name `--autostash` as it's not automatic.
`--stash` would make more sense to me. We'd have to deprecate `rebase
--autostash` in favor of `rebase --stash` to change it but it if we want
to change the name it would be better now before adding `--autostash` to
merge and pull - what do you think?
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index e0c8a0bad4..af5db58e16 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -727,6 +727,33 @@ test_expect_success 'conflicted merge with --autostash, --abort restores stash'
> test_cmp file.1 file
> '
>
> +test_expect_success 'completed merge with --no-commit and --autostash' '
> + git reset --hard c1 &&
> + git merge-file file file.orig file.9 &&
Is this a complicated way of getting some unstaged changes so we can
stash them or have I missed something?
Best Wishes
Phillip
> + git diff >expect &&
> + git merge --no-commit --autostash c2 &&
> + git stash show -p MERGE_AUTOSTASH >actual &&
> + test_cmp expect actual &&
> + git commit 2>err &&
> + test_i18ngrep "Applied autostash." err &&
> + git show HEAD:file >merge-result &&
> + test_cmp result.1-5 merge-result &&
> + test_cmp result.1-5-9 file
> +'
> +
> +test_expect_success 'aborted merge with --no-commit and --autostash' '
> + git reset --hard c1 &&
> + git merge-file file file.orig file.9 &&
> + git diff >expect &&
> + git merge --no-commit --autostash c2 &&
> + git stash show -p MERGE_AUTOSTASH >actual &&
> + test_cmp expect actual &&
> + git merge --abort 2>err &&
> + test_i18ngrep "Applied autostash." err &&
> + git diff >actual &&
> + test_cmp expect actual
> +'
> +
> test_expect_success 'merge with conflicted --autostash changes' '
> git reset --hard c1 &&
> git merge-file file file.orig file.9y &&
>
> Thanks,
>
> Denton
>
>>
>> Best Wishes
>>
>> Phillip
^ permalink raw reply
* Re: Question about the pack OBJ_OFS_DELTA format
From: Erik Fastermann @ 2020-01-10 13:56 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20200110095707.GA459765@coredump.intra.peff.net>
Thanks mate. That helped me a lot.
Erik
^ permalink raw reply
* Re: [PATCH] userdiff: add Julia to supported userdiff languages
From: Johannes Schindelin @ 2020-01-10 13:51 UTC (permalink / raw)
To: Ryan Zoeller via GitGitGadget; +Cc: git, Ryan Zoeller
In-Reply-To: <pull.521.git.1578625810098.gitgitgadget@gmail.com>
Hi,
On Fri, 10 Jan 2020, Ryan Zoeller via GitGitGadget wrote:
> Add xfuncname and word_regex patterns for Julia[1],
> which is a language used in numerical analysis and
> computational science.
>
> The default behavior for xfuncname did not allow
> functions to be indented, nor functions to have a
> macro applied, such as @inline or @generated.
>
> [1]: https://julialang.org
>
> Signed-off-by: Ryan Zoeller <rtzoeller@rtzoeller.com>
> ---
> userdiff: add Julia to supported userdiff languages
>
> Add xfuncname and word_regex patterns for Julia1 [https://julialang.org]
> , which is a language used in numerical analysis and computational
> science.
>
> The default behavior for xfuncname did not allow functions to be
> indented, nor functions to have a macro applied, such as @inline or
> @generated.
>
> Signed-off-by: Ryan Zoeller rtzoeller@rtzoeller.com
> [rtzoeller@rtzoeller.com]
Sorry about that. In my recent work to fold in the cover letter into
single-patch contributions, it was mentioned that this could come back to
bite us: By default, GitHub uses the commit message of single-commit PRs
as PR description, and if contributors do not change that, it essentially
repeats the commit message.
Sadly, I won't be able to justify working even more on GitGitGadget this
week (it took a sizable chunk out of my time budget and I have to make up
for that first).
Ciao,
Johannes
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-521%2Frtzoeller%2Fjulia_userdiff-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-521/rtzoeller/julia_userdiff-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/521
>
> Documentation/gitattributes.txt | 2 ++
> t/t4018-diff-funcname.sh | 1 +
> t/t4018/julia-function | 5 +++++
> t/t4018/julia-indented-function | 8 ++++++++
> t/t4018/julia-inline-function | 5 +++++
> t/t4018/julia-macro | 5 +++++
> t/t4018/julia-mutable-struct | 5 +++++
> t/t4018/julia-struct | 5 +++++
> userdiff.c | 15 +++++++++++++++
> 9 files changed, 51 insertions(+)
> create mode 100644 t/t4018/julia-function
> create mode 100644 t/t4018/julia-indented-function
> create mode 100644 t/t4018/julia-inline-function
> create mode 100644 t/t4018/julia-macro
> create mode 100644 t/t4018/julia-mutable-struct
> create mode 100644 t/t4018/julia-struct
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 508fe713c4..d39dc727e3 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -824,6 +824,8 @@ patterns are available:
>
> - `java` suitable for source code in the Java language.
>
> +- `julia` suitable for source code in the Julia language.
> +
> - `matlab` suitable for source code in the MATLAB and Octave languages.
>
> - `objc` suitable for source code in the Objective-C language.
> diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
> index c0f4839543..d4613eb7d2 100755
> --- a/t/t4018-diff-funcname.sh
> +++ b/t/t4018-diff-funcname.sh
> @@ -38,6 +38,7 @@ diffpatterns="
> golang
> html
> java
> + julia
> matlab
> objc
> pascal
> diff --git a/t/t4018/julia-function b/t/t4018/julia-function
> new file mode 100644
> index 0000000000..a2eab83c27
> --- /dev/null
> +++ b/t/t4018/julia-function
> @@ -0,0 +1,5 @@
> +function RIGHT()
> + # A comment
> + # Another comment
> + return ChangeMe
> +end
> diff --git a/t/t4018/julia-indented-function b/t/t4018/julia-indented-function
> new file mode 100644
> index 0000000000..2d48aabcdb
> --- /dev/null
> +++ b/t/t4018/julia-indented-function
> @@ -0,0 +1,8 @@
> +function outer_function()
> + function RIGHT()
> + for i = 1:10
> + print(i)
> + end
> + # ChangeMe
> + end
> +end
> diff --git a/t/t4018/julia-inline-function b/t/t4018/julia-inline-function
> new file mode 100644
> index 0000000000..5806f224fb
> --- /dev/null
> +++ b/t/t4018/julia-inline-function
> @@ -0,0 +1,5 @@
> +@inline function RIGHT()
> + # Prints Hello, then something else.
> + println("Hello")
> + println("ChangeMe")
> +end
> diff --git a/t/t4018/julia-macro b/t/t4018/julia-macro
> new file mode 100644
> index 0000000000..1d18bc2750
> --- /dev/null
> +++ b/t/t4018/julia-macro
> @@ -0,0 +1,5 @@
> +macro RIGHT()
> + # First comment
> + # Second comment
> + return :( println("ChangeMe") )
> +end
> diff --git a/t/t4018/julia-mutable-struct b/t/t4018/julia-mutable-struct
> new file mode 100644
> index 0000000000..db82017ba0
> --- /dev/null
> +++ b/t/t4018/julia-mutable-struct
> @@ -0,0 +1,5 @@
> +mutable struct RIGHT
> + x
> + y::Int
> + ChangeMe
> +end
> diff --git a/t/t4018/julia-struct b/t/t4018/julia-struct
> new file mode 100644
> index 0000000000..d3d2bda8cb
> --- /dev/null
> +++ b/t/t4018/julia-struct
> @@ -0,0 +1,5 @@
> +struct RIGHT
> + x
> + y::Int
> + ChangeMe
> +end
> diff --git a/userdiff.c b/userdiff.c
> index efbe05e5a5..b5e938b1c2 100644
> --- a/userdiff.c
> +++ b/userdiff.c
> @@ -79,6 +79,21 @@ PATTERNS("java",
> "|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lL]?"
> "|[-+*/<>%&^|=!]="
> "|--|\\+\\+|<<=?|>>>?=?|&&|\\|\\|"),
> +PATTERNS("julia",
> + "^[ \t]*(((mutable[ \t]+)?struct|(@.+[ \t])?function|macro)[ \t].*)$",
> + /* -- */
> + /* Binary literals */
> + "[-+]?0b[01]+"
> + /* Hexadecimal literals */
> + "|[-+]?0x[0-9a-fA-F]+"
> + /* Real and complex literals */
> + "|[-+0-9.e_(im)]+"
> + /* Should theoretically allow Unicode characters as part of
> + * a word, such as U+2211. However, Julia reserves most of the
> + * U+2200-U+22FF range (as well as others) as user-defined operators,
> + * therefore they are not handled in this regex. */
> + "|[a-zA-Z_][a-zA-Z0-9_!]*"
> + "|--|\\+\\+|<<=?|>>>=?|>>=?|\\\\\\\\=?|//=?|&&|\\|\\||::|->|[-+*/<>%^&|=!$]=?"),
> PATTERNS("matlab",
> /*
> * Octave pattern is mostly the same as matlab, except that '%%%' and
>
> base-commit: 042ed3e048af08014487d19196984347e3be7d1c
> --
> gitgitgadget
>
^ permalink raw reply
* Re: [PATCH] RFC: allow branch --edit-description during rebase
From: SZEDER Gábor @ 2020-01-10 13:18 UTC (permalink / raw)
To: marcandre.lureau; +Cc: git
In-Reply-To: <20200110071929.119000-1-marcandre.lureau@redhat.com>
On Fri, Jan 10, 2020 at 11:19:29AM +0400, marcandre.lureau@redhat.com wrote:
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> This patch aims to allow editing of branch description during a rebase.
>
> A common use case of rebasing is to iterate over a series of patches
> after receiving reviews. During the rebase, various patches will be
> modified, and it is often requested to put a summary of the changes for
> the next version in the cover letter ("v2: - fixed this, - changed
> that.."). This helps the reviewer to focus on the difference with the
> previous version. Unfortunately, git branch --edit-description doesn't
> allow yet to modify the content during a rebase, and forces the author
> to use memory muscles to update the description after finishing the
> rebase.
That's not true, 'git branch --edit-description mybranch' already
allows you to edit the branch description of the currently rebased
branch (well, basically of any branch, really).
So it's not really about allowing '--edit-description' during rebase,
but choosing the default branch during rebase sensibly, and the
subject line could be something like "branch: let '--edit-description'
default to rebased branch during rebase", and the rest of the commit
message should be updated accordingly.
Having said that, I agree that defaulting to editing the description
of the rebased branch without an explicit branchname argument makes
sense. Even the git bash prompt shows the name of the rebased branch,
and then
~/src/git (mybranch|REBASE-i 1/2)$ git branch --edit-description
fatal: Cannot give description to detached HEAD
looks quite unhelpful.
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> builtin/branch.c | 19 ++++++++++++++++---
> worktree.c | 19 +++++++++++++++++++
> worktree.h | 7 +++++++
Tests? :)
I think it's worth checking '--edit-description' while rebasing a
branch, while rebasing a detached HEAD, and while rebasing in a
different worktree.
> 3 files changed, 42 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index d8297f80ff..f7122d31d6 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -613,6 +613,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
> int icase = 0;
> static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting;
> struct ref_format format = REF_FORMAT_INIT;
> + struct wt_status_state state;
This variable is only used for '--edit-description', and even then only
when on a detached head; please limit its scope.
> struct option options[] = {
> OPT_GROUP(N_("Generic options")),
> @@ -664,6 +665,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
>
> setup_ref_filter_porcelain_msg();
>
> + memset(&state, 0, sizeof(state));
> +
> memset(&filter, 0, sizeof(filter));
> filter.kind = FILTER_REFS_BRANCHES;
> filter.abbrev = -1;
> @@ -745,13 +748,21 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
> string_list_clear(&output, 0);
> return 0;
> } else if (edit_description) {
> - const char *branch_name;
> + const char *branch_name = NULL;
> struct strbuf branch_ref = STRBUF_INIT;
>
> if (!argc) {
> - if (filter.detached)
> + if (filter.detached) {
Please use tabs for indentation.
> + const struct worktree *wt = worktree_get_current();
> +
> + if (wt_status_check_rebase(wt, &state)) {
I think passing NULL as the 'wt' argument means "check the current
worktree". If that's indeed the case then you don't have to add that
worktree_get_current() function at all.
> + branch_name = state.branch;
> + }
> +
> + if (!branch_name)
> die(_("Cannot give description to detached HEAD"));
> - branch_name = head;
> + } else
> + branch_name = head;
> } else if (argc == 1)
> branch_name = argv[0];
> else
> @@ -851,5 +862,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
> } else
> usage_with_options(builtin_branch_usage, options);
>
> + free(state.branch);
> + free(state.onto);
> return 0;
> }
> diff --git a/worktree.c b/worktree.c
> index 5b4793caa3..0318c6f6a6 100644
> --- a/worktree.c
> +++ b/worktree.c
> @@ -396,6 +396,25 @@ int is_worktree_being_bisected(const struct worktree *wt,
> return found_rebase;
> }
>
> +const struct worktree *worktree_get_current(void)
> +{
> + static struct worktree **worktrees;
> + int i = 0;
> +
> + if (worktrees)
> + free_worktrees(worktrees);
> + worktrees = get_worktrees(0);
I'm not sure about this static worktrees array and how it is handled
here. I mean, can the current worktree change mid-process?
(Though this is moot if this function turns out to be unnecessary, as
mentioned above.)
> + for (i = 0; worktrees[i]; i++) {
> + struct worktree *wt = worktrees[i];
> +
> + if (wt->is_current)
> + return wt;
> + }
> +
> + return NULL;
> +}
> +
> /*
> * note: this function should be able to detect shared symref even if
> * HEAD is temporarily detached (e.g. in the middle of rebase or
> diff --git a/worktree.h b/worktree.h
> index caecc7a281..4fe2b78d24 100644
> --- a/worktree.h
> +++ b/worktree.h
> @@ -91,6 +91,13 @@ void free_worktrees(struct worktree **);
> const struct worktree *find_shared_symref(const char *symref,
> const char *target);
>
> +
> +/*
> + * Return the current worktree. The result may be destroyed by the
> + * next call.
> + */
> +const struct worktree *worktree_get_current(void);
> +
> /*
> * Similar to head_ref() for all HEADs _except_ one from the current
> * worktree, which is covered by head_ref().
>
> base-commit: 042ed3e048af08014487d19196984347e3be7d1c
> prerequisite-patch-id: 9b3cf75545ec4a1e702c8c2b2aae8edf241b87f2
> --
> 2.25.0.rc1.20.g2443f3f80d.dirty
>
^ permalink raw reply
* Re: [PATCH v2 1/1] branch: advise the user to checkout a different branch before deleting
From: Heba Waly @ 2020-01-10 12:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Eric Sunshine, Heba Waly via GitGitGadget,
Git List, Emily Shaffer
In-Reply-To: <xmqqsgkp220d.fsf@gitster-ct.c.googlers.com>
On Thu, Jan 9, 2020 at 8:15 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This is the first time I hear about anybody wanting to disable any advice
> > ...
> > I don't really think that this is desired, though.
>
> Me neither. We seem to have come up with more-or-less the same
> illustration, but such a global "turn all off" needs to be explained
> very well before we let users blindly use it, I think.
Thank you Dscho and Junio.
^ permalink raw reply
* Re: [PATCH v2 1/1] branch: advise the user to checkout a different branch before deleting
From: Heba Waly @ 2020-01-10 12:09 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Heba Waly via GitGitGadget, Git List, Junio C Hamano
In-Reply-To: <CAPig+cTDayF0hHn7wSPGNS8h2qPUYhhg9Z8fY_rLQnWmAg-NKQ@mail.gmail.com>
On Wed, Jan 8, 2020 at 10:28 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> My own feeling is that this level of hand-holding is unnecessary, at
> least until we a discover a good number of real-world cases in which
> people are baffled by how to deal with this situation. Adding the
> advice seems simple on the surface, but every new piece of advice
> means having to add yet another configuration variable, writing more
> code, more tests, and more documentation, and it needs to be
> maintained for the life of the project. So what seems simple at first
> glance, can end up being costly in terms of developer resources. For a
> bit of advice which doesn't seem to be needed by anyone (yet), all
> that effort seem unwarranted. Thus, my preference is to see the patch
> dropped.
That's Ok. We can drop it.
Thanks,
Heba
^ permalink raw reply
* Re: [PATCH v2 1/4] config: fix typo in variable name
From: Jeff King @ 2020-01-10 11:55 UTC (permalink / raw)
To: Matthew Rogers via GitGitGadget; +Cc: git, Matthew Rogers
In-Reply-To: <b40480f03a5643761bd06d4b9c495a99b98a1ac8.1578565001.git.gitgitgadget@gmail.com>
On Thu, Jan 09, 2020 at 10:16:38AM +0000, Matthew Rogers via GitGitGadget wrote:
> - OPT_BOOL('z', "null", &end_null, N_("terminate values with NUL byte")),
> + OPT_BOOL('z', "null", &end_nul, N_("terminate values with NUL byte")),
The user-facing option is still spelled "null". Obviously we can't just
change that, but if we are trying to prefer "nul", should we offer both?
I think we actually _do_ allow "--nul" because of parse-option's
willingness to accept a partial name. But if we wanted to advertise one
over the other in "-h", then we'd have to set up the alias ourselves.
Interestingly, "xargs" (and GNU grep) spells it as "--null", so perhaps
that's an argument to keep it as-is. Likewise if we accept that "null
termination" is a correct name, I suppose.
-Peff
^ permalink raw reply
* Re: [PATCH] unpack-trees: correctly compute result count
From: Derrick Stolee @ 2020-01-10 11:30 UTC (permalink / raw)
To: Jeff King, Derrick Stolee via GitGitGadget
Cc: git, Johannes Schindelin, Derrick Stolee
In-Reply-To: <d9a465bf-843b-2a8f-66c0-73fb706dbfc0@gmail.com>
On 1/10/2020 6:24 AM, Derrick Stolee wrote:
> On 1/10/2020 5:37 AM, Jeff King wrote:
>> On Fri, Jan 10, 2020 at 01:59:30AM +0000, Derrick Stolee via GitGitGadget wrote:
>>>
>>> As for making it into the release, I don't know. The change is small, it
>>> has a very limited scope, but this flaw is also not really hurting
>>> anything in a major way.
>>
>> I could go either way.
>>
>> This counts as something small and obvious enough that I'd consider
>> slipping it in at the last minute if it were fixing a bad bug. But given
>> how minor the bug is, being conservative makes sense to me, if only
>> because it's good to exercise our release discipline muscles. :)
>
> Perhaps this should be an example for future release windows.
(Forgive me for fat-fingering and accidentally using "gmx.net" instead
of "gmx.de" for Johannes' email address. Fixed in this message.)
-Stolee
^ permalink raw reply
* Re: [PATCH] unpack-trees: correctly compute result count
From: Derrick Stolee @ 2020-01-10 11:24 UTC (permalink / raw)
To: Jeff King, Derrick Stolee via GitGitGadget
Cc: git, johannes.schindelin, Derrick Stolee
In-Reply-To: <20200110103729.GA470836@coredump.intra.peff.net>
On 1/10/2020 5:37 AM, Jeff King wrote:
> On Fri, Jan 10, 2020 at 01:59:30AM +0000, Derrick Stolee via GitGitGadget wrote:
>>
>> As for making it into the release, I don't know. The change is small, it
>> has a very limited scope, but this flaw is also not really hurting
>> anything in a major way.
>
> I could go either way.
>
> This counts as something small and obvious enough that I'd consider
> slipping it in at the last minute if it were fixing a bad bug. But given
> how minor the bug is, being conservative makes sense to me, if only
> because it's good to exercise our release discipline muscles. :)
Perhaps this should be an example for future release windows.
Thanks,
-Stolee
^ permalink raw reply
* Re: Fwd: Add support for axiterm colors in parse_color
From: Jeff King @ 2020-01-10 11:15 UTC (permalink / raw)
To: Eyal Soha; +Cc: git
In-Reply-To: <CANsz78Lm3ggVZLrSxM5tc0MozFMdAmVBOix_3sjJT4+s3VHLPQ@mail.gmail.com>
On Thu, Jan 09, 2020 at 07:20:09PM -0500, Eyal Soha wrote:
> > That said, I'm not entirely opposed to having more human-readable
> > aliases. I'm not sure if it's worth using the 16-color version (e.g.,
> > "ESC[91m" versus the 256-color version "ESC[38;5;9m"). It's possible it
> > would be compatible with more terminals, and it is slightly fewer bytes.
>
> My motivation for this patch was to fix the github workflow log output
> that doesn't support 8bit colors properly. Only the "ANSI" colors
> 0-15 worked. None of the 8-bit colors worked except for 30-37, 40-47,
> 90-97, and 100-107, which matched the ANSI colors. That is a very
> broken color scheme! But that's how it displayed.
That makes sense. I'm not too surprised to see a terminal that supports
one but not the other.
But I wonder if there are ones that go the other way around: supporting
256-color mode but not ANSI 90-97, etc. I doubt it, but I think it would
be nice to split that change out into a separate commit in case we do
run into problems.
> Done. Here's a new patch!
Thanks. The content here is looking pretty good (though I have a few
comments below).
Can you also format it as described in Documentation/SubmittingPatches
and re-send? In particular, it needs a regular commit message and your
signoff.
> +enum {
> + COLOR_BACKGROUND_OFFSET = 10,
> + COLOR_FOREGROUND_ANSI = 30,
> + COLOR_FOREGROUND_RGB = 38,
> + COLOR_FOREGROUND_256 = 38,
> + COLOR_FOREGROUND_BRIGHT_ANSI = 90,
> +};
The split in this enum mostly makes sense to me. It changes the meaning
of "value" for COLOR_ANSI, but this is all local to color.c, so your
changes to output_color() are all that's needed.
It might be easier to follow the patch if switching to this enum came in
a separate preparatory patch.
> @@ -92,7 +100,13 @@ static int parse_color(struct color *out, const
> char *name, int len)
> for (i = 0; i < ARRAY_SIZE(color_names); i++) {
> if (match_word(name, len, color_names[i])) {
> out->type = COLOR_ANSI;
> - out->value = i;
> + out->value = i + COLOR_FOREGROUND_ANSI;
> + return 0;
> + }
> + if (*name == '+' &&
> + match_word(name+1, len-1, color_names[i])) {
> + out->type = COLOR_ANSI;
> + out->value = i + COLOR_FOREGROUND_BRIGHT_ANSI;
> return 0;
> }
It would be slightly simpler and more efficient handle the "+" outside
the loop, like:
int offset = COLOR_FOREGROUND_ANSI;
if (*name == '+') {
offset = COLOR_FOREGROUND_BRIGHT_ANSI;
name++;
len--;
}
and then in the loop just set "out->value = i + offset".
You'd probably want to hoist this out to a separate function since
"name" needs to be unchanged in the later part of the function.
I dunno. It's almost certainly an unmeasurable micro-optimization, but
somehow the flow of it seems simpler to me.
I also wondered if we'd want English aliases like "brightred" that some
other systems use. It would be easy to add that to the check I showed
above without having to repeat as much.
> @@ -109,10 +123,15 @@ static int parse_color(struct color *out, const
> char *name, int len)
> else if (val < 0) {
> out->type = COLOR_NORMAL;
> return 0;
> - /* Rewrite low numbers as more-portable standard colors. */
> + /* Rewrite 0-7 as more-portable standard colors. */
> } else if (val < 8) {
> out->type = COLOR_ANSI;
> - out->value = val;
> + out->value = val + COLOR_FOREGROUND_ANSI;
> + return 0;
> + /* Rewrite 8-15 as more-portable aixterm colors. */
> + } else if (val < 16) {
> + out->type = COLOR_ANSI;
> + out->value = val - 8 + COLOR_FOREGROUND_BRIGHT_ANSI;
And I think this 8-15 handling might want to be a separate commit on
top, just because it's possible it might regress some cases (though
again, I do doubt it).
> case COLOR_256:
> - out += xsnprintf(out, len, "%c8;5;%d", type, c->value);
> + out += xsnprintf(out, len, "%d;5;%d", COLOR_FOREGROUND_256 + offset,
> + c->value);
Looks like some unwanted tab/space conversion (here and elsewhere).
> +test_expect_success 'axiterm bright fg color' '
> + color "+red" "[91m"
s/axi/aix/ (here and below).
> +test_expect_success '8-15 are aliases for aixterm color names' '
> + color "12 13" "[94;105m"
Makes sense.
-Peff
^ permalink raw reply
* Re: [PATCH] unpack-trees: correctly compute result count
From: Jeff King @ 2020-01-10 10:37 UTC (permalink / raw)
To: Derrick Stolee via GitGitGadget; +Cc: git, johannes.schindelin, Derrick Stolee
In-Reply-To: <pull.520.git.1578621570180.gitgitgadget@gmail.com>
On Fri, Jan 10, 2020 at 01:59:30AM +0000, Derrick Stolee via GitGitGadget wrote:
> Here is a very small fix to the cone-mode pattern-matching in
> unpack-trees.c. Johannes found this while running a Coverity scan for
> other issues. He alerted me to the problem and I could immediately see
> my error here. In creating this patch, most of my time was spent asking
> "how did this work before?" and "why didn't this hurt performance?"
> Hopefully my commit message explains this thoroughly enough.
Yes, it makes perfect sense (and as soon as I saw the explanation of the
problem, my immediate response was also "wait, how did this even work").
And the patch itself looks good.
> As for making it into the release, I don't know. The change is small, it
> has a very limited scope, but this flaw is also not really hurting
> anything in a major way.
I could go either way.
This counts as something small and obvious enough that I'd consider
slipping it in at the last minute if it were fixing a bad bug. But given
how minor the bug is, being conservative makes sense to me, if only
because it's good to exercise our release discipline muscles. :)
-Peff
^ permalink raw reply
* Re: Question about the pack OBJ_OFS_DELTA format
From: Jeff King @ 2020-01-10 9:57 UTC (permalink / raw)
To: Erik Fastermann; +Cc: git
In-Reply-To: <1032627506.120165.1578644787174@email.ionos.de>
On Fri, Jan 10, 2020 at 09:26:27AM +0100, Erik Fastermann wrote:
> I get: ee 01 8c 63
>
> The first two bytes, the type and the size are correctly computed.
>
> So the next varint should be the offset.
>
> 8c: 10001100 --- 63: 01100011
>
> -> 1100011_0001100
>
> -> 12684 ???
>
> The result is the same when calculating it manually and with my program.
The pack-format.txt file says:
offset encoding:
n bytes with MSB set in all but the last one.
The offset is then the number constructed by
concatenating the lower 7 bit of each byte, and
for n >= 2 adding 2^7 + 2^14 + ... + 2^(7*(n-1))
to the result.
but I think is missing two bits of information:
- the bytes are in most-significant to least-significant order, which
IIRC is the opposite of the size varint
- each 7-bit byte sneaks in some extra data by implicitly adding "1"
to all but the last byte
So the low seven bits of "8c" is "12". Add one and multiply by 2^7 gets
you 1664. The low seven of "63" is 99. No addition or multiply because
it's the last byte.
The result is 1763, which is what you expected.
It does seem like the documentation could be a lot better. I had to dig
into the source (packfile.c:get_delta_base is pretty clear, but if
you're trying to do a non-GPL clean-room implementation, then obviously
don't look at it).
-Peff
^ permalink raw reply
* Re: git submodule update strange output behavior.
From: Carlo Wood @ 2020-01-10 9:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq8smgz9as.fsf@gitster-ct.c.googlers.com>
It seems to me that the other part of the problem is printing
this output for submodules when nothing (needed to be) is fetched.
I haven't tested if output for the top-level is printed (without
--quiet) when also there fetching is needed; is that even possible?
On Thu, 09 Jan 2020 12:03:55 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Carlo Wood <carlo@alinoe.com> writes:
> >
> >> In a project containing submodules, one of the submodules
> >> contains a submodule itself, which in turn also contains
> >> a submodule.
> >>
> >> Overview:
> >>
> >> project/foobar [submodule]
> >> project/cwm4 [submodule]
> >> project/evio [submodule]
> >> project/evio/protocol/matrixssl [submodule]
> >> project/evio/protocol/matrixssl/cwm4 [submodule]
> >>
> >> ('protocol' is a normal subdirectory)
> >>
> >> Running (with or without the --quiet),
> >>
> >> $ git submodule --quiet update --init --recursive --remote
> >> Fetching submodule protocol/matrixssl
> >> Fetching submodule protocol/matrixssl/cwm4
> >> Fetching submodule cwm4
> >>
> >> This is odd (a bug imho) because
> >>
> >> 1) it seems to only print this fetching information for submodules
> >> inside submodules, not for the top-level submodules.
> >> 2) it even prints this when using --quiet
> >> 3) it prints this every time (also when there is nothing more to
> >> fetch).
> >
> >
> > Sounds like a symptom of (a) the top-level "git submodule update"
> > knowing how to react to "--quiet" but (b) it forgets to pass down
> > the "--quiet" when it recursively runs "git submodule update" in its
> > submodules?
>
> Just a shot in the dark. Not even compile tested ;-)
>
> submodule.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/submodule.c b/submodule.c
> index 9da7181321..535bb6bf04 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1454,11 +1454,12 @@ static int get_next_submodule(struct
> child_process *cp, argv_array_pushv(&cp->args, spf->args.argv);
> argv_array_push(&cp->args, default_argv);
> argv_array_push(&cp->args,
> "--submodule-prefix"); -
> strbuf_addf(&submodule_prefix, "%s%s/",
> spf->prefix,
> task->sub->path);
> argv_array_push(&cp->args,
> submodule_prefix.buf);
> + if (spf->quiet)
> + argv_array_push(&cp->args,
> "--quiet");
> spf->count++;
> *task_cb = task;
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply
* Re: git submodule update strange output behavior.
From: Carlo Wood @ 2020-01-10 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqtv54zcik.fsf@gitster-ct.c.googlers.com>
That seems only part of the problem, but yes.
It is only part of the problem because without --quiet
I get the same output; that is - the top-level is still
quiet, but the submodules aren't. That is out of balance
imho.
On Thu, 09 Jan 2020 10:54:27 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> Carlo Wood <carlo@alinoe.com> writes:
>
> > In a project containing submodules, one of the submodules
> > contains a submodule itself, which in turn also contains
> > a submodule.
> >
> > Overview:
> >
> > project/foobar [submodule]
> > project/cwm4 [submodule]
> > project/evio [submodule]
> > project/evio/protocol/matrixssl [submodule]
> > project/evio/protocol/matrixssl/cwm4 [submodule]
> >
> > ('protocol' is a normal subdirectory)
> >
> > Running (with or without the --quiet),
> >
> > $ git submodule --quiet update --init --recursive --remote
> > Fetching submodule protocol/matrixssl
> > Fetching submodule protocol/matrixssl/cwm4
> > Fetching submodule cwm4
> >
> > This is odd (a bug imho) because
> >
> > 1) it seems to only print this fetching information for submodules
> > inside submodules, not for the top-level submodules.
> > 2) it even prints this when using --quiet
> > 3) it prints this every time (also when there is nothing more to
> > fetch).
>
>
> Sounds like a symptom of (a) the top-level "git submodule update"
> knowing how to react to "--quiet" but (b) it forgets to pass down
> the "--quiet" when it recursively runs "git submodule update" in its
> submodules?
>
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply
* Question about the pack OBJ_OFS_DELTA format
From: Erik Fastermann @ 2020-01-10 8:26 UTC (permalink / raw)
To: git
Hi all,
I'm trying to implement the Git pack format. Parsing the index file and
unpacking undeltified objects already works. However I'm unable to get
the offset, if the type is OBJ_OFS_DELTA.
The very much work-in-progress Go code and data can be found here:
https://github.com/erikfastermann/notes/tree/wip/git
From the docs (https://git-scm.com/docs/pack-format) I assume, that
the offset is a variable length integer, like the size. However my
caclulation leads to a illogical result.
When trying the hash 8c40ff4767d973b672fe5aa431cb8ba0593dd26a with:
git verify-pack -v pack.pack
I get: offset: 138650 size: 30.
The base object 9b25d441c1bf358af01edc4eeba65870581a5ac1 (shown by
verify-pack) has the offset 136887, which I think means the delta should
be: 138650 - 136887 = 1763.
Using the command:
dd skip=138650 count=4 if=pack.pack bs=1 status=none | hexdump -C
I get: ee 01 8c 63
The first two bytes, the type and the size are correctly computed.
So the next varint should be the offset.
8c: 10001100 --- 63: 01100011
-> 1100011_0001100
-> 12684 ???
The result is the same when calculating it manually and with my program.
I probably have some crucial misunderstanding about the format, so a
clarification would be nice.
Thank you for your help.
Erik
^ permalink raw reply
* [PATCH] RFC: allow branch --edit-description during rebase
From: marcandre.lureau @ 2020-01-10 7:19 UTC (permalink / raw)
To: git; +Cc: Marc-André Lureau
From: Marc-André Lureau <marcandre.lureau@redhat.com>
This patch aims to allow editing of branch description during a rebase.
A common use case of rebasing is to iterate over a series of patches
after receiving reviews. During the rebase, various patches will be
modified, and it is often requested to put a summary of the changes for
the next version in the cover letter ("v2: - fixed this, - changed
that.."). This helps the reviewer to focus on the difference with the
previous version. Unfortunately, git branch --edit-description doesn't
allow yet to modify the content during a rebase, and forces the author
to use memory muscles to update the description after finishing the
rebase.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
builtin/branch.c | 19 ++++++++++++++++---
worktree.c | 19 +++++++++++++++++++
worktree.h | 7 +++++++
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index d8297f80ff..f7122d31d6 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -613,6 +613,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int icase = 0;
static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting;
struct ref_format format = REF_FORMAT_INIT;
+ struct wt_status_state state;
struct option options[] = {
OPT_GROUP(N_("Generic options")),
@@ -664,6 +665,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
setup_ref_filter_porcelain_msg();
+ memset(&state, 0, sizeof(state));
+
memset(&filter, 0, sizeof(filter));
filter.kind = FILTER_REFS_BRANCHES;
filter.abbrev = -1;
@@ -745,13 +748,21 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
string_list_clear(&output, 0);
return 0;
} else if (edit_description) {
- const char *branch_name;
+ const char *branch_name = NULL;
struct strbuf branch_ref = STRBUF_INIT;
if (!argc) {
- if (filter.detached)
+ if (filter.detached) {
+ const struct worktree *wt = worktree_get_current();
+
+ if (wt_status_check_rebase(wt, &state)) {
+ branch_name = state.branch;
+ }
+
+ if (!branch_name)
die(_("Cannot give description to detached HEAD"));
- branch_name = head;
+ } else
+ branch_name = head;
} else if (argc == 1)
branch_name = argv[0];
else
@@ -851,5 +862,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
} else
usage_with_options(builtin_branch_usage, options);
+ free(state.branch);
+ free(state.onto);
return 0;
}
diff --git a/worktree.c b/worktree.c
index 5b4793caa3..0318c6f6a6 100644
--- a/worktree.c
+++ b/worktree.c
@@ -396,6 +396,25 @@ int is_worktree_being_bisected(const struct worktree *wt,
return found_rebase;
}
+const struct worktree *worktree_get_current(void)
+{
+ static struct worktree **worktrees;
+ int i = 0;
+
+ if (worktrees)
+ free_worktrees(worktrees);
+ worktrees = get_worktrees(0);
+
+ for (i = 0; worktrees[i]; i++) {
+ struct worktree *wt = worktrees[i];
+
+ if (wt->is_current)
+ return wt;
+ }
+
+ return NULL;
+}
+
/*
* note: this function should be able to detect shared symref even if
* HEAD is temporarily detached (e.g. in the middle of rebase or
diff --git a/worktree.h b/worktree.h
index caecc7a281..4fe2b78d24 100644
--- a/worktree.h
+++ b/worktree.h
@@ -91,6 +91,13 @@ void free_worktrees(struct worktree **);
const struct worktree *find_shared_symref(const char *symref,
const char *target);
+
+/*
+ * Return the current worktree. The result may be destroyed by the
+ * next call.
+ */
+const struct worktree *worktree_get_current(void);
+
/*
* Similar to head_ref() for all HEADs _except_ one from the current
* worktree, which is covered by head_ref().
base-commit: 042ed3e048af08014487d19196984347e3be7d1c
prerequisite-patch-id: 9b3cf75545ec4a1e702c8c2b2aae8edf241b87f2
--
2.25.0.rc1.20.g2443f3f80d.dirty
^ permalink raw reply related
* Re: [RFC PATCH] unpack-trees: watch for out-of-range index position
From: Jeff King @ 2020-01-10 6:37 UTC (permalink / raw)
To: Emily Shaffer; +Cc: Junio C Hamano, git
In-Reply-To: <20200109224641.GF181522@google.com>
On Thu, Jan 09, 2020 at 02:46:41PM -0800, Emily Shaffer wrote:
> > Perhaps. The integrity check only protects against an index that was
> > modified after the fact, not one that was generated by a buggy Git. I'm
> > not sure we know how the index that led to this patch got into this
> > state (though it sounds like Emily has a copy and could check the hash
> > on it), but other cache-tree segfault I found recently was with an index
> > with an intact integrity hash.
>
> Yeah, I can do that, although I'm not sure how. The index itself is very
> small - it only contains one file and one tree extension - so I'll go
> ahead and paste some poking and prodding, and if it's not what you
> wanted then please let me know what else to run.
I was thinking you would run something like:
size=$(stat --format=%s "$file")
actual=$(head -c $(($size-20)) "$file" | sha1sum | awk '{print $1}')
expect=$(xxd -s -20 -g 20 -c 20 "$file" | awk '{print $2}')
if test "$actual" = "$expect"; then
echo "OK ($actual)"
else
echo "FAIL ($actual != $expect)"
fi
to manually check the sha1. But...
> $ g fsck --cache
> Checking object directories: 100% (256/256), done.
> Checking objects: 100% (20/20), done.
> broken link from commit 153a9a100eae7fdba5989ce39a5dd1782075517f
> to commit cca7ecaa5d8c398f41bfec7938cc6a526803579b
> broken link from commit 7d6bb91e31d18eadfaf855a9fb7ad6ba81b8b6d9
> to commit 03087a617bfe55f862cb1ef43273a2bd08e8b6d6
> missing commit 03087a617bfe55f862cb1ef43273a2bd08e8b6d6
> missing commit cca7ecaa5d8c398f41bfec7938cc6a526803579b
> dangling commit 5e2c635433bc46b13061b276e481f63b1f6642c8
...fsck would have reported a problem there, since we explicitly kept
the check there in a33fc72fe9 (read-cache: force_verify_index_checksum,
2017-04-14).
And just to be double-sure, I used this:
> $ hexdump -C .git/index
> 00000000 44 49 52 43 00 00 00 02 00 00 00 01 5d 89 5e 22 |DIRC........].^"|
> 00000010 23 bf a3 c4 5d 89 5e 22 23 bf a3 c4 00 00 fe 02 |#...].^"#.......|
> 00000020 02 c8 f5 83 00 00 81 a4 00 06 c1 dc 00 01 5f 53 |.............._S|
> 00000030 00 00 06 b3 78 88 a4 f4 22 34 7d ad b0 c4 73 0f |....x..."4}...s.|
> 00000040 c5 bc f6 ea 1d 2d f0 3a 00 09 52 45 41 44 4d 45 |.....-.:..README|
> 00000050 2e 6d 64 00 54 52 45 45 00 00 00 3a 00 31 37 20 |.md.TREE...:.17 |
> 00000060 31 0a da 7f 67 25 40 7d 4e ce 9f d3 72 ce 4c e8 |1...g%@}N...r.L.|
> 00000070 40 6d 5d ad e9 79 67 69 74 6c 69 6e 74 00 34 20 |@m]..ygitlint.4 |
> 00000080 30 0a 93 63 25 17 69 e6 d6 92 78 97 55 4b 0f 8b |0..c%.i...x.UK..|
> 00000090 ff a0 e8 2d 6d 71 32 d1 69 fc f2 38 42 f8 5a 6e |...-mq2.i..8B.Zn|
> 000000a0 05 35 d6 94 41 c0 9f c7 ba 43 |.5..A....C|
> 000000aa
to reconstruct the file and check its sha1, and indeed it is fine.
So this bogus index was probably actually created by Git, not an
after-the-fact byte corruption.
-Peff
^ permalink raw reply
* How to use git to add the modification of each commit to the existing folder in a patch way, because the project is large, using clone or pull is very time-consuming and network dependent?
From: 陈望舒 @ 2020-01-10 6:29 UTC (permalink / raw)
To: git
Thank you for your attention.
How to use git to add the modification of each commit to the existing folder
in a patch way, because the project is large, using clone or pull is very
time-consuming and network dependent?
Now,there is a linux kernel in my pc, and a branch of linux kernel in
github, I want to synchronize changes from remote repositories to my local
linux kernel.
And the local linux kernel is downloaded in zip format not in git mode. So,
Is there exists some method to do that.
^ permalink raw reply
* [PATCH] userdiff: add Julia to supported userdiff languages
From: Ryan Zoeller via GitGitGadget @ 2020-01-10 3:10 UTC (permalink / raw)
To: git; +Cc: Ryan Zoeller
Add xfuncname and word_regex patterns for Julia[1],
which is a language used in numerical analysis and
computational science.
The default behavior for xfuncname did not allow
functions to be indented, nor functions to have a
macro applied, such as @inline or @generated.
[1]: https://julialang.org
Signed-off-by: Ryan Zoeller <rtzoeller@rtzoeller.com>
---
userdiff: add Julia to supported userdiff languages
Add xfuncname and word_regex patterns for Julia1 [https://julialang.org]
, which is a language used in numerical analysis and computational
science.
The default behavior for xfuncname did not allow functions to be
indented, nor functions to have a macro applied, such as @inline or
@generated.
Signed-off-by: Ryan Zoeller rtzoeller@rtzoeller.com
[rtzoeller@rtzoeller.com]
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-521%2Frtzoeller%2Fjulia_userdiff-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-521/rtzoeller/julia_userdiff-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/521
Documentation/gitattributes.txt | 2 ++
t/t4018-diff-funcname.sh | 1 +
t/t4018/julia-function | 5 +++++
t/t4018/julia-indented-function | 8 ++++++++
t/t4018/julia-inline-function | 5 +++++
t/t4018/julia-macro | 5 +++++
t/t4018/julia-mutable-struct | 5 +++++
t/t4018/julia-struct | 5 +++++
userdiff.c | 15 +++++++++++++++
9 files changed, 51 insertions(+)
create mode 100644 t/t4018/julia-function
create mode 100644 t/t4018/julia-indented-function
create mode 100644 t/t4018/julia-inline-function
create mode 100644 t/t4018/julia-macro
create mode 100644 t/t4018/julia-mutable-struct
create mode 100644 t/t4018/julia-struct
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 508fe713c4..d39dc727e3 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -824,6 +824,8 @@ patterns are available:
- `java` suitable for source code in the Java language.
+- `julia` suitable for source code in the Julia language.
+
- `matlab` suitable for source code in the MATLAB and Octave languages.
- `objc` suitable for source code in the Objective-C language.
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index c0f4839543..d4613eb7d2 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -38,6 +38,7 @@ diffpatterns="
golang
html
java
+ julia
matlab
objc
pascal
diff --git a/t/t4018/julia-function b/t/t4018/julia-function
new file mode 100644
index 0000000000..a2eab83c27
--- /dev/null
+++ b/t/t4018/julia-function
@@ -0,0 +1,5 @@
+function RIGHT()
+ # A comment
+ # Another comment
+ return ChangeMe
+end
diff --git a/t/t4018/julia-indented-function b/t/t4018/julia-indented-function
new file mode 100644
index 0000000000..2d48aabcdb
--- /dev/null
+++ b/t/t4018/julia-indented-function
@@ -0,0 +1,8 @@
+function outer_function()
+ function RIGHT()
+ for i = 1:10
+ print(i)
+ end
+ # ChangeMe
+ end
+end
diff --git a/t/t4018/julia-inline-function b/t/t4018/julia-inline-function
new file mode 100644
index 0000000000..5806f224fb
--- /dev/null
+++ b/t/t4018/julia-inline-function
@@ -0,0 +1,5 @@
+@inline function RIGHT()
+ # Prints Hello, then something else.
+ println("Hello")
+ println("ChangeMe")
+end
diff --git a/t/t4018/julia-macro b/t/t4018/julia-macro
new file mode 100644
index 0000000000..1d18bc2750
--- /dev/null
+++ b/t/t4018/julia-macro
@@ -0,0 +1,5 @@
+macro RIGHT()
+ # First comment
+ # Second comment
+ return :( println("ChangeMe") )
+end
diff --git a/t/t4018/julia-mutable-struct b/t/t4018/julia-mutable-struct
new file mode 100644
index 0000000000..db82017ba0
--- /dev/null
+++ b/t/t4018/julia-mutable-struct
@@ -0,0 +1,5 @@
+mutable struct RIGHT
+ x
+ y::Int
+ ChangeMe
+end
diff --git a/t/t4018/julia-struct b/t/t4018/julia-struct
new file mode 100644
index 0000000000..d3d2bda8cb
--- /dev/null
+++ b/t/t4018/julia-struct
@@ -0,0 +1,5 @@
+struct RIGHT
+ x
+ y::Int
+ ChangeMe
+end
diff --git a/userdiff.c b/userdiff.c
index efbe05e5a5..b5e938b1c2 100644
--- a/userdiff.c
+++ b/userdiff.c
@@ -79,6 +79,21 @@ PATTERNS("java",
"|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lL]?"
"|[-+*/<>%&^|=!]="
"|--|\\+\\+|<<=?|>>>?=?|&&|\\|\\|"),
+PATTERNS("julia",
+ "^[ \t]*(((mutable[ \t]+)?struct|(@.+[ \t])?function|macro)[ \t].*)$",
+ /* -- */
+ /* Binary literals */
+ "[-+]?0b[01]+"
+ /* Hexadecimal literals */
+ "|[-+]?0x[0-9a-fA-F]+"
+ /* Real and complex literals */
+ "|[-+0-9.e_(im)]+"
+ /* Should theoretically allow Unicode characters as part of
+ * a word, such as U+2211. However, Julia reserves most of the
+ * U+2200-U+22FF range (as well as others) as user-defined operators,
+ * therefore they are not handled in this regex. */
+ "|[a-zA-Z_][a-zA-Z0-9_!]*"
+ "|--|\\+\\+|<<=?|>>>=?|>>=?|\\\\\\\\=?|//=?|&&|\\|\\||::|->|[-+*/<>%^&|=!$]=?"),
PATTERNS("matlab",
/*
* Octave pattern is mostly the same as matlab, except that '%%%' and
base-commit: 042ed3e048af08014487d19196984347e3be7d1c
--
gitgitgadget
^ permalink raw reply related
* Re: Unreliable 'git rebase --onto'
From: Elijah Newren @ 2020-01-10 2:35 UTC (permalink / raw)
To: Eugeniu Rosca
Cc: Eugeniu Rosca, SZEDER Gábor, Junio C Hamano, Jeff King,
Ævar Arnfjörð, Git Mailing List
In-Reply-To: <20200110000603.GA19040@erosca>
Hi Eugeniu,
On Thu, Jan 9, 2020 at 4:06 PM Eugeniu Rosca <roscaeugeniu@gmail.com> wrote:
>
> Hi Elijah,
>
> On Thu, Jan 09, 2020 at 10:05:52AM -0800, Elijah Newren wrote:
> > On Thu, Jan 9, 2020 at 2:53 AM Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
> > > Some years ago I was hit by 'git merge' producing slightly different
> > > results compared to 'git rebase --onto' and 'git cherry-pick A..B'
> > > (maybe I can come up with a reproduction scenario for that too).
> >
> > If you can, I'd be interested to see it and take a look. I'd normally
> > assume it was just some case where A..B included "evil" merge commits
> > (merge commits that made additional changes not part of the actual
> > merging) since rebasing or cherry-picking such a range would exclude
> > the merge commits and thus drop those changes -- but you identified a
> > real bug with the default rebase backend so I'm interested to see if
> > you happen to have more bugs I should know about.
>
> Here is a _simplified_ scenario to get a totally unexpected result from
> 'git merge' (initially reproduced years ago, but still happening on
> 2.25.0.rc2):
>
> ## Preparation
> 0. git --version
> git version 2.25.0.rc2
> 1. git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 2. git remote add linux-stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> 3. git fetch linux-stable
>
> # Reproduction
> 4. git checkout f7a8e38f07a1
> 5. git merge --no-edit e18da11fc0f959
> ## Merge v4.4.3 commit
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e18da11fc0f959
> which is a linux-stable backport of vanilla v4.5-rc1 commit
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7a8e38f07a1
> the latter being checked out at step 4.
>
> 6. git show HEAD
> ## Inspect the _automatic_ conflict resolution performed by git in
> drivers/mtd/nand/nand_base.c. Git decided to integrate e18da11fc0f959
> alongside f7a8e38f07a1, while essentially they are the same commit.
> We end up with two times commit f7a8e38f07a1.
>
> What do you think about that?
Ooh, interesting case; thanks for sending it along. I think this is
the same as https://lore.kernel.org/git/20190816184051.GB13894@sigill.intra.peff.net/
, which struck git itself not that long back. It didn't do any actual
harm, though, it was just surprising. I'm not familiar with the xdiff
part of the codebase, so I don't know if this is a heuristic thing, or
something more along the lines of the diff3 issues mentioned at
https://www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf. I read up
on this area a little bit a few months ago and I'd like to dig more at
the diff3 stuff in general, but it may be a little while. If you see
more issues like this, though, I'm definitely interested in saving and
cataloging them for when I get back to this.
Elijah
^ permalink raw reply
* Re: [PATCH v4 05/15] bugreport: add uname info
From: Aaron Schrab @ 2020-01-10 2:05 UTC (permalink / raw)
To: Emily Shaffer; +Cc: git
In-Reply-To: <20191213004312.169753-6-emilyshaffer@google.com>
At 16:43 -0800 12 Dec 2019, Emily Shaffer <emilyshaffer@google.com> wrote:
>The contents of uname() can give us some insight into what sort of
>system the user is running on, and help us replicate their setup if need
>be. The domainname field is not guaranteed to be available, so don't
>collect it.
The manpage on Linux says that it's a GNU extension; on Mac OS it isn't
mentioned. So it would be more accurate to say that it's known not to be
available on many systems rather than just not being guaranteed.
Besides that I think in some cases it may be considered sensitive
information, so another reason to not include it. Perhaps even worthy of
being mentioned as the primary reason.
>+ uname_info.nodename,
I think in some cases this could also be considered as sensitive
information, and is unlikely to help in diagnosing problems. So I'd
move to exclude this as well.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox