* Re: Fix git-send-email.perl w.r.t. recent Getopt::Long update
From: Junio C Hamano @ 2023-11-27 0:58 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20231124103932.31ca7688@pc09>
"H.Merijn Brand" <linux@tux.freedom.nl> writes:
> From the Getopt::Long changes:
> ```
> Changes in version 2.55
> -----------------------
> * Fix long standing bug that duplicate options were not detected when
> the options differ in case while ignore_case is in effect.
> This will now yield a warning and become a fatal error in a future
> release.
> ```
>
> Current version is 2.57
This patch looks like duplicate of
https://lore.kernel.org/git/20231116193014.470420-1-tmz@pobox.com/
perhaps independently discovered and worked on. Thanks for caring.
One downside of unconditional upgrade of the call is, of course,
that it would no longer work for those with older Getopt::Long that
did not support the "!" suffix. Fortunately, Getopt::Long 2.33
started shipping with Perl 5.8.1 that is more than 20 years old, so
with the series we accepted, we also have a change to bump the
required version of Perl from 5.8.0 to 5.8.1 to make it clear that
it is deliberate that we drop the support for anything older at the
same time.
^ permalink raw reply
* Re: [PATCH v3 0/4] Switch links to https
From: Junio C Hamano @ 2023-11-27 0:49 UTC (permalink / raw)
To: Josh Soref; +Cc: Elijah Newren, Josh Soref via GitGitGadget, git, Eric Sunshine
In-Reply-To: <CACZqfqAq0ijtYO9-1q6h2KQMyxHgLpFOg--d4c9F4xT0nMkvUg@mail.gmail.com>
Josh Soref <jsoref@gmail.com> writes:
> Elijah Newren wrote:
>> As stated elsewhere, I'd be fine with using the archived link if the
>> justification presented in the series for using archived links was
>> consistent and mentioned both reasons for changes. But, I think this
>> series is fine to merge down as-is if you don't want to go through the
>> trouble. Especially given how long you've waited.
>
> I'm clearly still contributing, so I can come back later and cross
> that bridge...
>
>> Anyway, I checked through every link in this series; it all looks good to me.
>
> Let's take this as-is. Thanks for taking the time to re-check every
> link, I know exactly how tedious that is :).
Thanks, both. Will queue.
^ permalink raw reply
* Re: [PATCH] i18n: factorize even more 'incompatible options' messages
From: Eric Sunshine @ 2023-11-26 17:49 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Jean-Noël Avila
In-Reply-To: <e6eb12e4-bb63-473c-9c2f-965a4d5981ad@web.de>
On Sun, Nov 26, 2023 at 6:57 AM René Scharfe <l.s.r@web.de> wrote:
> Continue the work of 12909b6b8a (i18n: turn "options are incompatible"
> into "cannot be used together", 2022-01-05) and a699367bb8 (i18n:
> factorize more 'incompatible options' messages, 2022-01-31) to use the
> same parameterized error message for reporting incompatible command line
> options. This reduces the number of strings to translate and makes the
> UI slightly more consistent.
Thanks for tackling this.
A couple additional instances recently slipped into `show-ref.c` which
were caught during review[1,2] but nevertheless made it to
"master"[3,4]. This patch, of course, doesn't need to address those,
but if rerolling for some other reason, perhaps they can be included,
as well(?).
[1]: https://lore.kernel.org/git/CAPig+cSrp7vZuy7D_ENHKZKZzF4OSmCtfYNHPGMtS1Hj6gArDw@mail.gmail.com/
[2]: https://lore.kernel.org/git/CAPig+cRTOMie0rUf=Mhbo9e2EXf-_2kQyMeqpB9OCRB1MZZ1rw@mail.gmail.com/
[3]: 199970e72f (builtin/show-ref: ensure mutual exclusiveness of
subcommands, 2023-10-31)
[4]: 9080a7f178 (builtin/show-ref: add new mode to check for reference
existence, 2023-10-31)
^ permalink raw reply
* No automatic continue of rebasing with rerere
From: Vovodroid @ 2023-11-26 12:08 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <511253473.8084883.1701000481697.ref@mail.yahoo.com>
Hi,
when running non-interactive rebasing (i.e. no -i option) with rerere turned on, already resolved conflicts and recorded conflicts causing Git to return exit code 1, as if error occurred.
Also "git.exe rebase --continue" still opens log editor unless GIT_EDITOR environment variable is set to true.
Such behavior causes to user to perform a lot of unnecessary Git runs, or clicking if some GUI shell, like in GitExtension, is used.
See https://github.com/gitextensions/gitextensions/issues/11382 for discussion and screenshots.
Regards.
^ permalink raw reply
* [PATCH] i18n: factorize even more 'incompatible options' messages
From: René Scharfe @ 2023-11-26 11:57 UTC (permalink / raw)
To: Git List; +Cc: Jean-Noël Avila
Continue the work of 12909b6b8a (i18n: turn "options are incompatible"
into "cannot be used together", 2022-01-05) and a699367bb8 (i18n:
factorize more 'incompatible options' messages, 2022-01-31) to use the
same parameterized error message for reporting incompatible command line
options. This reduces the number of strings to translate and makes the
UI slightly more consistent.
Signed-off-by: René Scharfe <l.s.r@web.de>
---
builtin/clone.c | 4 +++-
builtin/merge-tree.c | 3 ++-
parse-options.c | 3 ++-
revision.c | 4 ++--
t/t0040-parse-options.sh | 8 ++++----
t/t1006-cat-file.sh | 2 +-
t/t4301-merge-tree-write-tree.sh | 2 +-
t/t5606-clone-options.sh | 2 +-
8 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index c6357af949..45a5070268 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -965,7 +965,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
}
if (bundle_uri && deepen)
- die(_("--bundle-uri is incompatible with --depth, --shallow-since, and --shallow-exclude"));
+ die(_("options '%s' and '%s' cannot be used together"),
+ "--bundle-uri",
+ "--depth/--shallow-since/--shallow-exclude");
repo_name = argv[0];
diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
index a35e0452d6..a4aa6013c5 100644
--- a/builtin/merge-tree.c
+++ b/builtin/merge-tree.c
@@ -577,7 +577,8 @@ int cmd_merge_tree(int argc, const char **argv, const char *prefix)
if (o.mode == MODE_TRIVIAL)
die(_("--trivial-merge is incompatible with all other options"));
if (merge_base)
- die(_("--merge-base is incompatible with --stdin"));
+ die(_("options '%s' and '%s' cannot be used together"),
+ "--merge-base", "--stdin");
line_termination = '\0';
while (strbuf_getline_lf(&buf, stdin) != EOF) {
struct strbuf **split;
diff --git a/parse-options.c b/parse-options.c
index e0c94b0546..c3955847f4 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -279,7 +279,8 @@ static enum parse_opt_result get_value(struct parse_opt_ctx_t *p,
opt_name = optnamearg(opt, arg, flags);
other_opt_name = optnamearg(elem->opt, elem->arg, elem->flags);
- error(_("%s is incompatible with %s"), opt_name, other_opt_name);
+ error(_("options '%s' and '%s' cannot be used together"),
+ opt_name, other_opt_name);
free(opt_name);
free(other_opt_name);
return -1;
diff --git a/revision.c b/revision.c
index 00d5c29bfc..b2861474b1 100644
--- a/revision.c
+++ b/revision.c
@@ -2384,8 +2384,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->left_right = 1;
} else if (!strcmp(arg, "--left-only")) {
if (revs->right_only)
- die("--left-only is incompatible with --right-only"
- " or --cherry");
+ die(_("options '%s' and '%s' cannot be used together"),
+ "--left-only", "--right-only/--cherry");
revs->left_only = 1;
} else if (!strcmp(arg, "--right-only")) {
if (revs->left_only)
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 8fdef88b65..ec974867e4 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -376,7 +376,7 @@ test_expect_success 'OPT_CMDMODE() detects incompatibility (1)' '
test_must_be_empty output &&
test_grep "mode1" output.err &&
test_grep "mode2" output.err &&
- test_grep "is incompatible with" output.err
+ test_grep "cannot be used together" output.err
'
test_expect_success 'OPT_CMDMODE() detects incompatibility (2)' '
@@ -384,7 +384,7 @@ test_expect_success 'OPT_CMDMODE() detects incompatibility (2)' '
test_must_be_empty output &&
test_grep "mode2" output.err &&
test_grep "set23" output.err &&
- test_grep "is incompatible with" output.err
+ test_grep "cannot be used together" output.err
'
test_expect_success 'OPT_CMDMODE() detects incompatibility (3)' '
@@ -392,7 +392,7 @@ test_expect_success 'OPT_CMDMODE() detects incompatibility (3)' '
test_must_be_empty output &&
test_grep "mode2" output.err &&
test_grep "set23" output.err &&
- test_grep "is incompatible with" output.err
+ test_grep "cannot be used together" output.err
'
test_expect_success 'OPT_CMDMODE() detects incompatibility (4)' '
@@ -401,7 +401,7 @@ test_expect_success 'OPT_CMDMODE() detects incompatibility (4)' '
test_must_be_empty output &&
test_grep "mode2" output.err &&
test_grep "mode34.3" output.err &&
- test_grep "is incompatible with" output.err
+ test_grep "cannot be used together" output.err
'
test_expect_success 'OPT_COUNTUP() with PARSE_OPT_NODASH works' '
diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index d73a0be1b9..271c5e4fd3 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -6,7 +6,7 @@ test_description='git cat-file'
test_cmdmode_usage () {
test_expect_code 129 "$@" 2>err &&
- grep "^error:.*is incompatible with" err
+ grep "^error: .* cannot be used together" err
}
for switches in \
diff --git a/t/t4301-merge-tree-write-tree.sh b/t/t4301-merge-tree-write-tree.sh
index b2c8a43fce..12ac436873 100755
--- a/t/t4301-merge-tree-write-tree.sh
+++ b/t/t4301-merge-tree-write-tree.sh
@@ -887,7 +887,7 @@ test_expect_success '--stdin with both a successful and a conflicted merge' '
test_expect_success '--merge-base is incompatible with --stdin' '
test_must_fail git merge-tree --merge-base=side1 --stdin 2>expect &&
- grep "^fatal: --merge-base is incompatible with --stdin" expect
+ grep "^fatal: .*merge-base.*stdin.* cannot be used together" expect
'
# specify merge-base as parent of branch2
diff --git a/t/t5606-clone-options.sh b/t/t5606-clone-options.sh
index fc4bbd9daf..a400bcca62 100755
--- a/t/t5606-clone-options.sh
+++ b/t/t5606-clone-options.sh
@@ -64,7 +64,7 @@ test_expect_success 'disallows --bundle-uri with shallow options' '
for option in --depth=1 --shallow-since=01-01-2000 --shallow-exclude=HEAD
do
test_must_fail git clone --bundle-uri=bundle $option from to 2>err &&
- grep "bundle-uri is incompatible" err || return 1
+ grep "bundle-uri.* cannot be used together" err || return 1
done
'
--
2.43.0
^ permalink raw reply related
* [PATCH] column: release strbuf and string_list after use
From: René Scharfe @ 2023-11-26 11:57 UTC (permalink / raw)
To: Git List
Releasing strbuf and string_list just before exiting is not strictly
necessary, but it gets rid of false positives reported by leak checkers,
which can then be more easily used to show that the column-printing
machinery behind print_columns() are free of leaks.
Signed-off-by: René Scharfe <l.s.r@web.de>
---
builtin/column.c | 2 ++
t/t9002-column.sh | 1 +
2 files changed, 3 insertions(+)
diff --git a/builtin/column.c b/builtin/column.c
index a83be8bc99..e80218f81f 100644
--- a/builtin/column.c
+++ b/builtin/column.c
@@ -56,5 +56,7 @@ int cmd_column(int argc, const char **argv, const char *prefix)
string_list_append(&list, sb.buf);
print_columns(&list, colopts, &copts);
+ strbuf_release(&sb);
+ string_list_clear(&list, 0);
return 0;
}
diff --git a/t/t9002-column.sh b/t/t9002-column.sh
index 6d3dbde3fe..348cc40658 100755
--- a/t/t9002-column.sh
+++ b/t/t9002-column.sh
@@ -1,6 +1,7 @@
#!/bin/sh
test_description='git column'
+TEST_PASSES_SANITIZE_LEAK=true
. ./test-lib.sh
test_expect_success 'setup' '
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] builtin/reflog.c: fix dry-run option short name
From: Junio C Hamano @ 2023-11-26 8:44 UTC (permalink / raw)
To: Josh Brobst; +Cc: git
In-Reply-To: <20231126000514.85509-1-josh@brob.st>
Josh Brobst <josh@brob.st> writes:
> The documentation for reflog states that the --dry-run option of the
> expire and delete subcommands has a corresponding short name, -n.
> However, 33d7bdd645 (builtin/reflog.c: use parse-options api for expire,
> delete subcommands, 2022-01-06) did not include this short name in the
> new options parsing.
>
> Re-add the short name in the new dry-run option definitions.
Perfect. Thanks for spotting and doing necessary archaeology.
^ permalink raw reply
* [PATCH v2 4/4] completion: avoid user confusion in non-cone mode
From: Elijah Newren via GitGitGadget @ 2023-11-26 7:51 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, SZEDER Gábor, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1349.v2.git.1700985086.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
It is tempting to think of "files and directories" of the current
directory as valid inputs to the add and set subcommands of git
sparse-checkout. However, in non-cone mode, they often aren't and using
them as potential completions leads to *many* forms of confusion:
Issue #1. It provides the *wrong* files and directories.
For
git sparse-checkout add
we always want to add files and directories not currently in our sparse
checkout, which means we want file and directories not currently present
in the current working tree. Providing the files and directories
currently present is thus always wrong.
For
git sparse-checkout set
we have a similar problem except in the subset of cases where we are
trying to narrow our checkout to a strict subset of what we already
have. That is not a very common scenario, especially since it often
does not even happen to be true for the first use of the command; for
years we required users to create a sparse-checkout via
git sparse-checkout init
git sparse-checkout set <args...>
(or use a clone option that did the init step for you at clone time).
The init command creates a minimal sparse-checkout with just the
top-level directory present, meaning the set command has to be used to
expand the checkout. Thus, only in a special and perhaps unusual cases
would any of the suggestions from normal file and directory completion
be appropriate.
Issue #2: Suggesting patterns that lead to warnings is unfriendly.
If the user specifies any regular file and omits the leading '/', then
the sparse-checkout command will warn the user that their command is
problematic and suggest they use a leading slash instead.
Issue #3: Completion gets confused by leading '/', and provides wrong paths.
Users often want to anchor their patterns to the toplevel of the
repository, especially when listing individual files. There are a
number of reasons for this, but notably even sparse-checkout encourages
them to do so (as noted above). However, if users do so (via adding a
leading '/' to their pattern), then bash completion will interpret the
leading slash not as a request for a path at the toplevel of the
repository, but as a request for a path at the root of the filesytem.
That means at best that completion cannot help with such paths, and if
it does find any completions, they are almost guaranteed to be wrong.
Issue #4: Suggesting invalid patterns from subdirectories is unfriendly.
There is no per-directory equivalent to .gitignore with
sparse-checkouts. There is only a single worktree-global
$GIT_DIR/info/sparse-checkout file. As such, paths to files must be
specified relative to the toplevel of a repository. Providing
suggestions of paths that are relative to the current working directory,
as bash completion defaults to, is wrong when the current working
directory is not the worktree toplevel directory.
Issue #5: Paths with special characters will be interpreted incorrectly
The entries in the sparse-checkout file are patterns, not paths. While
most paths also qualify as patterns (though even in such cases it would
be better for users to not use them directly but prefix them with a
leading '/'), there are a variety of special characters that would need
special escaping beyond the normal shell escaping: '*', '?', '\', '[',
']', and any leading '#' or '!'. If completion suggests any such paths,
users will likely expect them to be treated as an exact path rather than
as a pattern that might match some number of files other than 1.
Because of the combination of the above issues, turn completion off for
the `set` and `add` subcommands of `sparse-checkout` when in non-cone
mode, but leave a NEEDSWORK comment specifying what could theoretically
be done if someone wanted to provide completion rules that were more
helpful than harmful.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
contrib/completion/git-completion.bash | 62 ++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c614e5d4f07..1e07dc8b73e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -3138,6 +3138,68 @@ _git_sparse_checkout ()
fi
if [[ "$using_cone" == "true" ]]; then
__gitcomp_directories
+ else
+ # NEEDSWORK: It might be useful to provide a
+ # completion function which:
+ #
+ # 1. Provides completions based on
+ # files/directories that exist in HEAD (or in
+ # the index since sparse-index isn't possible
+ # in non-cone mode), not just those currently
+ # present in the working tree. Bash's
+ # default file and directory completion is
+ # totally useless for "git sparse-checkout
+ # add" because of this. It is likewise
+ # problematic for "git sparse-checkout set"
+ # except in those subset of cases when trying
+ # to narrow scope to a strict subset of what
+ # you already have checked out.
+ #
+ # 2. Always provides file/directory completions
+ # with a prepended leading '/', so that
+ # files/directories are only searched at the
+ # relevant level rather than throughout all
+ # trees in the hierarchy. Doing this also
+ # avoids suggesting the user run a
+ # sparse-checkout command that will result in
+ # a warning be thrown at the user.
+ #
+ # 3. Does not accidentally search the root of
+ # the filesystem when a path with a leading
+ # slash is specified. ("git sparse-checkout
+ # add /ho<TAB>" should not complete to
+ # "/home" but to e.g. "/hooks" if there is a
+ # "hooks" in the top of the repository.)
+ #
+ # 4. Provides no completions when run from a
+ # subdirectory of the repository root. (If we
+ # did provide file/directory completions, the
+ # user would just get a "please run from the
+ # toplevel directory" error message when they
+ # ran it. *Further*, if the user did rerun
+ # the command from the toplevel, the
+ # completions we previously provided would
+ # likely be wrong as they'd be relative to the
+ # subdirectory rather than the repository
+ # root. That could lead to users getting a
+ # nasty surprise based on trying to use a
+ # command we helped them create.)
+ #
+ # 5. Provides escaped completions for any paths
+ # containing a '*', '?', '\', '[', ']', or
+ # leading '#' or '!'. (These characters might
+ # already be escaped to protect from the
+ # shell, but they need an *extra* layer of
+ # escaping to prevent the pattern parsing in
+ # Git from seeing them as special characters.)
+ #
+ # Of course, this would be a lot of work, so for now,
+ # just avoid the many forms of user confusion that
+ # could be caused by providing bad completions by
+ # providing a fake completion to avoid falling back to
+ # bash's normal file and directory completion.
+
+ COMPREPLY=( "" )
fi
esac
}
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 3/4] completion: avoid misleading completions in cone mode
From: Elijah Newren via GitGitGadget @ 2023-11-26 7:51 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, SZEDER Gábor, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1349.v2.git.1700985086.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
The "set" and "add" subcommands of "sparse-checkout", when in cone mode,
should only complete on directories. For bash_completion in general,
when no completions are returned for any subcommands, it will often fall
back to standard completion of files and directories as a substitute.
That is not helpful here. Since we have already looked for all valid
completions, if none are found then falling back to standard bash file
and directory completion is at best actively misleading. In fact, there
are three different ways it can be actively misleading. Add a long
comment in the code about how that fallback behavior can deceive, and
disable the fallback by returning a fake result as the sole completion.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
contrib/completion/git-completion.bash | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 7aa66c19ede..c614e5d4f07 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -3090,6 +3090,26 @@ __gitcomp_directories ()
# No possible further completions any deeper, so assume we're at
# a leaf directory and just consider it complete
__gitcomp_direct_append "$cur "
+ elif [[ $_found == 0 ]]; then
+ # No possible completions found. Avoid falling back to
+ # bash's default file and directory completion, because all
+ # valid completions have already been searched and the
+ # fallbacks can do nothing but mislead. In fact, they can
+ # mislead in three different ways:
+ # 1) Fallback file completion makes no sense when asking
+ # for directory completions, as this function does.
+ # 2) Fallback directory completion is bad because
+ # e.g. "/pro" is invalid and should NOT complete to
+ # "/proc".
+ # 3) Fallback file/directory completion only completes
+ # on paths that exist in the current working tree,
+ # i.e. which are *already* part of their
+ # sparse-checkout. Thus, normal file and directory
+ # completion is always useless for "git
+ # sparse-checkout add" and is also probelmatic for
+ # "git sparse-checkout set" unless using it to
+ # strictly narrow the checkout.
+ COMPREPLY=( "" )
fi
}
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 2/4] completion: fix logic for determining whether cone mode is active
From: Elijah Newren via GitGitGadget @ 2023-11-26 7:51 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, SZEDER Gábor, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1349.v2.git.1700985086.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
_git_sparse_checkout() was checking whether we were in cone mode by
checking whether either:
A) core.sparseCheckoutCone was "true"
B) "--cone" was specified on the command line
This code has 2 bugs I didn't catch in my review at the time
1) core.sparseCheckout must be "true" for core.sparseCheckoutCone to
be relevant (which matters since "git sparse-checkout disable"
only unsets core.sparseCheckout, not core.sparseCheckoutCone)
2) The presence of "--no-cone" should override any config setting
Further, I forgot to update this logic as part of 2d95707a02
("sparse-checkout: make --cone the default", 2022-04-22) for the new
default.
Update the code for the new default and make it be more careful in
determining whether to complete based on cone mode or non-cone mode.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
contrib/completion/git-completion.bash | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b8661701718..7aa66c19ede 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -3097,6 +3097,7 @@ _git_sparse_checkout ()
{
local subcommands="list init set disable add reapply"
local subcommand="$(__git_find_on_cmdline "$subcommands")"
+ local using_cone=true
if [ -z "$subcommand" ]; then
__gitcomp "$subcommands"
return
@@ -3107,8 +3108,15 @@ _git_sparse_checkout ()
__gitcomp_builtin sparse-checkout_$subcommand "" "--"
;;
set,*|add,*)
- if [ "$(__git config core.sparseCheckoutCone)" == "true" ] ||
- [ -n "$(__git_find_on_cmdline --cone)" ]; then
+ if [[ "$(__git config core.sparseCheckout)" == "true" &&
+ "$(__git config core.sparseCheckoutCone)" == "false" &&
+ -z "$(__git_find_on_cmdline --cone)" ]]; then
+ using_cone=false
+ fi
+ if [[ -n "$(__git_find_on_cmdline --no-cone)" ]]; then
+ using_cone=false
+ fi
+ if [[ "$using_cone" == "true" ]]; then
__gitcomp_directories
fi
esac
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 0/4] Sparse checkout completion fixes
From: Elijah Newren via GitGitGadget @ 2023-11-26 7:51 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, SZEDER Gábor, Elijah Newren
In-Reply-To: <pull.1349.git.1700761448.gitgitgadget@gmail.com>
This fixes a few issues with tab completion for the sparse-checkout command,
specifically with the "add" and "set" subcommands.
As noted in v1, the 4th patch implements a somewhat suboptimal solution that
at least improves the situation, while also documenting with a code comment
a much more involved alternative solution that we could consider in the
future.
Changes since v1:
* Use __git wrapper function to squelch errors, as suggested by SZEDER
Gábor
* note that we could use the index or HEAD for the more involved solution
in patch 4.
[1] https://lore.kernel.org/git/xmqqv8yjz5us.fsf@gitster.g/
Elijah Newren (4):
completion: squelch stray errors in sparse-checkout completion
completion: fix logic for determining whether cone mode is active
completion: avoid misleading completions in cone mode
completion: avoid user confusion in non-cone mode
contrib/completion/git-completion.bash | 96 +++++++++++++++++++++++++-
1 file changed, 93 insertions(+), 3 deletions(-)
base-commit: 564d0252ca632e0264ed670534a51d18a689ef5d
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1349%2Fnewren%2Fsparse-checkout-completion-fixes-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1349/newren/sparse-checkout-completion-fixes-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1349
Range-diff vs v1:
1: 591c7b8d73b ! 1: 97e20e3b99d completion: squelch stray errors in sparse-checkout completion
@@ Commit message
fatal: ../: '../' is outside repository at '/home/newren/floss/git'
is written to stderr, which munges the users view of their own command.
- Squelch such messages.
+ Squelch such messages by using the __git() wrapper, designed for this
+ purpose; see commit e15098a314 (completion: consolidate silencing errors
+ from git commands, 2017-02-03) for more on the wrapper.
Signed-off-by: Elijah Newren <newren@gmail.com>
@@ contrib/completion/git-completion.bash: __gitcomp_directories ()
_found=1
fi
- done < <(git ls-tree -z -d --name-only HEAD $_tmp_dir)
-+ done < <(git ls-tree -z -d --name-only HEAD $_tmp_dir 2>/dev/null)
++ done < <(__git ls-tree -z -d --name-only HEAD $_tmp_dir)
if [[ $_found == 0 ]] && [[ "$cur" =~ /$ ]]; then
# No possible further completions any deeper, so assume we're at
2: a15fb054579 = 2: 212ba35ed46 completion: fix logic for determining whether cone mode is active
3: e8cc5c54e60 = 3: 1cbbcd9097c completion: avoid misleading completions in cone mode
4: fe8669a3f4f ! 4: 604f21dc827 completion: avoid user confusion in non-cone mode
@@ contrib/completion/git-completion.bash: _git_sparse_checkout ()
+ # completion function which:
+ #
+ # 1. Provides completions based on
-+ # files/directories that exist in HEAD, not
-+ # just those currently present in the working
-+ # tree. Bash's default file and directory
-+ # completion is totally useless for "git
-+ # sparse-checkout add" because of this. It is
-+ # likewise problematic for "git
-+ # sparse-checkout set" except in those subset
-+ # of cases when trying to narrow scope to a
-+ # strict subset of what you already have
-+ # checked out.
++ # files/directories that exist in HEAD (or in
++ # the index since sparse-index isn't possible
++ # in non-cone mode), not just those currently
++ # present in the working tree. Bash's
++ # default file and directory completion is
++ # totally useless for "git sparse-checkout
++ # add" because of this. It is likewise
++ # problematic for "git sparse-checkout set"
++ # except in those subset of cases when trying
++ # to narrow scope to a strict subset of what
++ # you already have checked out.
+ #
+ # 2. Always provides file/directory completions
+ # with a prepended leading '/', so that
--
gitgitgadget
^ permalink raw reply
* [PATCH v2 1/4] completion: squelch stray errors in sparse-checkout completion
From: Elijah Newren via GitGitGadget @ 2023-11-26 7:51 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, SZEDER Gábor, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1349.v2.git.1700985086.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
If, in the root of a project, one types
git sparse-checkout set --cone ../<TAB>
then an error message of the form
fatal: ../: '../' is outside repository at '/home/newren/floss/git'
is written to stderr, which munges the users view of their own command.
Squelch such messages by using the __git() wrapper, designed for this
purpose; see commit e15098a314 (completion: consolidate silencing errors
from git commands, 2017-02-03) for more on the wrapper.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 13a39ebd2e7..b8661701718 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -3084,7 +3084,7 @@ __gitcomp_directories ()
COMPREPLY+=("$c/")
_found=1
fi
- done < <(git ls-tree -z -d --name-only HEAD $_tmp_dir)
+ done < <(__git ls-tree -z -d --name-only HEAD $_tmp_dir)
if [[ $_found == 0 ]] && [[ "$cur" =~ /$ ]]; then
# No possible further completions any deeper, so assume we're at
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH] doc: make the gitfile syntax easier to discover
From: Junio C Hamano @ 2023-11-26 3:04 UTC (permalink / raw)
To: Marcel Krause; +Cc: git mailing list
In-Reply-To: <20231124194711.563720-1-mk+copyleft@pimpmybyte.de>
Marcel Krause <mk+copyleft@pimpmybyte.de> writes:
> It took way too long for me to find the syntax expected for a gitfile.
> My search engine found the gitglossary manpage which defined the term
> but had no hints about syntax.
> Thus here I add a mention of gitrepository-layout.
Everything you wrote is not very interesting or relevant story we
want to see in order to explain and justify this change. The title
itself is sufficient, i.e. it had poor visibility, and you fix it by
giving it better visibility.
A more relevant is why you needed to find out what the former should
be in the first place. "git submodule init" and "git worktree add"
would create them as necessary without you needing to know about the
exact implementation.
> Signed-off-by: Marcel Krause <mk+copyleft@pimpmybyte.de>
> ---
> Documentation/gitrepository-layout.txt | 8 ++++----
> Documentation/glossary-content.txt | 1 +
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
> index 1a2ef4c150..c52b8564e3 100644
> --- a/Documentation/gitrepository-layout.txt
> +++ b/Documentation/gitrepository-layout.txt
> @@ -23,10 +23,10 @@ A Git repository comes in two different flavours:
>
> *Note*: Also you can have a plain text file `.git` at the root of
> your working tree, containing `gitdir: <path>` to point at the real
> -directory that has the repository. This mechanism is often used for
> -a working tree of a submodule checkout, to allow you in the
> -containing superproject to `git checkout` a branch that does not
> -have the submodule. The `checkout` has to remove the entire
> +directory that has the repository. This mechanism is called a 'gitfile'
> +and is often used for a working tree of a submodule checkout, to allow
> +you in the containing superproject to `git checkout` a branch that
> +does not have the submodule. The `checkout` has to remove the entire
> submodule working tree, without losing the submodule repository.
Do not unnecessary rewrap existing text, only to insert a few words,
to force reviewers read a lot more than needed.
> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
> index 5a537268e2..e5f55bf670 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -184,6 +184,7 @@ current branch integrates with) obviously do not work, as there is no
> [[def_gitfile]]gitfile::
> A plain file `.git` at the root of a working tree that
> points at the directory that is the real repository.
> + See linkgit:gitrepository-layout for the syntax.
Running "git grep linkgit:gitrepository-layout" would help you find
the right way to spell this one, I think.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email causes failures because of wrong option specifications
From: Eric Sunshine @ 2023-11-26 2:39 UTC (permalink / raw)
To: H.Merijn Brand - Tux; +Cc: git
In-Reply-To: <20231125094429.12025-2-linux@tux.freedom.nl>
On Sat, Nov 25, 2023 at 4:52 AM H.Merijn Brand - Tux
<linux@tux.freedom.nl> wrote:
> ...
> git-2.43.0 🐧 perl -Iperl git-send-email.perl --help
> Duplicate specification "cc-cover|cc-cover!" for option "cc-cover"
> Duplicate specification "no-cc-cover" for option "no-cc-cover"
> ...
> Signed-off-by: H.Merijn Brand - Tux <linux@tux.freedom.nl>
> ---
> diff --git a/git-send-email.perl b/git-send-email.perl
> @@ -506,36 +505,27 @@ sub config_regexp {
> - "no-signed-off-cc|no-signed-off-by-cc" => sub {$signed_off_by_cc = 0},
> - "cc-cover|cc-cover!" => \$cover_cc,
> - "no-cc-cover" => sub {$cover_cc = 0},
> - "to-cover|to-cover!" => \$cover_to,
> - "no-to-cover" => sub {$cover_to = 0},
> + "cc-cover!" => \$cover_cc,
> + "to-cover!" => \$cover_to,
Thanks for submitting a patch to address this issue. It matches very
closely an earlier patch[1] addressing the same purpose which has
already made it into Junio's "next" branch.
[1]: https://lore.kernel.org/git/20231116193014.470420-3-tmz@pobox.com/
^ permalink raw reply
* [PATCH] builtin/reflog.c: fix dry-run option short name
From: Josh Brobst @ 2023-11-26 0:05 UTC (permalink / raw)
To: git; +Cc: Josh Brobst
The documentation for reflog states that the --dry-run option of the
expire and delete subcommands has a corresponding short name, -n.
However, 33d7bdd645 (builtin/reflog.c: use parse-options api for expire,
delete subcommands, 2022-01-06) did not include this short name in the
new options parsing.
Re-add the short name in the new dry-run option definitions.
Signed-off-by: Josh Brobst <josh@brob.st>
---
builtin/reflog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/reflog.c b/builtin/reflog.c
index df63a5892e..a39962df69 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -248,7 +248,7 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
int verbose = 0;
reflog_expiry_should_prune_fn *should_prune_fn = should_expire_reflog_ent;
const struct option options[] = {
- OPT_BIT(0, "dry-run", &flags, N_("do not actually prune any entries"),
+ OPT_BIT('n', "dry-run", &flags, N_("do not actually prune any entries"),
EXPIRE_REFLOGS_DRY_RUN),
OPT_BIT(0, "rewrite", &flags,
N_("rewrite the old SHA1 with the new SHA1 of the entry that now precedes it"),
@@ -368,7 +368,7 @@ static int cmd_reflog_delete(int argc, const char **argv, const char *prefix)
int verbose = 0;
const struct option options[] = {
- OPT_BIT(0, "dry-run", &flags, N_("do not actually prune any entries"),
+ OPT_BIT('n', "dry-run", &flags, N_("do not actually prune any entries"),
EXPIRE_REFLOGS_DRY_RUN),
OPT_BIT(0, "rewrite", &flags,
N_("rewrite the old SHA1 with the new SHA1 of the entry that now precedes it"),
--
2.42.0
^ permalink raw reply related
* Re: [BUG] `git push` sends unnecessary objects
From: Javier Mora @ 2023-11-25 14:54 UTC (permalink / raw)
To: Bagas Sanjaya; +Cc: Git Mailing List, Derrick Stolee, Junio C Hamano
In-Reply-To: <ZQb9Thxa5X-Fo5mj@debian.me>
Apparently if I do that in two commits (one to move the dir, and a
second one add the file), and then push all that after the second
commit, this doesn't happen -- the resulting push will only contain 6
objects (2 commits, 3 trees, and 1 file), and be a few bytes large.
El dom, 17 sept 2023 a las 14:21, Bagas Sanjaya
(<bagasdotme@gmail.com>) escribió:
>
> On Wed, Sep 13, 2023 at 11:59:35PM +0100, Javier Mora wrote:
> > I came across this issue accidentally when trying to move a directory
> > containing a very large file, and deleting another file in that
> > directory while I was at it.
> > It seems to be caused by `pack.useSparse=true` being the default since
> > v2.27 (which I found out after spending quite a while manually
> > bisecting and compiling git since I noticed that this didn't happen in
> > v2.25; commit de3a864 introduces this regression).
> >
> > * Expected:
> > Pushing a commit that moves a file without modifying it shouldn't
> > require sending a blob object for that file, since the remote server
> > already has that blob object.
> > * Observed:
> > Pushing a commit that moves a directory containing a file and also
> > adds/deletes other files in that directory will for some reason also
> > send blobs for all the files in that directory, even the ones that
> > were already in the remote.
> > * Consequences:
> > This has a very big impact in push times for very small commits
> > that just move around files, if those files are very big (I had this
> > happen with a >100MB file over a problematic connection... yikes!)
> > * Note:
> > The commit introducing the regression does warn about possible
> > scenarios involving a special arrangement of exact copies across
> > directories, but these are not "copies", I just moved a file, which
> > seems like a rather common operation.
> >
> > Code snippet for reproduction:
> > ```
> > mkdir TEST_git
> > cd TEST_git
> >
> > mkdir -p local remote/origin.git
> > cd remote/origin.git
> > git init --bare
> > cd ../../local
> > git init
> > git remote add origin file://"${PWD%/*}"/remote/origin.git
> >
> > mkdir zig
> > for i in a b c d e; do
> > dd if=/dev/urandom of=zig/"$i" bs=1M count=1
> > done
> > git add .
> > git commit -m 'Add big files'
> > git push -u origin master
> > #>> Writing objects: 100% (8/8), 5.00 MiB | 13.27 MiB/s, done.
> > #^ makes sense: 1 commit + 2 trees (/ and /zig) + 5 files = 8;
> > # 5 MiB in total for the 5x 1 MiB binary files
> >
> > git mv zig zag
> > git commit -m 'Move zig'
> > git push
> > #>> Writing objects: 100% (2/2), 233 bytes | 233.00 KiB/s, done.
> > #^ makes sense: 1 commit + 1 tree (/ renames /zig to /zag) = 2;
> > # a,b,c,d,e objects already in remote
> >
> > git mv zag zog
> > touch zog/f
> > git add zog/f
> > git commit -m 'For great justice'
> > git push
> > #>> Writing objects: 100% (9/9), 5.00 MiB | 24.63 MiB/s, done.
> > #^ It re-uploaded the 5x 1 MiB blobs
> > # even though remote already had them.
> > ```
> >
> > Note that the latter doesn't happen if I use `git -c pack.useSparse=false push`.
>
> I can reproduce this regression on v2.42.0 (self-compiled) on my Debian
> testing system.
>
> Cc'ing Derrick and Junio.
>
> Thanks for the report!
>
> --
> An old man doll... just what I always wanted! - Clara
^ permalink raw reply
* Re: Fix git-send-email.perl w.r.t. recent Getopt::Long update
From: Dragan Simic @ 2023-11-25 12:28 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Bagas Sanjaya, Git Mailing List
In-Reply-To: <20231125104211.5b7fe0be@pc09>
On 2023-11-25 10:45, H.Merijn Brand wrote:
> As I am used to PR's by now on all OSS projects I am involved in, or
> use git commits or merges directly on the repo, I *never* use
> format-patch and/or send-email.
Actually, using email to send patches is quite neat, IMHO, once you get
hold of it.
> These docs - yes I read them - do not offer a concise cut-n-paste
> example for people like me. In order to have my relative simple patch
> submitted (I already had the PR ready, but that came with a huge
> warning that PR's are not accepted) I did it the way I did it. Now I
> need to read and learn two new commands> I don't think that is very
> user-friendly, but that might be just me.
>
> Ironically, this patch is about the mail part of git.
>
> I suggest adding a small example like
>
> # Create the patch basics
> $ git format-patch --cover-letter -M origin/master -o outgoing
> # Fix the subject
> $ $VISUAL outgoing/0000-cover-letter.patch
> # Send the mail
> $ git send-email --to=git@vger.kernel.org outgoing/*
Please note that a cover letter isn't needed unless you're sending a
patch series, i.e. unless you're generating and sending more than a
single patch at once. Also, fixing the subject line inside the patch
files generated by git-format-patch shouldn't be needed in most cases,
and commit summaries should be adjusted/rebased instead, if needed.
^ permalink raw reply
* Re: "git overlay" - command for overlaying branches
From: Michal Suchánek @ 2023-11-25 10:50 UTC (permalink / raw)
To: Oliver Bandel; +Cc: git
In-Reply-To: <647focpqwyild7dbmw7dloc5q2irijk7z77ymmfut5zdjrqhzy@xsle27m6flun>
On Sat, Nov 25, 2023 at 12:51:06AM +0100, Oliver Bandel wrote:
> Quoting Michal Suchánek <msuchanek@suse.de> (snt: 2023-11-24 21:59 +0100 CET) (rcv: 2023-11-24 21:59 +0100 CET):
> > On Fri, Nov 24, 2023 at 05:39:12PM +0100, Oliver Bandel wrote:
> > > Hello,
> > >
> > > I'm adressing the problem with files separated from the main branch(es),
> > > which currently might be (more or less) solved with either submodules or subtrees.
> > > I want to suggest a new command here.
> > >
> > > As usecase-example I assume a project that has 'branch_a' and 'branch_b'
> > > with some files may be identical, some different between them.
> > > I assume that the (classical) way the files are handled
> > > by belonging to those branches is intended.
> > >
> > > Then say later I want to add more files to these branches,
> > > but don't want to commit them in either of these existing branches.
> > > Instead a branch 'branch_addons' is created, which solely contains
> > > files that are used in 'branch_a' as well as 'branch_b'.
> >
> > Now you can merge branch_addons onto branch_a and branch_b and be done.
>
> Maybe my example or the explanation was not clear enough or stopped to early.
>
> After a merge, I may have added files from one branch to another branch
> and some files might be changed during the merge operation and this is
> persistent then.
>
> But the overlay would be a temporal situation and so no "pollution" with files from
> other branches would occur and no changes of the files with same names
> (some were just temporarily hidden).
>
> In an overlay situation, all involved branches are checked out into the
> working dir (the non-hidden files are checked out) at the same time.
> All changes (change/add/commit) could then be done in one go (with 'git
> add' and 'git commit' as in the usual way), and all commits will only
> affect those branches where the changed files are comming from.
> This means editing more than one branch at the same time,
> committing to more than one branch at the same time,
> but not merging them.
>
> After un-overloading, the temporarily overlayed files from other
> branches will be removed from the working dir by git.
> No merge has been done, but changes to more than one branch might have
> happened.
>
> I hope it's more clear now, how that differs from normal merge-branches situation.
It's not clear why would anyone do that, though.
>
> Ciao,
> Oliver
>
> P.S.: Changing sources and tests together but only publishing the code would be
> easy this way.
And why would you do that?
Even if you wanted the git archive has option to exclude directories so
you could publish separate releases from one branch.
> Just check out the sources, overlay the tests, do the work, commit
> the changes and after un-overlaying the sources branch has no
> "tests pollution", and no other tricks are needed then.
Since you detail how 'do the work' would commit the changes to both
branches at the same time that means that specific revision of the code
is tied to specific revision of the tests, different revisions would not
work together. If the overlay branch is used with multiple different
branches it will diverge, and will be compatible only with one of them
at any time.
Merging a specific revision of the overlay branch solves this problem.
It ties the correct revision of the shared branch together with the
correct revision of the separate files.
It's the same with the interface-implementation example you gave
earlier.
> Also useful, when working with LaTeX documents and you temporarily
> want to change the included extra files (or use the other layoutet
> old version together with the current one) from a different
> branch, but don't want the changes be permanently in your
> currently preferred main branch (nevertheless change the main-doc
> and the extra files in one go).
Don't really understand what you are trying to do here.
> For those people who commit their passwords or private keys into git,
> this also could increase security ;-)
> For testing the code, the secrets are just overlayed.
Or not put those into project git in the first place. When the secrets
are in an 'overlay branch' in the same repository they are published
anyway.
Thanks
Michal
^ permalink raw reply
* [PATCH 0/1] git-send-email causes failures because of wrong option specifications
From: H.Merijn Brand - Tux @ 2023-11-25 9:44 UTC (permalink / raw)
To: git; +Cc: H.Merijn Brand - Tux
*** BLURB HERE ***
H.Merijn Brand - Tux (1):
git-send-email causes failures because of wrong option specifications
git-send-email.perl | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/1] git-send-email causes failures because of wrong option specifications
From: H.Merijn Brand - Tux @ 2023-11-25 9:44 UTC (permalink / raw)
To: git; +Cc: H.Merijn Brand - Tux
In-Reply-To: <20231125094429.12025-1-linux@tux.freedom.nl>
From the Getopt::Long changes:
```
Changes in version 2.55
-----------------------
* Fix long standing bug that duplicate options were not detected when
the options differ in case while ignore_case is in effect.
This will now yield a warning and become a fatal error in a future
release.
```
Current version is 2.57
```
git-2.43.0 🐧 perl -Iperl git-send-email.perl --help
Duplicate specification "cc-cover|cc-cover!" for option "cc-cover"
Duplicate specification "no-cc-cover" for option "no-cc-cover"
Duplicate specification "to-cover|to-cover!" for option "to-cover"
Duplicate specification "no-annotate" for option "no-annotate"
Duplicate specification "no-format-patch" for option "no-format-patch"
Duplicate specification "no-signed-off-cc|no-signed-off-by-cc" for option "no-signed-off-cc"
Duplicate specification "no-signed-off-cc|no-signed-off-by-cc" for option "no-signed-off-by-cc"
Duplicate specification "no-validate" for option "no-validate"
Duplicate specification "no-chain-reply-to" for option "no-chain-reply-to"
```
`"option!" => \$value`
*automatically* supports both `--option` and `--no-option` and `--nooption`
See the docs for Getopt::Long:
```
The argument specification can be
! The option does not take an argument and may be negated by
prefixing it with "no" or "no-". E.g. "foo!" will allow "--foo" (a
value of 1 will be assigned) as well as "--nofoo" and "--no-foo" (a
value of 0 will be assigned). If the option has aliases, this
applies to the aliases as well.
Using negation on a single letter option when bundling is in effect
is pointless and will result in a warning.
```
Signed-off-by: H.Merijn Brand - Tux <linux@tux.freedom.nl>
---
git-send-email.perl | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index d24e981d61..125f49cd08 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -491,7 +491,6 @@ sub config_regexp {
"bcc=s" => \@getopt_bcc,
"no-bcc" => \$no_bcc,
"chain-reply-to!" => \$chain_reply_to,
- "no-chain-reply-to" => sub {$chain_reply_to = 0},
"sendmail-cmd=s" => \$sendmail_cmd,
"smtp-server=s" => \$smtp_server,
"smtp-server-option=s" => \@smtp_server_options,
@@ -506,36 +505,27 @@ sub config_regexp {
"smtp-auth=s" => \$smtp_auth,
"no-smtp-auth" => sub {$smtp_auth = 'none'},
"annotate!" => \$annotate,
- "no-annotate" => sub {$annotate = 0},
"compose" => \$compose,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
"header-cmd=s" => \$header_cmd,
"no-header-cmd" => \$no_header_cmd,
"suppress-from!" => \$suppress_from,
- "no-suppress-from" => sub {$suppress_from = 0},
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
- "no-signed-off-cc|no-signed-off-by-cc" => sub {$signed_off_by_cc = 0},
- "cc-cover|cc-cover!" => \$cover_cc,
- "no-cc-cover" => sub {$cover_cc = 0},
- "to-cover|to-cover!" => \$cover_to,
- "no-to-cover" => sub {$cover_to = 0},
+ "cc-cover!" => \$cover_cc,
+ "to-cover!" => \$cover_to,
"confirm=s" => \$confirm,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
- "no-thread" => sub {$thread = 0},
"validate!" => \$validate,
- "no-validate" => sub {$validate = 0},
"transfer-encoding=s" => \$target_xfer_encoding,
"format-patch!" => \$format_patch,
- "no-format-patch" => sub {$format_patch = 0},
"8bit-encoding=s" => \$auto_8bit_encoding,
"compose-encoding=s" => \$compose_encoding,
"force" => \$force,
"xmailer!" => \$use_xmailer,
- "no-xmailer" => sub {$use_xmailer = 0},
"batch-size=i" => \$batch_size,
"relogin-delay=i" => \$relogin_delay,
"git-completion-helper" => \$git_completion_helper,
--
2.42.1
^ permalink raw reply related
* Re: Fix git-send-email.perl w.r.t. recent Getopt::Long update
From: H.Merijn Brand @ 2023-11-25 9:45 UTC (permalink / raw)
To: Bagas Sanjaya, Git Mailing List
In-Reply-To: <ZWFaZcgzwEP13geI@archie.me>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
On Sat, 25 Nov 2023 09:22:29 +0700, Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> On Fri, Nov 24, 2023 at 10:39:32AM +0100, H.Merijn Brand wrote:
> > Patch attached
>
> Do not send patches as attachments; send them inline instead. See
> Documentation/SubmittingPatches for more info (hint: send patches
> with git-send-email(1)).
As I am used to PR's by now on all OSS projects I am involved in, or
use git commits or merges directly on the repo, I *never* use
format-patch and/or send-email.
These docs - yes I read them - do not offer a concise cut-n-paste
example for people like me. In order to have my relative simple patch
submitted (I already had the PR ready, but that came with a huge
warning that PR's are not accepted) I did it the way I did it. Now I
need to read and learn two new commands> I don't think that is very
user-friendly, but that might be just me.
Ironically, this patch is about the mail part of git.
I suggest adding a small example like
# Create the patch basics
$ git format-patch --cover-letter -M origin/master -o outgoing
# Fix the subject
$ $VISUAL outgoing/0000-cover-letter.patch
# Send the mail
$ git send-email --to=git@vger.kernel.org outgoing/*
> Thanks.
--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Fix git-send-email.perl w.r.t. recent Getopt::Long update
From: Bagas Sanjaya @ 2023-11-25 2:22 UTC (permalink / raw)
To: H.Merijn Brand, Git Mailing List
Cc: Todd Zullinger, Michael Strawbridge, Jeff King, Junio C Hamano
In-Reply-To: <20231124103932.31ca7688@pc09>
[-- Attachment #1: Type: text/plain, Size: 318 bytes --]
On Fri, Nov 24, 2023 at 10:39:32AM +0100, H.Merijn Brand wrote:
> Patch attached
Do not send patches as attachments; send them inline instead. See
Documentation/SubmittingPatches for more info (hint: send patches
with git-send-email(1)).
Thanks.
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v8 00/14] Introduce new `git replay` command
From: Johannes Schindelin @ 2023-11-25 0:02 UTC (permalink / raw)
To: Christian Couder
Cc: git, Junio C Hamano, Patrick Steinhardt, Elijah Newren, John Cai,
Derrick Stolee, Phillip Wood, Calvin Wan, Toon Claes,
Dragan Simic, Linus Arver
In-Reply-To: <20231124111044.3426007-1-christian.couder@gmail.com>
Hi Christian,
On Fri, 24 Nov 2023, Christian Couder wrote:
> # Changes between v7 and v8
>
> Thanks to Dscho, Linus Arver, Dragan Simic, Elijah, Junio, Derrick
> Stolee, Phillip Wood, Calvin Wan and Toon Claes for their suggestions
> on the previous versions! The only few changes compared to v7 are:
>
> * The patch series was rebased onto master at 564d0252ca (Git 2.43,
> 2023-11-20). This is to make it stand on a stable base.
>
> * In patch 2/14 (replay: introduce new builtin), there is a synopsys
> change in the doc, and the corresponding usage message change as
> suggested by Dscho. This is just about replacing " # EXPERIMENTAL"
> at the end of both the synopsys and usage message with
> "(EXPERIMENTAL!) " at the beginning of them.
Thank you so much for going all the way to where we are now.
> CI tests seem to pass according to:
>
> https://github.com/chriscool/git/actions/runs/6979770154
>
> (Sorry I am not waiting more than 20 minutes for the 3 last ones to
> finish.)
Yes, our test suite takes too long, and I fear that there are quite a few
developers ignoring it as a consequence.
> # Range-diff between v7 and v8
>
> (A single change was made in patch 2/14, but unfortunately as the
> lines changed in that patch are also changed by other patches later,
> it looks like there are more changes in subsequent patches.)
Right, the lines added in 2/14 are changed multiple times over the course
of the patch series.
> 1: cddcd967b2 = 1: 18fd9b0d5d t6429: remove switching aspects of fast-rebase
> 2: c8476fb093 ! 2: fc6bdf4de4 replay: introduce new builtin
> @@ Documentation/git-replay.txt (new)
> +SYNOPSIS
> +--------
> +[verse]
> -+'git replay' --onto <newbase> <oldbase> <branch> # EXPERIMENTAL
> ++(EXPERIMENTAL!) 'git replay' --onto <newbase> <oldbase> <branch>
> +
> +DESCRIPTION
> +-----------
> @@ builtin/replay.c: int cmd__fast_rebase(int argc, const char **argv)
> -
> if (argc == 2 && !strcmp(argv[1], "-h")) {
> - printf("Sorry, I am not a psychiatrist; I can not give you the help you need. Oh, you meant usage...\n");
> -+ printf("git replay --onto <newbase> <oldbase> <branch> # EXPERIMENTAL\n");
> ++ printf("usage: (EXPERIMENTAL!) git replay --onto <newbase> <oldbase> <branch>\n");
> exit(129);
> }
>
> 3: 43322abd1e ! 3: e96a66c352 replay: start using parse_options API
> @@ builtin/replay.c: int cmd_replay(int argc, const char **argv, const char *prefix
> int ret = 0;
>
> - if (argc == 2 && !strcmp(argv[1], "-h")) {
> -- printf("git replay --onto <newbase> <oldbase> <branch> # EXPERIMENTAL\n");
> +- printf("usage: (EXPERIMENTAL!) git replay --onto <newbase> <oldbase> <branch>\n");
> - exit(129);
> + const char * const replay_usage[] = {
> -+ N_("git replay --onto <newbase> <oldbase> <branch> # EXPERIMENTAL"),
> ++ N_("(EXPERIMENTAL!) git replay --onto <newbase> <oldbase> <branch>"),
> + NULL
> + };
> + struct option replay_options[] = {
> 4: 6524c7f045 = 4: f819d283d9 replay: die() instead of failing assert()
> 5: 05d0efa3cb = 5: 68bbcf9492 replay: introduce pick_regular_commit()
> 6: c7a5aad3d6 = 6: 72221c647e replay: change rev walking options
> 7: 01f35f924b = 7: f54d8fce22 replay: add an important FIXME comment about gpg signing
> 8: 1498b24bad = 8: e50cc22522 replay: remove progress and info output
> 9: 6786fc147b = 9: 0c5ea3d18e replay: remove HEAD related sanity check
> 10: 9a24dbb530 = 10: 9fc636fc3d replay: make it a minimal server side command
> 11: ad6ca2fbef ! 11: 2096bcad79 replay: use standard revision ranges
> @@ Documentation/git-replay.txt: git-replay - EXPERIMENTAL: Replay commits on a new
> SYNOPSIS
> --------
> [verse]
> --'git replay' --onto <newbase> <oldbase> <branch> # EXPERIMENTAL
> -+'git replay' --onto <newbase> <revision-range>... # EXPERIMENTAL
> +-(EXPERIMENTAL!) 'git replay' --onto <newbase> <oldbase> <branch>
> ++(EXPERIMENTAL!) 'git replay' --onto <newbase> <revision-range>...
>
> DESCRIPTION
> -----------
> @@ builtin/replay.c: int cmd_replay(int argc, const char **argv, const char *prefix
> int ret = 0;
>
> const char * const replay_usage[] = {
> -- N_("git replay --onto <newbase> <oldbase> <branch> # EXPERIMENTAL"),
> -+ N_("git replay --onto <newbase> <revision-range>... # EXPERIMENTAL"),
> +- N_("(EXPERIMENTAL!) git replay --onto <newbase> <oldbase> <branch>"),
> ++ N_("(EXPERIMENTAL!) git replay --onto <newbase> <revision-range>..."),
> NULL
> };
> struct option replay_options[] = {
> 12: 081864ed5f ! 12: d5414806ef replay: add --advance or 'cherry-pick' mode
> @@ Documentation/git-replay.txt: git-replay - EXPERIMENTAL: Replay commits on a new
> SYNOPSIS
> --------
> [verse]
> --'git replay' --onto <newbase> <revision-range>... # EXPERIMENTAL
> -+'git replay' (--onto <newbase> | --advance <branch>) <revision-range>... # EXPERIMENTAL
> +-(EXPERIMENTAL!) 'git replay' --onto <newbase> <revision-range>...
> ++(EXPERIMENTAL!) 'git replay' (--onto <newbase> | --advance <branch>) <revision-range>...
>
> DESCRIPTION
> -----------
> @@ builtin/replay.c: static struct commit *pick_regular_commit(struct commit *pickm
> int ret = 0;
>
> const char * const replay_usage[] = {
> -- N_("git replay --onto <newbase> <revision-range>... # EXPERIMENTAL"),
> -+ N_("git replay (--onto <newbase> | --advance <branch>) <revision-range>... # EXPERIMENTAL"),
> +- N_("(EXPERIMENTAL!) git replay --onto <newbase> <revision-range>..."),
> ++ N_("(EXPERIMENTAL!) git replay (--onto <newbase> | --advance <branch>) <revision-range>..."),
> NULL
> };
> struct option replay_options[] = {
> 13: 19c4016c7c ! 13: 2a3e521c13 replay: add --contained to rebase contained branches
> @@ Documentation/git-replay.txt: git-replay - EXPERIMENTAL: Replay commits on a new
> SYNOPSIS
> --------
> [verse]
> --'git replay' (--onto <newbase> | --advance <branch>) <revision-range>... # EXPERIMENTAL
> -+'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>... # EXPERIMENTAL
> +-(EXPERIMENTAL!) 'git replay' (--onto <newbase> | --advance <branch>) <revision-range>...
> ++(EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>...
>
> DESCRIPTION
> -----------
> @@ builtin/replay.c: int cmd_replay(int argc, const char **argv, const char *prefix
> int ret = 0;
>
> const char * const replay_usage[] = {
> -- N_("git replay (--onto <newbase> | --advance <branch>) <revision-range>... # EXPERIMENTAL"),
> -+ N_("git replay ([--contained] --onto <newbase> | --advance <branch>) "
> -+ "<revision-range>... # EXPERIMENTAL"),
> +- N_("(EXPERIMENTAL!) git replay (--onto <newbase> | --advance <branch>) <revision-range>..."),
> ++ N_("(EXPERIMENTAL!) git replay "
> ++ "([--contained] --onto <newbase> | --advance <branch>) "
> ++ "<revision-range>..."),
> NULL
> };
> struct option replay_options[] = {
> 14: 29556bcc86 = 14: 93e034faee replay: stop assuming replayed branches do not diverge
The range-diff looks excellent!
Thank you for addressing all of my concerns, I am very much in favor of
getting this version into git/git's main branch.
Thank you,
Johannes
^ permalink raw reply
* Re: "git overlay" - command for overlaying branches
From: Oliver Bandel @ 2023-11-24 23:51 UTC (permalink / raw)
To: Michal Suchánek; +Cc: git
In-Reply-To: <20231124205945.GA9696@kitsune.suse.cz>
Quoting Michal Suchánek <msuchanek@suse.de> (snt: 2023-11-24 21:59 +0100 CET) (rcv: 2023-11-24 21:59 +0100 CET):
> On Fri, Nov 24, 2023 at 05:39:12PM +0100, Oliver Bandel wrote:
> > Hello,
> >
> > I'm adressing the problem with files separated from the main branch(es),
> > which currently might be (more or less) solved with either submodules or subtrees.
> > I want to suggest a new command here.
> >
> > As usecase-example I assume a project that has 'branch_a' and 'branch_b'
> > with some files may be identical, some different between them.
> > I assume that the (classical) way the files are handled
> > by belonging to those branches is intended.
> >
> > Then say later I want to add more files to these branches,
> > but don't want to commit them in either of these existing branches.
> > Instead a branch 'branch_addons' is created, which solely contains
> > files that are used in 'branch_a' as well as 'branch_b'.
>
> Now you can merge branch_addons onto branch_a and branch_b and be done.
Maybe my example or the explanation was not clear enough or stopped to early.
After a merge, I may have added files from one branch to another branch
and some files might be changed during the merge operation and this is
persistent then.
But the overlay would be a temporal situation and so no "pollution" with files from
other branches would occur and no changes of the files with same names
(some were just temporarily hidden).
In an overlay situation, all involved branches are checked out into the
working dir (the non-hidden files are checked out) at the same time.
All changes (change/add/commit) could then be done in one go (with 'git
add' and 'git commit' as in the usual way), and all commits will only
affect those branches where the changed files are comming from.
This means editing more than one branch at the same time,
committing to more than one branch at the same time,
but not merging them.
After un-overloading, the temporarily overlayed files from other
branches will be removed from the working dir by git.
No merge has been done, but changes to more than one branch might have
happened.
I hope it's more clear now, how that differs from normal merge-branches situation.
Ciao,
Oliver
P.S.: Changing sources and tests together but only publishing the code would be
easy this way.
Just check out the sources, overlay the tests, do the work, commit
the changes and after un-overlaying the sources branch has no
"tests pollution", and no other tricks are needed then.
Also useful, when working with LaTeX documents and you temporarily
want to change the included extra files (or use the other layoutet
old version together with the current one) from a different
branch, but don't want the changes be permanently in your
currently preferred main branch (nevertheless change the main-doc
and the extra files in one go).
For those people who commit their passwords or private keys into git,
this also could increase security ;-)
For testing the code, the secrets are just overlayed.
^ permalink raw reply
* [PATCH] doc: make the gitfile syntax easier to discover
From: Marcel Krause @ 2023-11-24 19:47 UTC (permalink / raw)
To: git mailing list; +Cc: Marcel Krause
It took way too long for me to find the syntax expected for a gitfile.
My search engine found the gitglossary manpage which defined the term
but had no hints about syntax.
Thus here I add a mention of gitrepository-layout.
Once I somehow found gitrepository-layout, I searched for "gitfile" in
there, but had no matches. It took a moment of discouragement and a
minute or so of actually reading to find the info I was looking for.
Thus here I add the part "[This mechanism is] called a 'gitfile'" in
hopes that future readers will find it in mere seconds and without
discouragement. Maybe it even helps search engines find it.
Ideally, someone else may add a mention of gitrepository-layout in the
"fatal: invalid gitfile format:" error message, which is what sent me
on my journey initially, or even add a stub man page named "gitfile".
Based on the maint branch for maximum compatibility.
Signed-off-by: Marcel Krause <mk+copyleft@pimpmybyte.de>
---
Documentation/gitrepository-layout.txt | 8 ++++----
Documentation/glossary-content.txt | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index 1a2ef4c150..c52b8564e3 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -23,10 +23,10 @@ A Git repository comes in two different flavours:
*Note*: Also you can have a plain text file `.git` at the root of
your working tree, containing `gitdir: <path>` to point at the real
-directory that has the repository. This mechanism is often used for
-a working tree of a submodule checkout, to allow you in the
-containing superproject to `git checkout` a branch that does not
-have the submodule. The `checkout` has to remove the entire
+directory that has the repository. This mechanism is called a 'gitfile'
+and is often used for a working tree of a submodule checkout, to allow
+you in the containing superproject to `git checkout` a branch that
+does not have the submodule. The `checkout` has to remove the entire
submodule working tree, without losing the submodule repository.
These things may exist in a Git repository.
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 5a537268e2..e5f55bf670 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -184,6 +184,7 @@ current branch integrates with) obviously do not work, as there is no
[[def_gitfile]]gitfile::
A plain file `.git` at the root of a working tree that
points at the directory that is the real repository.
+ See linkgit:gitrepository-layout for the syntax.
[[def_grafts]]grafts::
Grafts enables two otherwise different lines of development to be joined
--
2.25.1
^ permalink raw reply related
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