* [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
* Re: [PATCH v2 1/4] doc: switch links to https
From: Elijah Newren @ 2023-11-24 15:33 UTC (permalink / raw)
To: Josh Soref; +Cc: Josh Soref via GitGitGadget, git
In-Reply-To: <CACZqfqD-M3NAb3=Y-StWfAk50r-XPkFRRLLJPe9RUek21+Lnsg@mail.gmail.com>
On Thu, Nov 23, 2023 at 7:13 PM Josh Soref <jsoref@gmail.com> wrote:
>
> > > -See http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code,
> > > +See https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code,
> > > browsed using gitweb itself.
> >
> > The suggested link gives a "404 - No such tree". Granted, the http:
> > link also does that, but it'd be nicer to provide a non-broken link,
> > which you can do by stripping the '/[]' from the end of the URL.
>
> The `[]` is part of AsciiDoc's [1] notation. I tripped on this when I
> first looked into
> this series (as I'm much more familiar w/ Markdown and Restructured Text).
Ah, thanks for the explanation.
>
> [1] https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/
^ permalink raw reply
* Re: [PATCH v2 4/4] doc: refer to internet archive
From: Elijah Newren @ 2023-11-24 15:32 UTC (permalink / raw)
To: Josh Soref; +Cc: Josh Soref via GitGitGadget, git
In-Reply-To: <CACZqfqCksg=uMh=URh-0KEoPA9cvjgDAKPhn+0WZti-y2A540Q@mail.gmail.com>
On Thu, Nov 23, 2023 at 7:24 PM Josh Soref <jsoref@gmail.com> wrote:
>
> Elijah Newren wrote:
> > Thanks, these all look good, except on of the old links works for me.
> > Maybe it was just down the day you checked?
>
> > More comments on that below...
>
> > > - # Atom: http://www.atomenabled.org/developers/syndication/
> > > - # RSS: http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
> > > + # Atom: https://web.archive.org/web/20230815171113/https://www.atomenabled.org/developers/syndication/
> > > + # RSS: https://web.archive.org/web/20030729001534/http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
> >
> > The original www.atomenabled.org link works for me.
>
> That's odd. As you can see based on my archive.org link, at some point
> they had `https` support (their certificate expired Feb 7, 2021 UTC).
>
> Personally, as a former web browser developer, I'd rather people rely
> on archived authenticated content than content that could be rewritten
> in transit.
I think that'd be perfectly reasonable, I was just thrown because the
justification was that the links no longer worked. Mentioning why the
changes are being made in the commit message, and in particular that
there are two reasons for the changes, would have been sufficient.
> That said, I'm going to drop this change.
Your call.
^ permalink raw reply
* Re: [PATCH 4/4] completion: avoid user confusion in non-cone mode
From: Elijah Newren @ 2023-11-24 15:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Elijah Newren via GitGitGadget, git
In-Reply-To: <xmqqo7fk9cdt.fsf@gitster.g>
On Thu, Nov 23, 2023 at 5:19 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > if [[ "$using_cone" == "true" ]]; then
> > __gitcomp_directories
>
> Hmph, doesn't "Providing the files and directories currently present
> is thus always wrong." apply equally to cone mode?
Absolutely, it definitely applies to cone mode. We (mostly) fixed
that a long time ago, making it not complete on the files &
directories currently present. In particular, the
__gitcomp_directories() function highlighted here completes on the
output of `git ls-tree -z -d --name-only HEAD`.
However, before this series, there was a problem when
__gitcomp_directories() finds no possible completions. In that case,
the code would fall back to bash-completion's default of completing on
all files and directories currently present. But that was fixed in
patch 3 of this series to avoid that fallback.
This patch, though, isn't about cone mode. It's about fixing (or at
least improving) non-cone mode.
> > + else
> > + # NEEDSWORK: It might be useful to provide a
> > + # completion function which:
> > + #
> > + # 1. Provides completions based on
> > + # files/directories that exist in HEAD, not
> > + # just those currently present in the working
> > + # tree.
>
> This makes a lot of sense. May make even more sense with
> s/HEAD/index/, though.
Ooh, interesting. That wouldn't work with the sparse index (where
paths we want to complete on are currently missing from the index
too), but sparse index is restricted to cone mode, and we're
discussing non-cone-mode here. So, this might be a basis for a good
alternative.
> > + # 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.)
>
> Hmph, would an obvious alternative to (1) check against the HEAD (or
> the index) to see if the prefix string matches an entity at the
> current directory level, and then (2) to prefix the result of the
> previous step with "/$(git rev-parse --show-prefix)" work? That is
> something like this:
>
> $ cd t
> $ git sparse-checkout add help<TAB>
> ->
> $ git sparse-checkout add /t/helper/
I thought bash-completion was only for completions, not for startings
as well. Was I mistaken?
> and when the user gave the full path from the root level, do the
> obvious:
>
> $ cd t
> $ git sparse-checkout add /t/help<TAB>
> ->
> $ git sparse-checkout add /t/helper/
>
> Another more fundamental approach to avoid "confusion" this bullet
> item tries to side step might be to *fix* the command that gets
> completed. As "git sparse-checkout --help" is marked as
> EXPERIMENTAL in capital letters, we should be able to say "what was
> traditionally known as 'add' is from now on called 'add-pattern' and
> command line completion would not get in the way; the 'add'
> subcommand now takes only literal paths, not patterns, that are
> relative to the current directory" if we wanted to.
That's interesting...but it opens up a new can of worms:
* Would we also need both `set-patterns` and `set`, in addition to
`add-patterns` and `add`?
* In cone mode, the paths passed are literal directories (and only
directories; no individual files), but the thing added is a
telescoping "cone" of leading directories as well. Does this make it
potentially confusing to users to say that `add` only takes literal
paths?
* In cone mode (the default), should `add-patterns` just be an
error, since no pattern specification is allowed?
* In the git-sparse-checkout manual, for performance reasons, we
recommend users _not_ specify individual paths in non-cone mode.
Would our recommendation then be to just not use `add` or `set` and
only use `add-patterns` and `set-patterns`? If so, what have we
accomplished by adding the new names?
Maybe I'm missing something about your suggestion, but this seems much
more complex than the simple solution we implemented in bb8b5e9a90d
("sparse-checkout: pay attention to prefix for {set, add}",
2022-02-19) for the !core_sparse_checkout_cone case. I like the
simple solution there, though that simple solution omitted modifying
the completion rules in a way that was consistent (i.e. that returns
nothing when the user is running from a subdirectory).
> > + # 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
> > }
^ permalink raw reply
* Re: Unable to split then edit hunk in git interactive add
From: Phillip Wood @ 2023-11-24 15:19 UTC (permalink / raw)
To: scarf, git
In-Reply-To: <8d7c8313-0f02-4218-ba2a-1716ada7956f@gmail.com>
On 24/11/2023 08:16, scarf wrote:
> |Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
Thanks for taking the time to report this. While it is a known
limitation of "git add -p" that editing a hunk after splitting it can
cause problems (see below) I am unable to reproduce this particular bug.
When a hunk is split the resulting hunks share the context lines around
the split. The trailing context lines of the first hunk are the same
lines as the leading context of the second hunk. If the shared context
is edited then the lines no-longer match between the hunks which means
they cannot be applied. In general it is better to avoid splitting a
hunk if you plan to edit it.
Best Wishes
Phillip
^ permalink raw reply
* Running git(1) from within hooks/post-update
From: Alejandro Colomar @ 2023-11-24 14:00 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]
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 &
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/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] git-prompt: stop manually parsing HEAD
From: Patrick Steinhardt @ 2023-11-24 11:37 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]
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.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
contrib/completion/git-prompt.sh | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 2c030050ae..05de540e13 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -474,17 +474,10 @@ __git_ps1 ()
if [ -n "$b" ]; then
:
- elif [ -h "$g/HEAD" ]; then
- # symlink symbolic ref
- b="$(git symbolic-ref HEAD 2>/dev/null)"
else
- local head=""
- if ! __git_eread "$g/HEAD" head; then
- return $exit
- fi
- # is it a symbolic ref?
- b="${head#ref: }"
- if [ "$head" = "$b" ]; then
+ b="$(git symbolic-ref HEAD 2>/dev/null)"
+
+ if test -z "$b"; then
detached=yes
b="$(
case "${GIT_PS1_DESCRIBE_STYLE-}" in
@@ -498,9 +491,14 @@ __git_ps1 ()
git describe HEAD ;;
(* | default)
git describe --tags --exact-match HEAD ;;
- esac 2>/dev/null)" ||
+ esac 2>/dev/null)"
+
+ if test -z "$b"; then
+ test -z "$short_sha" && return $exit
+
+ b="$short_sha..."
+ fi
- b="$short_sha..."
b="($b)"
fi
fi
--
2.43.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH v8 14/14] replay: stop assuming replayed branches do not diverge
From: Christian Couder @ 2023-11-24 11:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
Elijah Newren, John Cai, Derrick Stolee, Phillip Wood, Calvin Wan,
Toon Claes, Dragan Simic, Linus Arver, Christian Couder
In-Reply-To: <20231124111044.3426007-1-christian.couder@gmail.com>
From: Elijah Newren <newren@gmail.com>
The replay command is able to replay multiple branches but when some of
them are based on other replayed branches, their commit should be
replayed onto already replayed commits.
For this purpose, let's store the replayed commit and its original
commit in a key value store, so that we can easily find and reuse a
replayed commit instead of the original one.
Co-authored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin/replay.c | 44 ++++++++++++++++++++++++++--------
t/t3650-replay-basics.sh | 52 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 86 insertions(+), 10 deletions(-)
diff --git a/builtin/replay.c b/builtin/replay.c
index df14657e2f..6bc4b47f09 100644
--- a/builtin/replay.c
+++ b/builtin/replay.c
@@ -223,20 +223,33 @@ static void determine_replay_mode(struct rev_cmdline_info *cmd_info,
strset_clear(&rinfo.positive_refs);
}
+static struct commit *mapped_commit(kh_oid_map_t *replayed_commits,
+ struct commit *commit,
+ struct commit *fallback)
+{
+ khint_t pos = kh_get_oid_map(replayed_commits, commit->object.oid);
+ if (pos == kh_end(replayed_commits))
+ return fallback;
+ return kh_value(replayed_commits, pos);
+}
+
static struct commit *pick_regular_commit(struct commit *pickme,
- struct commit *last_commit,
+ kh_oid_map_t *replayed_commits,
+ struct commit *onto,
struct merge_options *merge_opt,
struct merge_result *result)
{
- struct commit *base;
+ struct commit *base, *replayed_base;
struct tree *pickme_tree, *base_tree;
base = pickme->parents->item;
+ replayed_base = mapped_commit(replayed_commits, base, onto);
+ result->tree = repo_get_commit_tree(the_repository, replayed_base);
pickme_tree = repo_get_commit_tree(the_repository, pickme);
base_tree = repo_get_commit_tree(the_repository, base);
- merge_opt->branch1 = short_commit_name(last_commit);
+ merge_opt->branch1 = short_commit_name(replayed_base);
merge_opt->branch2 = short_commit_name(pickme);
merge_opt->ancestor = xstrfmt("parent of %s", merge_opt->branch2);
@@ -250,7 +263,7 @@ static struct commit *pick_regular_commit(struct commit *pickme,
merge_opt->ancestor = NULL;
if (!result->clean)
return NULL;
- return create_commit(result->tree, pickme, last_commit);
+ return create_commit(result->tree, pickme, replayed_base);
}
int cmd_replay(int argc, const char **argv, const char *prefix)
@@ -266,6 +279,7 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
struct merge_options merge_opt;
struct merge_result result;
struct strset *update_refs = NULL;
+ kh_oid_map_t *replayed_commits;
int ret = 0;
const char * const replay_usage[] = {
@@ -363,21 +377,30 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
init_merge_options(&merge_opt, the_repository);
memset(&result, 0, sizeof(result));
merge_opt.show_rename_progress = 0;
-
- result.tree = repo_get_commit_tree(the_repository, onto);
last_commit = onto;
+ replayed_commits = kh_init_oid_map();
while ((commit = get_revision(&revs))) {
const struct name_decoration *decoration;
+ khint_t pos;
+ int hr;
if (!commit->parents)
die(_("replaying down to root commit is not supported yet!"));
if (commit->parents->next)
die(_("replaying merge commits is not supported yet!"));
- last_commit = pick_regular_commit(commit, last_commit, &merge_opt, &result);
+ last_commit = pick_regular_commit(commit, replayed_commits, onto,
+ &merge_opt, &result);
if (!last_commit)
break;
+ /* Record commit -> last_commit mapping */
+ pos = kh_put_oid_map(replayed_commits, commit->object.oid, &hr);
+ if (hr == 0)
+ BUG("Duplicate rewritten commit: %s\n",
+ oid_to_hex(&commit->object.oid));
+ kh_value(replayed_commits, pos) = last_commit;
+
/* Update any necessary branches */
if (advance_name)
continue;
@@ -406,13 +429,14 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
}
merge_finalize(&merge_opt, &result);
- ret = result.clean;
-
-cleanup:
+ kh_destroy_oid_map(replayed_commits);
if (update_refs) {
strset_clear(update_refs);
free(update_refs);
}
+ ret = result.clean;
+
+cleanup:
release_revisions(&revs);
/* Return */
diff --git a/t/t3650-replay-basics.sh b/t/t3650-replay-basics.sh
index d6286f9580..389670262e 100755
--- a/t/t3650-replay-basics.sh
+++ b/t/t3650-replay-basics.sh
@@ -143,4 +143,56 @@ test_expect_success 'using replay on bare repo to also rebase a contained branch
test_cmp expect result-bare
'
+test_expect_success 'using replay to rebase multiple divergent branches' '
+ git replay --onto main ^topic1 topic2 topic4 >result &&
+
+ test_line_count = 2 result &&
+ cut -f 3 -d " " result >new-branch-tips &&
+
+ git log --format=%s $(head -n 1 new-branch-tips) >actual &&
+ test_write_lines E D M L B A >expect &&
+ test_cmp expect actual &&
+
+ git log --format=%s $(tail -n 1 new-branch-tips) >actual &&
+ test_write_lines J I M L B A >expect &&
+ test_cmp expect actual &&
+
+ printf "update refs/heads/topic2 " >expect &&
+ printf "%s " $(head -n 1 new-branch-tips) >>expect &&
+ git rev-parse topic2 >>expect &&
+ printf "update refs/heads/topic4 " >>expect &&
+ printf "%s " $(tail -n 1 new-branch-tips) >>expect &&
+ git rev-parse topic4 >>expect &&
+
+ test_cmp expect result
+'
+
+test_expect_success 'using replay on bare repo to rebase multiple divergent branches, including contained ones' '
+ git -C bare replay --contained --onto main ^main topic2 topic3 topic4 >result &&
+
+ test_line_count = 4 result &&
+ cut -f 3 -d " " result >new-branch-tips &&
+
+ >expect &&
+ for i in 2 1 3 4
+ do
+ printf "update refs/heads/topic$i " >>expect &&
+ printf "%s " $(grep topic$i result | cut -f 3 -d " ") >>expect &&
+ git -C bare rev-parse topic$i >>expect || return 1
+ done &&
+
+ test_cmp expect result &&
+
+ test_write_lines F C M L B A >expect1 &&
+ test_write_lines E D C M L B A >expect2 &&
+ test_write_lines H G F C M L B A >expect3 &&
+ test_write_lines J I M L B A >expect4 &&
+
+ for i in 1 2 3 4
+ do
+ git -C bare log --format=%s $(grep topic$i result | cut -f 3 -d " ") >actual &&
+ test_cmp expect$i actual || return 1
+ done
+'
+
test_done
--
2.43.0.14.g93e034faee
^ permalink raw reply related
* [PATCH v8 13/14] replay: add --contained to rebase contained branches
From: Christian Couder @ 2023-11-24 11:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
Elijah Newren, John Cai, Derrick Stolee, Phillip Wood, Calvin Wan,
Toon Claes, Dragan Simic, Linus Arver, Christian Couder
In-Reply-To: <20231124111044.3426007-1-christian.couder@gmail.com>
From: Elijah Newren <newren@gmail.com>
Let's add a `--contained` option that can be used along with
`--onto` to rebase all the branches contained in the <revision-range>
argument.
Co-authored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replay.txt | 12 +++++++++++-
builtin/replay.c | 14 ++++++++++++--
t/t3650-replay-basics.sh | 29 +++++++++++++++++++++++++++++
3 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-replay.txt b/Documentation/git-replay.txt
index c4c64f955a..f6c269c62d 100644
--- a/Documentation/git-replay.txt
+++ b/Documentation/git-replay.txt
@@ -9,7 +9,7 @@ git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos t
SYNOPSIS
--------
[verse]
-(EXPERIMENTAL!) 'git replay' (--onto <newbase> | --advance <branch>) <revision-range>...
+(EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>...
DESCRIPTION
-----------
@@ -96,6 +96,16 @@ top of the exact same new base, they only differ in that the first
provides instructions to make mybranch point at the new commits and
the second provides instructions to make target point at them.
+What if you have a stack of branches, one depending upon another, and
+you'd really like to rebase the whole set?
+
+------------
+$ git replay --contained --onto origin/main origin/main..tipbranch
+update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
+update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
+update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH}
+------------
+
When calling `git replay`, one does not need to specify a range of
commits to replay using the syntax `A..B`; any range expression will
do:
diff --git a/builtin/replay.c b/builtin/replay.c
index f26806d7e2..df14657e2f 100644
--- a/builtin/replay.c
+++ b/builtin/replay.c
@@ -258,6 +258,7 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
const char *advance_name = NULL;
struct commit *onto = NULL;
const char *onto_name = NULL;
+ int contained = 0;
struct rev_info revs;
struct commit *last_commit = NULL;
@@ -268,7 +269,9 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
int ret = 0;
const char * const replay_usage[] = {
- 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[] = {
@@ -278,6 +281,8 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
OPT_STRING(0, "onto", &onto_name,
N_("revision"),
N_("replay onto given commit")),
+ OPT_BOOL(0, "contained", &contained,
+ N_("advance all branches contained in revision-range")),
OPT_END()
};
@@ -289,6 +294,10 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
usage_with_options(replay_usage, replay_options);
}
+ if (advance_name && contained)
+ die(_("options '%s' and '%s' cannot be used together"),
+ "--advance", "--contained");
+
repo_init_revisions(the_repository, &revs, prefix);
/*
@@ -377,7 +386,8 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
continue;
while (decoration) {
if (decoration->type == DECORATION_REF_LOCAL &&
- strset_contains(update_refs, decoration->name)) {
+ (contained || strset_contains(update_refs,
+ decoration->name))) {
printf("update %s %s %s\n",
decoration->name,
oid_to_hex(&last_commit->object.oid),
diff --git a/t/t3650-replay-basics.sh b/t/t3650-replay-basics.sh
index 68a87e7803..d6286f9580 100755
--- a/t/t3650-replay-basics.sh
+++ b/t/t3650-replay-basics.sh
@@ -114,4 +114,33 @@ test_expect_success 'replay fails when both --advance and --onto are omitted' '
test_must_fail git replay topic1..topic2 >result
'
+test_expect_success 'using replay to also rebase a contained branch' '
+ git replay --contained --onto main main..topic3 >result &&
+
+ test_line_count = 2 result &&
+ cut -f 3 -d " " result >new-branch-tips &&
+
+ git log --format=%s $(head -n 1 new-branch-tips) >actual &&
+ test_write_lines F C M L B A >expect &&
+ test_cmp expect actual &&
+
+ git log --format=%s $(tail -n 1 new-branch-tips) >actual &&
+ test_write_lines H G F C M L B A >expect &&
+ test_cmp expect actual &&
+
+ printf "update refs/heads/topic1 " >expect &&
+ printf "%s " $(head -n 1 new-branch-tips) >>expect &&
+ git rev-parse topic1 >>expect &&
+ printf "update refs/heads/topic3 " >>expect &&
+ printf "%s " $(tail -n 1 new-branch-tips) >>expect &&
+ git rev-parse topic3 >>expect &&
+
+ test_cmp expect result
+'
+
+test_expect_success 'using replay on bare repo to also rebase a contained branch' '
+ git -C bare replay --contained --onto main main..topic3 >result-bare &&
+ test_cmp expect result-bare
+'
+
test_done
--
2.43.0.14.g93e034faee
^ permalink raw reply related
* [PATCH v8 12/14] replay: add --advance or 'cherry-pick' mode
From: Christian Couder @ 2023-11-24 11:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
Elijah Newren, John Cai, Derrick Stolee, Phillip Wood, Calvin Wan,
Toon Claes, Dragan Simic, Linus Arver, Christian Couder
In-Reply-To: <20231124111044.3426007-1-christian.couder@gmail.com>
From: Elijah Newren <newren@gmail.com>
There is already a 'rebase' mode with `--onto`. Let's add an 'advance' or
'cherry-pick' mode with `--advance`. This new mode will make the target
branch advance as we replay commits onto it.
The replayed commits should have a single tip, so that it's clear where
the target branch should be advanced. If they have more than one tip,
this new mode will error out.
Co-authored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replay.txt | 41 ++++++--
builtin/replay.c | 185 +++++++++++++++++++++++++++++++++--
t/t3650-replay-basics.sh | 34 +++++++
3 files changed, 243 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-replay.txt b/Documentation/git-replay.txt
index f7b232caa2..c4c64f955a 100644
--- a/Documentation/git-replay.txt
+++ b/Documentation/git-replay.txt
@@ -9,7 +9,7 @@ git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos t
SYNOPSIS
--------
[verse]
-(EXPERIMENTAL!) 'git replay' --onto <newbase> <revision-range>...
+(EXPERIMENTAL!) 'git replay' (--onto <newbase> | --advance <branch>) <revision-range>...
DESCRIPTION
-----------
@@ -29,14 +29,25 @@ OPTIONS
Starting point at which to create the new commits. May be any
valid commit, and not just an existing branch name.
+
-The update-ref command(s) in the output will update the branch(es) in
-the revision range to point at the new commits, similar to the way how
-`git rebase --update-refs` updates multiple branches in the affected
-range.
+When `--onto` is specified, the update-ref command(s) in the output will
+update the branch(es) in the revision range to point at the new
+commits, similar to the way how `git rebase --update-refs` updates
+multiple branches in the affected range.
+
+--advance <branch>::
+ Starting point at which to create the new commits; must be a
+ branch name.
++
+When `--advance` is specified, the update-ref command(s) in the output
+will update the branch passed as an argument to `--advance` to point at
+the new commits (in other words, this mimics a cherry-pick operation).
<revision-range>::
- Range of commits to replay; see "Specifying Ranges" in
- linkgit:git-rev-parse and the "Commit Limiting" options below.
+ Range of commits to replay. More than one <revision-range> can
+ be passed, but in `--advance <branch>` mode, they should have
+ a single tip, so that it's clear where <branch> should point
+ to. See "Specifying Ranges" in linkgit:git-rev-parse and the
+ "Commit Limiting" options below.
include::rev-list-options.txt[]
@@ -51,7 +62,9 @@ input to `git update-ref --stdin`. It is of the form:
update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}
where the number of refs updated depends on the arguments passed and
-the shape of the history being replayed.
+the shape of the history being replayed. When using `--advance`, the
+number of refs updated is always one, but for `--onto`, it can be one
+or more (rebasing multiple branches simultaneously is supported).
EXIT STATUS
-----------
@@ -71,6 +84,18 @@ $ git replay --onto target origin/main..mybranch
update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH}
------------
+To cherry-pick the commits from mybranch onto target:
+
+------------
+$ git replay --advance target origin/main..mybranch
+update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH}
+------------
+
+Note that the first two examples replay the exact same commits and on
+top of the exact same new base, they only differ in that the first
+provides instructions to make mybranch point at the new commits and
+the second provides instructions to make target point at them.
+
When calling `git replay`, one does not need to specify a range of
commits to replay using the syntax `A..B`; any range expression will
do:
diff --git a/builtin/replay.c b/builtin/replay.c
index 3d5e00147b..f26806d7e2 100644
--- a/builtin/replay.c
+++ b/builtin/replay.c
@@ -14,6 +14,7 @@
#include "parse-options.h"
#include "refs.h"
#include "revision.h"
+#include "strmap.h"
#include <oidset.h>
#include <tree.h>
@@ -82,6 +83,146 @@ static struct commit *create_commit(struct tree *tree,
return (struct commit *)obj;
}
+struct ref_info {
+ struct commit *onto;
+ struct strset positive_refs;
+ struct strset negative_refs;
+ int positive_refexprs;
+ int negative_refexprs;
+};
+
+static void get_ref_information(struct rev_cmdline_info *cmd_info,
+ struct ref_info *ref_info)
+{
+ int i;
+
+ ref_info->onto = NULL;
+ strset_init(&ref_info->positive_refs);
+ strset_init(&ref_info->negative_refs);
+ ref_info->positive_refexprs = 0;
+ ref_info->negative_refexprs = 0;
+
+ /*
+ * When the user specifies e.g.
+ * git replay origin/main..mybranch
+ * git replay ^origin/next mybranch1 mybranch2
+ * we want to be able to determine where to replay the commits. In
+ * these examples, the branches are probably based on an old version
+ * of either origin/main or origin/next, so we want to replay on the
+ * newest version of that branch. In contrast we would want to error
+ * out if they ran
+ * git replay ^origin/master ^origin/next mybranch
+ * git replay mybranch~2..mybranch
+ * the first of those because there's no unique base to choose, and
+ * the second because they'd likely just be replaying commits on top
+ * of the same commit and not making any difference.
+ */
+ for (i = 0; i < cmd_info->nr; i++) {
+ struct rev_cmdline_entry *e = cmd_info->rev + i;
+ struct object_id oid;
+ const char *refexpr = e->name;
+ char *fullname = NULL;
+ int can_uniquely_dwim = 1;
+
+ if (*refexpr == '^')
+ refexpr++;
+ if (repo_dwim_ref(the_repository, refexpr, strlen(refexpr), &oid, &fullname, 0) != 1)
+ can_uniquely_dwim = 0;
+
+ if (e->flags & BOTTOM) {
+ if (can_uniquely_dwim)
+ strset_add(&ref_info->negative_refs, fullname);
+ if (!ref_info->negative_refexprs)
+ ref_info->onto = lookup_commit_reference_gently(the_repository,
+ &e->item->oid, 1);
+ ref_info->negative_refexprs++;
+ } else {
+ if (can_uniquely_dwim)
+ strset_add(&ref_info->positive_refs, fullname);
+ ref_info->positive_refexprs++;
+ }
+
+ free(fullname);
+ }
+}
+
+static void determine_replay_mode(struct rev_cmdline_info *cmd_info,
+ const char *onto_name,
+ const char **advance_name,
+ struct commit **onto,
+ struct strset **update_refs)
+{
+ struct ref_info rinfo;
+
+ get_ref_information(cmd_info, &rinfo);
+ if (!rinfo.positive_refexprs)
+ die(_("need some commits to replay"));
+ if (onto_name && *advance_name)
+ die(_("--onto and --advance are incompatible"));
+ else if (onto_name) {
+ *onto = peel_committish(onto_name);
+ if (rinfo.positive_refexprs <
+ strset_get_size(&rinfo.positive_refs))
+ die(_("all positive revisions given must be references"));
+ } else if (*advance_name) {
+ struct object_id oid;
+ char *fullname = NULL;
+
+ *onto = peel_committish(*advance_name);
+ if (repo_dwim_ref(the_repository, *advance_name, strlen(*advance_name),
+ &oid, &fullname, 0) == 1) {
+ *advance_name = fullname;
+ } else {
+ die(_("argument to --advance must be a reference"));
+ }
+ if (rinfo.positive_refexprs > 1)
+ die(_("cannot advance target with multiple sources because ordering would be ill-defined"));
+ } else {
+ int positive_refs_complete = (
+ rinfo.positive_refexprs ==
+ strset_get_size(&rinfo.positive_refs));
+ int negative_refs_complete = (
+ rinfo.negative_refexprs ==
+ strset_get_size(&rinfo.negative_refs));
+ /*
+ * We need either positive_refs_complete or
+ * negative_refs_complete, but not both.
+ */
+ if (rinfo.negative_refexprs > 0 &&
+ positive_refs_complete == negative_refs_complete)
+ die(_("cannot implicitly determine whether this is an --advance or --onto operation"));
+ if (negative_refs_complete) {
+ struct hashmap_iter iter;
+ struct strmap_entry *entry;
+
+ if (rinfo.negative_refexprs == 0)
+ die(_("all positive revisions given must be references"));
+ else if (rinfo.negative_refexprs > 1)
+ die(_("cannot implicitly determine whether this is an --advance or --onto operation"));
+ else if (rinfo.positive_refexprs > 1)
+ die(_("cannot advance target with multiple source branches because ordering would be ill-defined"));
+
+ /* Only one entry, but we have to loop to get it */
+ strset_for_each_entry(&rinfo.negative_refs,
+ &iter, entry) {
+ *advance_name = entry->key;
+ }
+ } else { /* positive_refs_complete */
+ if (rinfo.negative_refexprs > 1)
+ die(_("cannot implicitly determine correct base for --onto"));
+ if (rinfo.negative_refexprs == 1)
+ *onto = rinfo.onto;
+ }
+ }
+ if (!*advance_name) {
+ *update_refs = xcalloc(1, sizeof(**update_refs));
+ **update_refs = rinfo.positive_refs;
+ memset(&rinfo.positive_refs, 0, sizeof(**update_refs));
+ }
+ strset_clear(&rinfo.negative_refs);
+ strset_clear(&rinfo.positive_refs);
+}
+
static struct commit *pick_regular_commit(struct commit *pickme,
struct commit *last_commit,
struct merge_options *merge_opt,
@@ -114,20 +255,26 @@ static struct commit *pick_regular_commit(struct commit *pickme,
int cmd_replay(int argc, const char **argv, const char *prefix)
{
- struct commit *onto;
+ const char *advance_name = NULL;
+ struct commit *onto = NULL;
const char *onto_name = NULL;
- struct commit *last_commit = NULL;
+
struct rev_info revs;
+ struct commit *last_commit = NULL;
struct commit *commit;
struct merge_options merge_opt;
struct merge_result result;
+ struct strset *update_refs = NULL;
int ret = 0;
const char * const replay_usage[] = {
- N_("(EXPERIMENTAL!) git replay --onto <newbase> <revision-range>..."),
+ N_("(EXPERIMENTAL!) git replay (--onto <newbase> | --advance <branch>) <revision-range>..."),
NULL
};
struct option replay_options[] = {
+ OPT_STRING(0, "advance", &advance_name,
+ N_("branch"),
+ N_("make replay advance given branch")),
OPT_STRING(0, "onto", &onto_name,
N_("revision"),
N_("replay onto given commit")),
@@ -137,13 +284,11 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, replay_options, replay_usage,
PARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN_OPT);
- if (!onto_name) {
- error(_("option --onto is mandatory"));
+ if (!onto_name && !advance_name) {
+ error(_("option --onto or --advance is mandatory"));
usage_with_options(replay_usage, replay_options);
}
- onto = peel_committish(onto_name);
-
repo_init_revisions(the_repository, &revs, prefix);
/*
@@ -195,6 +340,12 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
revs.simplify_history = 0;
}
+ determine_replay_mode(&revs.cmdline, onto_name, &advance_name,
+ &onto, &update_refs);
+
+ if (!onto) /* FIXME: Should handle replaying down to root commit */
+ die("Replaying down to root commit is not supported yet!");
+
if (prepare_revision_walk(&revs) < 0) {
ret = error(_("error preparing revisions"));
goto cleanup;
@@ -203,6 +354,7 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
init_merge_options(&merge_opt, the_repository);
memset(&result, 0, sizeof(result));
merge_opt.show_rename_progress = 0;
+
result.tree = repo_get_commit_tree(the_repository, onto);
last_commit = onto;
while ((commit = get_revision(&revs))) {
@@ -217,12 +369,15 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
if (!last_commit)
break;
+ /* Update any necessary branches */
+ if (advance_name)
+ continue;
decoration = get_name_decoration(&commit->object);
if (!decoration)
continue;
-
while (decoration) {
- if (decoration->type == DECORATION_REF_LOCAL) {
+ if (decoration->type == DECORATION_REF_LOCAL &&
+ strset_contains(update_refs, decoration->name)) {
printf("update %s %s %s\n",
decoration->name,
oid_to_hex(&last_commit->object.oid),
@@ -232,10 +387,22 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
}
}
+ /* In --advance mode, advance the target ref */
+ if (result.clean == 1 && advance_name) {
+ printf("update %s %s %s\n",
+ advance_name,
+ oid_to_hex(&last_commit->object.oid),
+ oid_to_hex(&onto->object.oid));
+ }
+
merge_finalize(&merge_opt, &result);
ret = result.clean;
cleanup:
+ if (update_refs) {
+ strset_clear(update_refs);
+ free(update_refs);
+ }
release_revisions(&revs);
/* Return */
diff --git a/t/t3650-replay-basics.sh b/t/t3650-replay-basics.sh
index a1da4f9ef9..68a87e7803 100755
--- a/t/t3650-replay-basics.sh
+++ b/t/t3650-replay-basics.sh
@@ -80,4 +80,38 @@ test_expect_success 'using replay on bare repo to rebase with a conflict' '
test_expect_code 1 git -C bare replay --onto topic1 B..conflict
'
+test_expect_success 'using replay to perform basic cherry-pick' '
+ # The differences between this test and previous ones are:
+ # --advance vs --onto
+ # 2nd field of result is refs/heads/main vs. refs/heads/topic2
+ # 4th field of result is hash for main instead of hash for topic2
+
+ git replay --advance main topic1..topic2 >result &&
+
+ test_line_count = 1 result &&
+
+ git log --format=%s $(cut -f 3 -d " " result) >actual &&
+ test_write_lines E D M L B A >expect &&
+ test_cmp expect actual &&
+
+ printf "update refs/heads/main " >expect &&
+ printf "%s " $(cut -f 3 -d " " result) >>expect &&
+ git rev-parse main >>expect &&
+
+ test_cmp expect result
+'
+
+test_expect_success 'using replay on bare repo to perform basic cherry-pick' '
+ git -C bare replay --advance main topic1..topic2 >result-bare &&
+ test_cmp expect result-bare
+'
+
+test_expect_success 'replay on bare repo fails with both --advance and --onto' '
+ test_must_fail git -C bare replay --advance main --onto main topic1..topic2 >result-bare
+'
+
+test_expect_success 'replay fails when both --advance and --onto are omitted' '
+ test_must_fail git replay topic1..topic2 >result
+'
+
test_done
--
2.43.0.14.g93e034faee
^ permalink raw reply related
* [PATCH v8 11/14] replay: use standard revision ranges
From: Christian Couder @ 2023-11-24 11:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
Elijah Newren, John Cai, Derrick Stolee, Phillip Wood, Calvin Wan,
Toon Claes, Dragan Simic, Linus Arver, Christian Couder
In-Reply-To: <20231124111044.3426007-1-christian.couder@gmail.com>
From: Elijah Newren <newren@gmail.com>
Instead of the fixed "<oldbase> <branch>" arguments, the replay
command now accepts "<revision-range>..." arguments in a similar
way as many other Git commands. This makes its interface more
standard and more flexible.
This also enables many revision related options accepted and
eaten by setup_revisions(). If the replay command was a high level
one or had a high level mode, it would make sense to restrict some
of the possible options, like those generating non-contiguous
history, as they could be confusing for most users.
Also as the interface of the command is now mostly finalized,
we can add more documentation and more testcases to make sure
the command will continue to work as designed in the future.
We only document the rev-list related options among all the
revision related options that are now accepted, as the rev-list
related ones are probably the most useful for now.
Helped-by: Dragan Simic <dsimic@manjaro.org>
Helped-by: Linus Arver <linusa@google.com>
Co-authored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replay.txt | 58 ++++++++++++++++++++++--
builtin/replay.c | 21 ++-------
t/t3650-replay-basics.sh | 12 ++++-
t/t6429-merge-sequence-rename-caching.sh | 18 ++++----
4 files changed, 77 insertions(+), 32 deletions(-)
diff --git a/Documentation/git-replay.txt b/Documentation/git-replay.txt
index 267282d92a..f7b232caa2 100644
--- a/Documentation/git-replay.txt
+++ b/Documentation/git-replay.txt
@@ -9,16 +9,16 @@ git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos t
SYNOPSIS
--------
[verse]
-(EXPERIMENTAL!) 'git replay' --onto <newbase> <oldbase> <branch>
+(EXPERIMENTAL!) 'git replay' --onto <newbase> <revision-range>...
DESCRIPTION
-----------
-Takes a range of commits, specified by <oldbase> and <branch>, and
-replays them onto a new location (see `--onto` option below). Leaves
+Takes ranges of commits and replays them onto a new location. Leaves
the working tree and the index untouched, and updates no references.
The output of this command is meant to be used as input to
-`git update-ref --stdin`, which would update the relevant branches.
+`git update-ref --stdin`, which would update the relevant branches
+(see the OUTPUT section below).
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
@@ -28,6 +28,30 @@ OPTIONS
--onto <newbase>::
Starting point at which to create the new commits. May be any
valid commit, and not just an existing branch name.
++
+The update-ref command(s) in the output will update the branch(es) in
+the revision range to point at the new commits, similar to the way how
+`git rebase --update-refs` updates multiple branches in the affected
+range.
+
+<revision-range>::
+ Range of commits to replay; see "Specifying Ranges" in
+ linkgit:git-rev-parse and the "Commit Limiting" options below.
+
+include::rev-list-options.txt[]
+
+OUTPUT
+------
+
+When there are no conflicts, the output of this command is usable as
+input to `git update-ref --stdin`. It is of the form:
+
+ update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
+ update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
+ update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}
+
+where the number of refs updated depends on the arguments passed and
+the shape of the history being replayed.
EXIT STATUS
-----------
@@ -37,6 +61,32 @@ the replay has conflicts, the exit status is 1. If the replay is not
able to complete (or start) due to some kind of error, the exit status
is something other than 0 or 1.
+EXAMPLES
+--------
+
+To simply rebase `mybranch` onto `target`:
+
+------------
+$ git replay --onto target origin/main..mybranch
+update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH}
+------------
+
+When calling `git replay`, one does not need to specify a range of
+commits to replay using the syntax `A..B`; any range expression will
+do:
+
+------------
+$ git replay --onto origin/main ^base branch1 branch2 branch3
+update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
+update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
+update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}
+------------
+
+This will simultaneously rebase `branch1`, `branch2`, and `branch3`,
+all commits they have since `base`, playing them on top of
+`origin/main`. These three branches may have commits on top of `base`
+that they have in common, but that does not need to be the case.
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/builtin/replay.c b/builtin/replay.c
index bfccbbbfea..3d5e00147b 100644
--- a/builtin/replay.c
+++ b/builtin/replay.c
@@ -14,7 +14,6 @@
#include "parse-options.h"
#include "refs.h"
#include "revision.h"
-#include "strvec.h"
#include <oidset.h>
#include <tree.h>
@@ -118,16 +117,14 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
struct commit *onto;
const char *onto_name = NULL;
struct commit *last_commit = NULL;
- struct strvec rev_walk_args = STRVEC_INIT;
struct rev_info revs;
struct commit *commit;
struct merge_options merge_opt;
struct merge_result result;
- struct strbuf branch_name = STRBUF_INIT;
int ret = 0;
const char * const replay_usage[] = {
- N_("(EXPERIMENTAL!) git replay --onto <newbase> <oldbase> <branch>"),
+ N_("(EXPERIMENTAL!) git replay --onto <newbase> <revision-range>..."),
NULL
};
struct option replay_options[] = {
@@ -145,18 +142,10 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
usage_with_options(replay_usage, replay_options);
}
- if (argc != 3) {
- error(_("bad number of arguments"));
- usage_with_options(replay_usage, replay_options);
- }
-
onto = peel_committish(onto_name);
- strbuf_addf(&branch_name, "refs/heads/%s", argv[2]);
repo_init_revisions(the_repository, &revs, prefix);
- strvec_pushl(&rev_walk_args, "", argv[2], "--not", argv[1], NULL);
-
/*
* Set desired values for rev walking options here. If they
* are changed by some user specified option in setup_revisions()
@@ -171,8 +160,9 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
revs.topo_order = 1;
revs.simplify_history = 0;
- if (setup_revisions(rev_walk_args.nr, rev_walk_args.v, &revs, NULL) > 1) {
- ret = error(_("unhandled options"));
+ argc = setup_revisions(argc, argv, &revs, NULL);
+ if (argc > 1) {
+ ret = error(_("unrecognized argument: %s"), argv[1]);
goto cleanup;
}
@@ -205,8 +195,6 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
revs.simplify_history = 0;
}
- strvec_clear(&rev_walk_args);
-
if (prepare_revision_walk(&revs) < 0) {
ret = error(_("error preparing revisions"));
goto cleanup;
@@ -248,7 +236,6 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
ret = result.clean;
cleanup:
- strbuf_release(&branch_name);
release_revisions(&revs);
/* Return */
diff --git a/t/t3650-replay-basics.sh b/t/t3650-replay-basics.sh
index 3567c98362..a1da4f9ef9 100755
--- a/t/t3650-replay-basics.sh
+++ b/t/t3650-replay-basics.sh
@@ -52,7 +52,7 @@ test_expect_success 'setup bare' '
'
test_expect_success 'using replay to rebase two branches, one on top of other' '
- git replay --onto main topic1 topic2 >result &&
+ git replay --onto main topic1..topic2 >result &&
test_line_count = 1 result &&
@@ -68,8 +68,16 @@ test_expect_success 'using replay to rebase two branches, one on top of other' '
'
test_expect_success 'using replay on bare repo to rebase two branches, one on top of other' '
- git -C bare replay --onto main topic1 topic2 >result-bare &&
+ git -C bare replay --onto main topic1..topic2 >result-bare &&
test_cmp expect result-bare
'
+test_expect_success 'using replay to rebase with a conflict' '
+ test_expect_code 1 git replay --onto topic1 B..conflict
+'
+
+test_expect_success 'using replay on bare repo to rebase with a conflict' '
+ test_expect_code 1 git -C bare replay --onto topic1 B..conflict
+'
+
test_done
diff --git a/t/t6429-merge-sequence-rename-caching.sh b/t/t6429-merge-sequence-rename-caching.sh
index 099aefeffc..0f39ed0d08 100755
--- a/t/t6429-merge-sequence-rename-caching.sh
+++ b/t/t6429-merge-sequence-rename-caching.sh
@@ -71,7 +71,7 @@ test_expect_success 'caching renames does not preclude finding new ones' '
git switch upstream &&
- git replay --onto HEAD upstream~1 topic >out &&
+ git replay --onto HEAD upstream~1..topic >out &&
git update-ref --stdin <out &&
git checkout topic &&
@@ -141,7 +141,7 @@ test_expect_success 'cherry-pick both a commit and its immediate revert' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic >out &&
+ git replay --onto HEAD upstream~1..topic >out &&
git update-ref --stdin <out &&
git checkout topic &&
@@ -201,7 +201,7 @@ test_expect_success 'rename same file identically, then reintroduce it' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic >out &&
+ git replay --onto HEAD upstream~1..topic >out &&
git update-ref --stdin <out &&
git checkout topic &&
@@ -279,7 +279,7 @@ test_expect_success 'rename same file identically, then add file to old dir' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic >out &&
+ git replay --onto HEAD upstream~1..topic >out &&
git update-ref --stdin <out &&
git checkout topic &&
@@ -357,7 +357,7 @@ test_expect_success 'cached dir rename does not prevent noticing later conflict'
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- test_must_fail git replay --onto HEAD upstream~1 topic >output &&
+ test_must_fail git replay --onto HEAD upstream~1..topic >output &&
grep region_enter.*diffcore_rename trace.output >calls &&
test_line_count = 2 calls
@@ -456,7 +456,7 @@ test_expect_success 'dir rename unneeded, then add new file to old dir' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic >out &&
+ git replay --onto HEAD upstream~1..topic >out &&
git update-ref --stdin <out &&
git checkout topic &&
@@ -523,7 +523,7 @@ test_expect_success 'dir rename unneeded, then rename existing file into old dir
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic >out &&
+ git replay --onto HEAD upstream~1..topic >out &&
git update-ref --stdin <out &&
git checkout topic &&
@@ -626,7 +626,7 @@ test_expect_success 'caching renames only on upstream side, part 1' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic >out &&
+ git replay --onto HEAD upstream~1..topic >out &&
git update-ref --stdin <out &&
git checkout topic &&
@@ -685,7 +685,7 @@ test_expect_success 'caching renames only on upstream side, part 2' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic >out &&
+ git replay --onto HEAD upstream~1..topic >out &&
git update-ref --stdin <out &&
git checkout topic &&
--
2.43.0.14.g93e034faee
^ permalink raw reply related
* [PATCH v8 10/14] replay: make it a minimal server side command
From: Christian Couder @ 2023-11-24 11:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
Elijah Newren, John Cai, Derrick Stolee, Phillip Wood, Calvin Wan,
Toon Claes, Dragan Simic, Linus Arver, Christian Couder
In-Reply-To: <20231124111044.3426007-1-christian.couder@gmail.com>
From: Elijah Newren <newren@gmail.com>
We want this command to be a minimal command that just does server side
picking of commits, displaying the results on stdout for higher level
scripts to consume.
So let's simplify it:
* remove the worktree and index reading/writing,
* remove the ref (and reflog) updating,
* remove the assumptions tying us to HEAD, since (a) this is not a
rebase and (b) we want to be able to pick commits in a bare repo,
i.e. to/from branches that are not checked out and not the main
branch,
* remove unneeded includes,
* handle rebasing multiple branches by printing on stdout the update
ref commands that should be performed.
The output can be piped into `git update-ref --stdin` for the ref
updates to happen.
In the future to make it easier for users to use this command
directly maybe an option can be added to automatically pipe its output
into `git update-ref`.
Co-authored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replay.txt | 5 +-
builtin/replay.c | 78 ++++++++----------------
t/t3650-replay-basics.sh | 19 +++++-
t/t6429-merge-sequence-rename-caching.sh | 39 +++++++-----
4 files changed, 72 insertions(+), 69 deletions(-)
diff --git a/Documentation/git-replay.txt b/Documentation/git-replay.txt
index 2ca7ca5fd8..267282d92a 100644
--- a/Documentation/git-replay.txt
+++ b/Documentation/git-replay.txt
@@ -15,7 +15,10 @@ DESCRIPTION
-----------
Takes a range of commits, specified by <oldbase> and <branch>, and
-replays them onto a new location (see `--onto` option below).
+replays them onto a new location (see `--onto` option below). Leaves
+the working tree and the index untouched, and updates no references.
+The output of this command is meant to be used as input to
+`git update-ref --stdin`, which would update the relevant branches.
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
diff --git a/builtin/replay.c b/builtin/replay.c
index bdec2f2b97..bfccbbbfea 100644
--- a/builtin/replay.c
+++ b/builtin/replay.c
@@ -6,11 +6,7 @@
#include "git-compat-util.h"
#include "builtin.h"
-#include "cache-tree.h"
-#include "commit.h"
#include "environment.h"
-#include "gettext.h"
-#include "hash.h"
#include "hex.h"
#include "lockfile.h"
#include "merge-ort.h"
@@ -18,8 +14,6 @@
#include "parse-options.h"
#include "refs.h"
#include "revision.h"
-#include "sequencer.h"
-#include "setup.h"
#include "strvec.h"
#include <oidset.h>
#include <tree.h>
@@ -102,6 +96,7 @@ static struct commit *pick_regular_commit(struct commit *pickme,
pickme_tree = repo_get_commit_tree(the_repository, pickme);
base_tree = repo_get_commit_tree(the_repository, base);
+ merge_opt->branch1 = short_commit_name(last_commit);
merge_opt->branch2 = short_commit_name(pickme);
merge_opt->ancestor = xstrfmt("parent of %s", merge_opt->branch2);
@@ -122,15 +117,12 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
{
struct commit *onto;
const char *onto_name = NULL;
- struct commit *last_commit = NULL, *last_picked_commit = NULL;
- struct lock_file lock = LOCK_INIT;
+ struct commit *last_commit = NULL;
struct strvec rev_walk_args = STRVEC_INIT;
struct rev_info revs;
struct commit *commit;
struct merge_options merge_opt;
- struct tree *head_tree;
struct merge_result result;
- struct strbuf reflog_msg = STRBUF_INIT;
struct strbuf branch_name = STRBUF_INIT;
int ret = 0;
@@ -161,10 +153,6 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
onto = peel_committish(onto_name);
strbuf_addf(&branch_name, "refs/heads/%s", argv[2]);
- repo_hold_locked_index(the_repository, &lock, LOCK_DIE_ON_ERROR);
- if (repo_read_index(the_repository) < 0)
- BUG("Could not read index");
-
repo_init_revisions(the_repository, &revs, prefix);
strvec_pushl(&rev_walk_args, "", argv[2], "--not", argv[1], NULL);
@@ -227,58 +215,44 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
init_merge_options(&merge_opt, the_repository);
memset(&result, 0, sizeof(result));
merge_opt.show_rename_progress = 0;
- merge_opt.branch1 = "HEAD";
- head_tree = repo_get_commit_tree(the_repository, onto);
- result.tree = head_tree;
+ result.tree = repo_get_commit_tree(the_repository, onto);
last_commit = onto;
while ((commit = get_revision(&revs))) {
- struct commit *pick;
+ const struct name_decoration *decoration;
if (!commit->parents)
die(_("replaying down to root commit is not supported yet!"));
if (commit->parents->next)
die(_("replaying merge commits is not supported yet!"));
- pick = pick_regular_commit(commit, last_commit, &merge_opt, &result);
- if (!pick)
+ last_commit = pick_regular_commit(commit, last_commit, &merge_opt, &result);
+ if (!last_commit)
break;
- last_commit = pick;
- last_picked_commit = commit;
+
+ decoration = get_name_decoration(&commit->object);
+ if (!decoration)
+ continue;
+
+ while (decoration) {
+ if (decoration->type == DECORATION_REF_LOCAL) {
+ printf("update %s %s %s\n",
+ decoration->name,
+ oid_to_hex(&last_commit->object.oid),
+ oid_to_hex(&commit->object.oid));
+ }
+ decoration = decoration->next;
+ }
}
merge_finalize(&merge_opt, &result);
+ ret = result.clean;
- if (result.clean < 0)
- exit(128);
-
- if (result.clean) {
- strbuf_addf(&reflog_msg, "finish rebase %s onto %s",
- oid_to_hex(&last_picked_commit->object.oid),
- oid_to_hex(&last_commit->object.oid));
- if (update_ref(reflog_msg.buf, branch_name.buf,
- &last_commit->object.oid,
- &last_picked_commit->object.oid,
- REF_NO_DEREF, UPDATE_REFS_MSG_ON_ERR)) {
- error(_("could not update %s"), argv[2]);
- die("Failed to update %s", argv[2]);
- }
- if (create_symref("HEAD", branch_name.buf, reflog_msg.buf) < 0)
- die(_("unable to update HEAD"));
- } else {
- strbuf_addf(&reflog_msg, "rebase progress up to %s",
- oid_to_hex(&last_picked_commit->object.oid));
- if (update_ref(reflog_msg.buf, "HEAD",
- &last_commit->object.oid,
- &onto->object.oid,
- REF_NO_DEREF, UPDATE_REFS_MSG_ON_ERR)) {
- error(_("could not update %s"), argv[2]);
- die("Failed to update %s", argv[2]);
- }
- }
- ret = (result.clean == 0);
cleanup:
- strbuf_release(&reflog_msg);
strbuf_release(&branch_name);
release_revisions(&revs);
- return ret;
+
+ /* Return */
+ if (ret < 0)
+ exit(128);
+ return ret ? 0 : 1;
}
diff --git a/t/t3650-replay-basics.sh b/t/t3650-replay-basics.sh
index b5b9f9ade2..3567c98362 100755
--- a/t/t3650-replay-basics.sh
+++ b/t/t3650-replay-basics.sh
@@ -47,12 +47,29 @@ test_expect_success 'setup' '
test_commit C.conflict C.t conflict
'
+test_expect_success 'setup bare' '
+ git clone --bare . bare
+'
+
test_expect_success 'using replay to rebase two branches, one on top of other' '
git replay --onto main topic1 topic2 >result &&
+ test_line_count = 1 result &&
+
git log --format=%s $(cut -f 3 -d " " result) >actual &&
test_write_lines E D M L B A >expect &&
- test_cmp expect actual
+ test_cmp expect actual &&
+
+ printf "update refs/heads/topic2 " >expect &&
+ printf "%s " $(cut -f 3 -d " " result) >>expect &&
+ git rev-parse topic2 >>expect &&
+
+ test_cmp expect result
+'
+
+test_expect_success 'using replay on bare repo to rebase two branches, one on top of other' '
+ git -C bare replay --onto main topic1 topic2 >result-bare &&
+ test_cmp expect result-bare
'
test_done
diff --git a/t/t6429-merge-sequence-rename-caching.sh b/t/t6429-merge-sequence-rename-caching.sh
index 7670b72008..099aefeffc 100755
--- a/t/t6429-merge-sequence-rename-caching.sh
+++ b/t/t6429-merge-sequence-rename-caching.sh
@@ -71,8 +71,9 @@ test_expect_success 'caching renames does not preclude finding new ones' '
git switch upstream &&
- git replay --onto HEAD upstream~1 topic &&
- git reset --hard topic &&
+ git replay --onto HEAD upstream~1 topic >out &&
+ git update-ref --stdin <out &&
+ git checkout topic &&
git ls-files >tracked-files &&
test_line_count = 2 tracked-files &&
@@ -140,7 +141,9 @@ test_expect_success 'cherry-pick both a commit and its immediate revert' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic &&
+ git replay --onto HEAD upstream~1 topic >out &&
+ git update-ref --stdin <out &&
+ git checkout topic &&
grep region_enter.*diffcore_rename trace.output >calls &&
test_line_count = 1 calls
@@ -198,8 +201,9 @@ test_expect_success 'rename same file identically, then reintroduce it' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic &&
- git reset --hard topic &&
+ git replay --onto HEAD upstream~1 topic >out &&
+ git update-ref --stdin <out &&
+ git checkout topic &&
git ls-files >tracked &&
test_line_count = 2 tracked &&
@@ -275,8 +279,9 @@ test_expect_success 'rename same file identically, then add file to old dir' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic &&
- git reset --hard topic &&
+ git replay --onto HEAD upstream~1 topic >out &&
+ git update-ref --stdin <out &&
+ git checkout topic &&
git ls-files >tracked &&
test_line_count = 4 tracked &&
@@ -451,8 +456,9 @@ test_expect_success 'dir rename unneeded, then add new file to old dir' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic &&
- git reset --hard topic &&
+ git replay --onto HEAD upstream~1 topic >out &&
+ git update-ref --stdin <out &&
+ git checkout topic &&
grep region_enter.*diffcore_rename trace.output >calls &&
test_line_count = 2 calls &&
@@ -517,8 +523,9 @@ test_expect_success 'dir rename unneeded, then rename existing file into old dir
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic &&
- git reset --hard topic &&
+ git replay --onto HEAD upstream~1 topic >out &&
+ git update-ref --stdin <out &&
+ git checkout topic &&
grep region_enter.*diffcore_rename trace.output >calls &&
test_line_count = 3 calls &&
@@ -619,8 +626,9 @@ test_expect_success 'caching renames only on upstream side, part 1' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic &&
- git reset --hard topic &&
+ git replay --onto HEAD upstream~1 topic >out &&
+ git update-ref --stdin <out &&
+ git checkout topic &&
grep region_enter.*diffcore_rename trace.output >calls &&
test_line_count = 1 calls &&
@@ -677,8 +685,9 @@ test_expect_success 'caching renames only on upstream side, part 2' '
GIT_TRACE2_PERF="$(pwd)/trace.output" &&
export GIT_TRACE2_PERF &&
- git replay --onto HEAD upstream~1 topic &&
- git reset --hard topic &&
+ git replay --onto HEAD upstream~1 topic >out &&
+ git update-ref --stdin <out &&
+ git checkout topic &&
grep region_enter.*diffcore_rename trace.output >calls &&
test_line_count = 2 calls &&
--
2.43.0.14.g93e034faee
^ permalink raw reply related
* [PATCH v8 09/14] replay: remove HEAD related sanity check
From: Christian Couder @ 2023-11-24 11:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
Elijah Newren, John Cai, Derrick Stolee, Phillip Wood, Calvin Wan,
Toon Claes, Dragan Simic, Linus Arver, Christian Couder
In-Reply-To: <20231124111044.3426007-1-christian.couder@gmail.com>
From: Elijah Newren <newren@gmail.com>
We want replay to be a command that can be used on the server side on
any branch, not just the current one, so we are going to stop updating
HEAD in a future commit.
A "sanity check" that makes sure we are replaying the current branch
doesn't make sense anymore. Let's remove it.
Co-authored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin/replay.c | 8 +-------
t/t3650-replay-basics.sh | 2 --
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/builtin/replay.c b/builtin/replay.c
index ca3867dc57..bdec2f2b97 100644
--- a/builtin/replay.c
+++ b/builtin/replay.c
@@ -123,7 +123,6 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
struct commit *onto;
const char *onto_name = NULL;
struct commit *last_commit = NULL, *last_picked_commit = NULL;
- struct object_id head;
struct lock_file lock = LOCK_INIT;
struct strvec rev_walk_args = STRVEC_INIT;
struct rev_info revs;
@@ -162,11 +161,6 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
onto = peel_committish(onto_name);
strbuf_addf(&branch_name, "refs/heads/%s", argv[2]);
- /* Sanity check */
- if (repo_get_oid(the_repository, "HEAD", &head))
- die(_("Cannot read HEAD"));
- assert(oideq(&onto->object.oid, &head));
-
repo_hold_locked_index(the_repository, &lock, LOCK_DIE_ON_ERROR);
if (repo_read_index(the_repository) < 0)
BUG("Could not read index");
@@ -275,7 +269,7 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
oid_to_hex(&last_picked_commit->object.oid));
if (update_ref(reflog_msg.buf, "HEAD",
&last_commit->object.oid,
- &head,
+ &onto->object.oid,
REF_NO_DEREF, UPDATE_REFS_MSG_ON_ERR)) {
error(_("could not update %s"), argv[2]);
die("Failed to update %s", argv[2]);
diff --git a/t/t3650-replay-basics.sh b/t/t3650-replay-basics.sh
index 36c1b5082a..b5b9f9ade2 100755
--- a/t/t3650-replay-basics.sh
+++ b/t/t3650-replay-basics.sh
@@ -48,8 +48,6 @@ test_expect_success 'setup' '
'
test_expect_success 'using replay to rebase two branches, one on top of other' '
- git switch main &&
-
git replay --onto main topic1 topic2 >result &&
git log --format=%s $(cut -f 3 -d " " result) >actual &&
--
2.43.0.14.g93e034faee
^ permalink raw reply related
* [PATCH v8 08/14] replay: remove progress and info output
From: Christian Couder @ 2023-11-24 11:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
Elijah Newren, John Cai, Derrick Stolee, Phillip Wood, Calvin Wan,
Toon Claes, Dragan Simic, Linus Arver, Christian Couder
In-Reply-To: <20231124111044.3426007-1-christian.couder@gmail.com>
From: Elijah Newren <newren@gmail.com>
The replay command will be changed in a follow up commit, so that it
will not update refs directly, but instead it will print on stdout a
list of commands that can be consumed by `git update-ref --stdin`.
We don't want this output to be polluted by its current low value
output, so let's just remove the latter.
In the future, when the command gets an option to update refs by
itself, it will make a lot of sense to display a progress meter, but
we are not there yet.
Co-authored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin/replay.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/builtin/replay.c b/builtin/replay.c
index 384bb4ddd3..ca3867dc57 100644
--- a/builtin/replay.c
+++ b/builtin/replay.c
@@ -232,7 +232,7 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
init_merge_options(&merge_opt, the_repository);
memset(&result, 0, sizeof(result));
- merge_opt.show_rename_progress = 1;
+ merge_opt.show_rename_progress = 0;
merge_opt.branch1 = "HEAD";
head_tree = repo_get_commit_tree(the_repository, onto);
result.tree = head_tree;
@@ -240,9 +240,6 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
while ((commit = get_revision(&revs))) {
struct commit *pick;
- fprintf(stderr, "Rebasing %s...\r",
- oid_to_hex(&commit->object.oid));
-
if (!commit->parents)
die(_("replaying down to root commit is not supported yet!"));
if (commit->parents->next)
@@ -261,7 +258,6 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
exit(128);
if (result.clean) {
- fprintf(stderr, "\nDone.\n");
strbuf_addf(&reflog_msg, "finish rebase %s onto %s",
oid_to_hex(&last_picked_commit->object.oid),
oid_to_hex(&last_commit->object.oid));
@@ -275,7 +271,6 @@ int cmd_replay(int argc, const char **argv, const char *prefix)
if (create_symref("HEAD", branch_name.buf, reflog_msg.buf) < 0)
die(_("unable to update HEAD"));
} else {
- fprintf(stderr, "\nAborting: Hit a conflict.\n");
strbuf_addf(&reflog_msg, "rebase progress up to %s",
oid_to_hex(&last_picked_commit->object.oid));
if (update_ref(reflog_msg.buf, "HEAD",
--
2.43.0.14.g93e034faee
^ permalink raw reply related
* [PATCH v8 07/14] replay: add an important FIXME comment about gpg signing
From: Christian Couder @ 2023-11-24 11:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
Elijah Newren, John Cai, Derrick Stolee, Phillip Wood, Calvin Wan,
Toon Claes, Dragan Simic, Linus Arver, Christian Couder
In-Reply-To: <20231124111044.3426007-1-christian.couder@gmail.com>
From: Elijah Newren <newren@gmail.com>
We want to be able to handle signed commits in some way in the future,
but we are not ready to do it now. So for the time being let's just add
a FIXME comment to remind us about it.
These are different ways we could handle them:
- in case of a cli user and if there was an interactive mode, we could
perhaps ask if the user wants to sign again
- we could add an option to just fail if there are signed commits
Co-authored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin/replay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/replay.c b/builtin/replay.c
index 2f664218be..384bb4ddd3 100644
--- a/builtin/replay.c
+++ b/builtin/replay.c
@@ -62,7 +62,7 @@ static struct commit *create_commit(struct tree *tree,
struct object *obj;
struct commit_list *parents = NULL;
char *author;
- char *sign_commit = NULL;
+ char *sign_commit = NULL; /* FIXME: cli users might want to sign again */
struct commit_extra_header *extra;
struct strbuf msg = STRBUF_INIT;
const char *out_enc = get_commit_output_encoding();
--
2.43.0.14.g93e034faee
^ 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