* [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
* Re: "git overlay" - command for overlaying branches
From: Michal Suchánek @ 2023-11-24 20:59 UTC (permalink / raw)
To: Oliver Bandel; +Cc: git
In-Reply-To: <n46dskd3hudzssaam56jesxr5elzdvs3asurqvbxkgsdcqitjs@qlufclnnjpsq>
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.
Unfortunately, git does not provide 'theirs' merge strategy while 'ours'
is provided - somewhat asymmetrical.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH 1/4] completion: squelch stray errors in sparse-checkout completion
From: Elijah Newren @ 2023-11-24 20:05 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Elijah Newren via GitGitGadget, git
In-Reply-To: <20231124183938.GB11157@szeder.dev>
On Fri, Nov 24, 2023 at 10:39 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
>
> On Thu, Nov 23, 2023 at 05:44:05PM +0000, Elijah Newren via GitGitGadget wrote:
> > 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.
> >
> > 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 ba5c395d2d8..6fced40d04c 100644
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -3014,7 +3014,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 2>/dev/null)
>
> It would be better to use the __git wrapper instead, like the wast
> majority of git invocations in our completion script, because it not
> only takes care of squelching standard error, but also takes into
> account any -C dir and/or --git-dir options present on the command
> line.
>
> e15098a314 (completion: consolidate silencing errors from git
> commands, 2017-02-03)
Ooh, nice! Thanks for the pointer, I was unaware. I'll make that change.
^ permalink raw reply
* Re: [PATCH 1/4] completion: squelch stray errors in sparse-checkout completion
From: SZEDER Gábor @ 2023-11-24 18:39 UTC (permalink / raw)
To: Elijah Newren via GitGitGadget; +Cc: git, Elijah Newren
In-Reply-To: <591c7b8d73b1a93feaa749d68156a198a7e32a9c.1700761448.git.gitgitgadget@gmail.com>
On Thu, Nov 23, 2023 at 05:44:05PM +0000, Elijah Newren via GitGitGadget wrote:
> 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.
>
> 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 ba5c395d2d8..6fced40d04c 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -3014,7 +3014,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 2>/dev/null)
It would be better to use the __git wrapper instead, like the wast
majority of git invocations in our completion script, because it not
only takes care of squelching standard error, but also takes into
account any -C dir and/or --git-dir options present on the command
line.
e15098a314 (completion: consolidate silencing errors from git
commands, 2017-02-03)
>
> if [[ $_found == 0 ]] && [[ "$cur" =~ /$ ]]; then
> # No possible further completions any deeper, so assume we're at
> --
> gitgitgadget
>
>
^ permalink raw reply
* Re: [PATCH] git-prompt: stop manually parsing HEAD
From: SZEDER Gábor @ 2023-11-24 18:28 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Patrick Steinhardt, git
In-Reply-To: <CAPig+cSa9zxEhKXtXHrVuB3Eb6=vnD1Ppnfj59rA+nPEO-9j-w@mail.gmail.com>
On Fri, Nov 24, 2023 at 01:09:03PM -0500, Eric Sunshine wrote:
> On Fri, Nov 24, 2023 at 6:37 AM Patrick Steinhardt <ps@pks.im> wrote:
> > We're manually parsing the HEAD reference in git-prompt to figure out
> > whether it is a symbolic or direct reference. This makes it intimately
> > tied to the on-disk format we use to store references and will stop
> > working once we gain additional reference backends in the Git project.
> >
> > Refactor the code to always use git-symbolic-ref(1) to read HEAD, which
> > is both simpler and compatible with alternate reference backends.
>
> This may get some push-back from Windows folks due to high
> process-creation cost on that platform. As I recall, over the years, a
> good deal of effort has been put into reducing the number of programs
> run each time the prompt is displayed, precisely because invoking Git
> (or other programs) multiple times became unbearably slow. In
> particular, optimizations efforts have focussed on computing as much
> as possible within the shell itself rather than invoking external
> programs for the same purpose. Thus, this seems to be taking a step
> backwards in that regard for the common or status quo case.
>
> Would it be possible instead to, within shell, detect if the historic
> file-based backend is being used in the current repository, thus
> continue using the existing shell code for that case, and only employ
> git-symbolic-ref if some other backend is in use?
Thanks for sharing my worries :)
I sent a patch a while ago to Han-Wen to make our Bash prompt script
work with the reftable backend without incurring the overhead of extra
subshells or processes when using the files based refs backend. He
picked it up and used to include it in rerolls of the reftable patch
series; the last version of that patch is I believe at:
https://public-inbox.org/git/patch-v4-21.28-443bdebfb5d-20210823T120208Z-avarab@gmail.com/
^ permalink raw reply
* Re: [PATCH] git-prompt: stop manually parsing HEAD
From: Eric Sunshine @ 2023-11-24 18:09 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <cc902954f30c2faa92d1c5a4469f0dcc23e4acfe.1700825779.git.ps@pks.im>
On Fri, Nov 24, 2023 at 6:37 AM Patrick Steinhardt <ps@pks.im> wrote:
> We're manually parsing the HEAD reference in git-prompt to figure out
> whether it is a symbolic or direct reference. This makes it intimately
> tied to the on-disk format we use to store references and will stop
> working once we gain additional reference backends in the Git project.
>
> Refactor the code to always use git-symbolic-ref(1) to read HEAD, which
> is both simpler and compatible with alternate reference backends.
This may get some push-back from Windows folks due to high
process-creation cost on that platform. As I recall, over the years, a
good deal of effort has been put into reducing the number of programs
run each time the prompt is displayed, precisely because invoking Git
(or other programs) multiple times became unbearably slow. In
particular, optimizations efforts have focussed on computing as much
as possible within the shell itself rather than invoking external
programs for the same purpose. Thus, this seems to be taking a step
backwards in that regard for the common or status quo case.
Would it be possible instead to, within shell, detect if the historic
file-based backend is being used in the current repository, thus
continue using the existing shell code for that case, and only employ
git-symbolic-ref if some other backend is in use?
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
^ permalink raw reply
* "git overlay" - command for overlaying branches
From: Oliver Bandel @ 2023-11-24 16:39 UTC (permalink / raw)
To: git
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'.
Assume there is a command 'git overlay' which overlays one branch on top of another branch,
so that the working dir contains files of both branches (with the overlayed on-top
having priority in hiding all the other files of same name in the working dir).
The files in the working dir are regarded as being members of the branches,
they are coming from initially (with the (last) overlayed branch as priority).
This, I guess, would solve the use case of the submodules/subtree problem.
Example:
Assuming only the files of the according branches are in the working dir.
branch_a has these files:
a1.txt
a2.txt
common.txt
branch_b has these files:
b1.txt
b2.txt
common.txt
branch_addons has these files:
addon_1.txt
addon_2.txt
CASE_1:
When sitting in 'branch_a' and typing 'git overlay branch_addons' I see these files:
a1.txt
a2.txt
common.txt
addon_1.txt
addon_2.txt
CASE_2:
Would I instead be sitting in 'branch_b' and typing 'git overlay branch_addons' I see these files:
b1.txt
b2.txt
common.txt
addon_1.txt
addon_2.txt
Changing files and then adding/committing them would apply add/commit on the branches,
where these files are comming from.
This means, in CASE_1, adding/committing changes of files from 'branch_a' would work on 'branch_a',
adding/committing changes of files from 'branch_addons' would work on 'branch_addons'.
In CASE_2, adding/committing changes of files from 'branch_b' would work on 'branch_b',
adding/committing changes of files from 'branch_addons' would work on 'branch_addons'.
If 'branch_addons' would also contain a file common.txt, then this file would be
residing in the working dir (hiding all other common.txt) and
changing/adding/committing it, would result in the 'branch_addons' common.txt
being changed.
A 'git unoverlay' or 'git unoverlay branch_addons' or 'git overlay --rm'
or 'git overlay --off' would disable the overlay, which means only the main branch
(here 'branch_a' or 'branch_b') would be checked out.
A switch of the branch (checkout/switch) might automatically un-overlay all of
the overlayed branches, or might be forbidden until an explicit un-overlay
would be done. (maybe configurable behaviour)
I assume that more than one overlay would be possible.
Of course the order of applying the overlays determenines, what branches the
files in the working dir are associated with (and checked out from).
Other use cases of course could use programming files.
The main branch might contain some interface files (*.h, *.mli, ...)
and the overlays the implementation (*.c, *.ml, ...).
Then switching the implementation for the same interface
(assuming no interface files are in the overlay-branches)
would just be one git command.
Additionally it would be good to have an easy way to move a file from one branch to another
branch (for example from one of the main branches to an overlay or vice versa).
If common.txt in the above example does not differ between 'branch_a' and
'branch_b', it might make sense to move it to maybe a branch 'branch_common', which
might be used as overlay as well (or as a base branch instead, making branhc_a and 'branch_b'
possible candidates for being overlayed).
I suggest considering such an overlay feature for git in the future.
If there are problems lurking in the background here
(for example when considering merges, rebasing and such stuff),
or if anything would fit in nicely, I can't see right now.
Ciao,
Oliver
P.S.:
Instead of "overlay" I first had in mind "mount" and "unmount" as name,
but the name "overlay" is better choice, even though "unoverlay" is somewhat intricate.
^ permalink raw reply
* Re: [PATCH v3 0/4] Switch links to https
From: Josh Soref @ 2023-11-24 16:03 UTC (permalink / raw)
To: Elijah Newren; +Cc: Josh Soref via GitGitGadget, git, Eric Sunshine
In-Reply-To: <CABPp-BGhHivx9_R6fwL--K5nTvz1sh67JDMtWG7WajxmX=56Fg@mail.gmail.com>
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 :).
^ permalink raw reply
* Re: Running git(1) from within hooks/post-update
From: Alejandro Colomar @ 2023-11-24 15:49 UTC (permalink / raw)
To: git
In-Reply-To: <ZWDEWDTtiFYAYp2P@debian>
[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]
On Fri, Nov 24, 2023 at 04:42:16PM +0100, Alejandro Colomar wrote:
> On Fri, Nov 24, 2023 at 03:00:22PM +0100, Alejandro Colomar wrote:
> > Hi,
> >
> > I'm trying to set up a post-update hook to produce a build of the Linux
> > man-pages PDF book after every push to my personal server to the 'main'
> > branch, so that I can serve man-pages-HEAD.pdf at some URL, for users to
> > be able to easily check the manual at git HEAD without having to clone
> > the repo.
> >
> > I thought of having a git non-bare repo where I build it, so the script
> > would be the following (the paths are tmp, because I'm still testing).
> >
> > $ cat post-update
> > #!/bin/sh
> >
> > test "$1" = "refs/heads/main" || exit 0;
> >
> > cd ~/tmp/man-pages/;
> >
> > whoami; pwd; ls -ld .git/; # This is for debugging.
> >
> > git fetch srv #>/dev/null 2>&1;
> > git reset srv/main --hard #>/dev/null 2>&1;
> > git clean -dffx #>/dev/null 2>&1;
> > scripts/LinuxManBook/build.sh >~/tmp/LMB-HEAD.pdf &
>
> The script works fine when called manually. It seems it's calling it
> as a hook that fails. It seems it's running git(1) from within a
> post-update hook that is problematic. Is that expected, or is it a bug,
> and can it be fixed?
Ahh, after this I've found it documented in githooks(5):
Environment variables, such as GIT_DIR, GIT_WORK_TREE, etc., are
exported so that Git commands run by the hook can correctly
locate the repository. If your hook needs to invoke Git commands
in a foreign repository or in a different working tree of the
same repository, then it should clear these environment variables
so they do not interfere with Git operations at the foreign
location. For example:
local_desc=$(git describe)
foreign_desc=$(unset $(git rev-parse --local-env-vars); git -C ../foreign-repo describe)
Never mind.
Thanks,
Alex
>
> >
> > But it's not working. The git(1) calls are failing, saying it's not a
> > git repo, but it clearly is, and I have permissions, so I don't
> > understand what's going wrong. Here's the 'remote:' output of a push to
> > that testing server:
> >
> > remote: alx
> > remote: /home/alx/tmp/man-pages
> > remote: drwxr-xr-x 8 alx alx 4096 Nov 24 14:41 .git/
> > remote: fatal: not a git repository: '.'
> > remote: fatal: not a git repository: '.'
> > remote: fatal: not a git repository: '.'
> > remote: hooks/post-update: 12: ./scripts/LinuxManBook/build.sh: not found
> >
> > Can you please help? :)
> >
> > Thanks,
> > Alex
> >
> > --
> > <https://www.alejandro-colomar.es/>
>
>
>
> --
> <https://www.alejandro-colomar.es/>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Running git(1) from within hooks/post-update
From: Alejandro Colomar @ 2023-11-24 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <ZWCsd3cJZ3LAqOwg@debian>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
On Fri, Nov 24, 2023 at 03:00:22PM +0100, Alejandro Colomar wrote:
> Hi,
>
> I'm trying to set up a post-update hook to produce a build of the Linux
> man-pages PDF book after every push to my personal server to the 'main'
> branch, so that I can serve man-pages-HEAD.pdf at some URL, for users to
> be able to easily check the manual at git HEAD without having to clone
> the repo.
>
> I thought of having a git non-bare repo where I build it, so the script
> would be the following (the paths are tmp, because I'm still testing).
>
> $ cat post-update
> #!/bin/sh
>
> test "$1" = "refs/heads/main" || exit 0;
>
> cd ~/tmp/man-pages/;
>
> whoami; pwd; ls -ld .git/; # This is for debugging.
>
> git fetch srv #>/dev/null 2>&1;
> git reset srv/main --hard #>/dev/null 2>&1;
> git clean -dffx #>/dev/null 2>&1;
> scripts/LinuxManBook/build.sh >~/tmp/LMB-HEAD.pdf &
The script works fine when called manually. It seems it's calling it
as a hook that fails. It seems it's running git(1) from within a
post-update hook that is problematic. Is that expected, or is it a bug,
and can it be fixed?
>
> But it's not working. The git(1) calls are failing, saying it's not a
> git repo, but it clearly is, and I have permissions, so I don't
> understand what's going wrong. Here's the 'remote:' output of a push to
> that testing server:
>
> remote: alx
> remote: /home/alx/tmp/man-pages
> remote: drwxr-xr-x 8 alx alx 4096 Nov 24 14:41 .git/
> remote: fatal: not a git repository: '.'
> remote: fatal: not a git repository: '.'
> remote: fatal: not a git repository: '.'
> remote: hooks/post-update: 12: ./scripts/LinuxManBook/build.sh: not found
>
> Can you please help? :)
>
> Thanks,
> Alex
>
> --
> <https://www.alejandro-colomar.es/>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/4] Switch links to https
From: Elijah Newren @ 2023-11-24 15:36 UTC (permalink / raw)
To: Josh Soref via GitGitGadget; +Cc: git, Eric Sunshine, Josh Soref
In-Reply-To: <pull.1589.v3.git.1700796916.gitgitgadget@gmail.com>
On Thu, Nov 23, 2023 at 7:35 PM Josh Soref via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> There are a couple of categories of http links...
>
> There are four categories worth changing:
>
> * pages that have jittered a bit but are now available as https:
> * pages which exist at both http: and https: and can be safely switched
> * pages that have jittered a bit and are not available over https:
> * pages that are gone and for which the best source is
> https://web.archive.org
>
> And some categories that aren't being changed:
>
> * links that are required to be http: because they're copied from something
> that mandates it (the apache license, xml namespaces, xsl docbook
> things?)
> * urls that were imaginary (e.g. http://example.com/repo.git)
> * links in borrowed code where the http: form still works
>
> In order:
>
> * doc: update links to current pages -- I found the current pages for
> these, it should be easy enough to verify these / reject them
> * doc: switch links to https -- the simplest
> * doc: update links for andre-simon.de -- I've split this out, I don't like
> the idea of having to download binaries over http. If this were my
> project, I'd be tempted to remove the feature or self-host w/ https...
> * doc: refer to internet archive -- the original urls are dead, I've found
> internet archive date links for them. (There are some in git already, so
> this seemed like a very reasonable choice.)
>
> Changes from v1:
>
> * Commit messages have been adjusted since v1
> * files were dropped based on feedback from Junio
>
> Changes from v2:
>
> * The first two commits have been swapped (favoring more complicated urls
> over simply switching to https)
> * The archive.org link for atomenabled.org has been dropped, we'll risk
> users getting hacked content from an arbitrary MITM instead of taking
> archived authenticated content based on the last time their web site was
> properly maintained.
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.
Anyway, I checked through every link in this series; it all looks good to me.
^ 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