> -	base = pickme->parents->item;
> -	replayed_base = mapped_commit(replayed_commits, base, onto);
> +	if (pickme->parents) {
> +		base = pickme->parents->item;
> +		replayed_base = mapped_commit(replayed_commits, base, onto);
> +		base_tree = repo_get_commit_tree(repo, base);

> +	} else {
> +		base = NULL;
> +		replayed_base = onto;
> +		base_tree = lookup_tree(repo, repo->hash_algo->empty_tree);
> +	}

> Toon Claes <toon@iotcl.com> writes:
>
>> git-replay(1) doesn't allow replaying commits all the way down to the
>> root commit. Fix that.
>
> OK.
>
>> -	base = pickme->parents->item;
>> -	replayed_base = mapped_commit(replayed_commits, base, onto);
>> +	if (pickme->parents) {
>> +		base = pickme->parents->item;
>> +		replayed_base = mapped_commit(replayed_commits, base, onto);
>> +		base_tree = repo_get_commit_tree(repo, base);
>
> So, if we are replaying a commit with parent(s), we do the same as
> before (base_tree used to be computed a bit later).  But ...
>
>> +	} else {
>> +		base = NULL;
>> +		replayed_base = onto;
>> +		base_tree = lookup_tree(repo, repo->hash_algo->empty_tree);
>> +	}
>
> ... if we are replaying the root commit, there is no base (in
> contrast to "the first parent of the original commit" used in the
> other branch of this if-else construct).  We use an empty tree for
> the base_tree, which is the natural thing to use to replay for a
> root commit, of course.
>
> I am not sure why replayed_base is computed differently, though?  Is
> it because mapped_commit() would not work when base==NULL?

> git-replay(1) doesn't allow replaying commits all the way down to the
> root commit. Fix that.
>
> Signed-off-by: Toon Claes <toon@iotcl.com>
> ---
> These changes might conflict Siddharth's series[1] to add '--revert' to
> git-replay(1), although resolving that should be trivial.

>
> Toon Claes <toon@iotcl.com> writes:
>
> > git-replay(1) doesn't allow replaying commits all the way down to the
> > root commit. Fix that.
> >
> > Signed-off-by: Toon Claes <toon@iotcl.com>
> > ---
> > These changes might conflict Siddharth's series[1] to add '--revert' to
> > git-replay(1), although resolving that should be trivial.
>
> True.  This round looks great to me.  Will queue.
>
> Shall we mark the topic for 'next' now?

> Le 25 mars 2026 à 06:05, Christian Couder <christian.couder@gmail.com> a écrit :
> 
> On Tue, Mar 24, 2026 at 8:56 PM Junio C Hamano <gitster@pobox.com> wrote:
>> 
>> Toon Claes <toon@iotcl.com> writes:
>> 
>>> git-replay(1) doesn't allow replaying commits all the way down to the
>>> root commit. Fix that.
>>> 
>>> Signed-off-by: Toon Claes <toon@iotcl.com>
>>> ---
>>> These changes might conflict Siddharth's series[1] to add '--revert' to
>>> git-replay(1), although resolving that should be trivial.
>> 
>> True.  This round looks great to me.  Will queue.
>> 
>> Shall we mark the topic for 'next' now?
> 
> The patch looks good to me, but I wonder if the docs should be updated
> somehow, especially to try to avoid confusion in case users don't
> properly specify a range.
> 
> For example, before this, `git replay --onto main topic` would fail,
> but emit "fatal: replaying down from root commit is not supported
> yet!". This would likely help users understand that they might need to
> properly specify a range like "main..topic" instead of 'topic".
> 
> Now it would likely fail without any error message.

> 
> Maybe something like the following could help:
> 
> --- a/Documentation/git-replay.adoc
> +++ b/Documentation/git-replay.adoc
> @@ -23,6 +23,10 @@ instead get update commands that can be piped to
> `git update-ref --stdin`
> 
> THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
> 
> +Note that `git replay --onto main topic` replays the topic branch starting
> +from the root commit, not from main. What you might want instead is
> +`git replay --onto main main..topic`.
> +
> OPTIONS
> -------
> 
> ?
> 
> And yeah currently `git replay` is a plumbing command that most
> regular users shouldn't likely use, but I think Elijah's goal was to
> eventually make it user friendly enough for advanced users with
> stacked branches.
> 

> On Tue, Mar 24, 2026 at 8:56 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Toon Claes <toon@iotcl.com> writes:
>>
>> > git-replay(1) doesn't allow replaying commits all the way down to the
>> > root commit. Fix that.
>> >
>> > Signed-off-by: Toon Claes <toon@iotcl.com>
>> > ---
>> > These changes might conflict Siddharth's series[1] to add '--revert' to
>> > git-replay(1), although resolving that should be trivial.
>>
>> True.  This round looks great to me.  Will queue.
>>
>> Shall we mark the topic for 'next' now?
>
> The patch looks good to me, but I wonder if the docs should be updated
> somehow, especially to try to avoid confusion in case users don't
> properly specify a range.
>
> For example, before this, `git replay --onto main topic` would fail,
> but emit "fatal: replaying down from root commit is not supported
> yet!".

> This would likely help users understand that they might need to
> properly specify a range like "main..topic" instead of 'topic".
>
> Now it would likely fail without any error message.
>
> Maybe something like the following could help:
>
> --- a/Documentation/git-replay.adoc
> +++ b/Documentation/git-replay.adoc
> @@ -23,6 +23,10 @@ instead get update commands that can be piped to
> `git update-ref --stdin`
>
>  THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
>
> +Note that `git replay --onto main topic` replays the topic branch starting
> +from the root commit, not from main. What you might want instead is
> +`git replay --onto main main..topic`.
> +

>> The patch looks good to me, but I wonder if the docs should be updated
>> somehow, especially to try to avoid confusion in case users don't
>> properly specify a range.
>> 
>> For example, before this, `git replay --onto main topic` would fail,
>> but emit "fatal: replaying down from root commit is not supported
>> yet!". This would likely help users understand that they might need to
>> properly specify a range like "main..topic" instead of 'topic".
>> 
>> Now it would likely fail without any error message.
>
> Having used replay in a large monorepo where I juggle many branches
> (so rebasing another in-flight topic without otherwise interrupting my
> work is valuable), I’ve made this mistake a few times. Some way of
> handling it more gracefully would be appreciated: perhaps the root
> case is rare enough to warrant an option or confirmation prompt (when
> attached interactively)?

> For example, before this, `git replay --onto main topic` would fail,
> but emit "fatal: replaying down from root commit is not supported
> yet!". This would likely help users understand that they might need to
> properly specify a range like "main..topic" instead of 'topic".
>
> Now it would likely fail without any error message.

> Maybe something like the following could help:
>
> --- a/Documentation/git-replay.adoc
> +++ b/Documentation/git-replay.adoc
> @@ -23,6 +23,10 @@ instead get update commands that can be piped to
> `git update-ref --stdin`
>
>  THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
>
> +Note that `git replay --onto main topic` replays the topic branch starting
> +from the root commit, not from main. What you might want instead is
> +`git replay --onto main main..topic`.

>> Maybe something like the following could help:
>>
>> --- a/Documentation/git-replay.adoc
>> +++ b/Documentation/git-replay.adoc
>> @@ -23,6 +23,10 @@ instead get update commands that can be piped to
>> `git update-ref --stdin`
>>
>>  THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
>>
>> +Note that `git replay --onto main topic` replays the topic branch starting
>> +from the root commit, not from main. What you might want instead is
>> +`git replay --onto main main..topic`.
>> +
>
> Definitely would help, not sure it needs to be part of this series.

>
> Toon Claes <toon@iotcl.com> writes:
>
> >> Maybe something like the following could help:
> >>
> >> --- a/Documentation/git-replay.adoc
> >> +++ b/Documentation/git-replay.adoc
> >> @@ -23,6 +23,10 @@ instead get update commands that can be piped to
> >> `git update-ref --stdin`
> >>
> >>  THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
> >>
> >> +Note that `git replay --onto main topic` replays the topic branch starting
> >> +from the root commit, not from main. What you might want instead is
> >> +`git replay --onto main main..topic`.
> >> +
> >
> > Definitely would help, not sure it needs to be part of this series.
>
> Where else should the patch to add such a note to the documentation
> go, though?  Without this patch, we do not is because the command
> will not take such a command line.  With this patch that adds the
> "now we allow replay to take a single tip commit and replay the
> history leading to the tip all the way down to root" feature, the
> note may become relevant.
>
> So to me, it looks like it is either we will never add such a note
> because it is irrelevant and everybody should know the consequence
> of passing "topic", not "main..topic", or we will have to add such a
> note as part of the series (if the note would help the readers).
>
> Even though I am on the fence about the need for this specific note
> in the documentation, it does not make sense to me to say "this will
> help but we are not doing so here".
>
> My comment on "might" in "What you might" in the thread still
> applies, by the way.

> So if we are about to fix that main issue in a separate patch or
> series, and if we plan to emit something like the following in the
> regular case:
>
> "fatal: replaying failed due to conflict"
>
> and something like the following when replaying from a root commit:
>
> "fatal: replaying from root commit XXX failed due to conflict"
>
> then I think it would alleviate the need for a doc update.

> Toon Claes <toon@iotcl.com> writes:
>
>>> Maybe something like the following could help:
>>>
>>> --- a/Documentation/git-replay.adoc
>>> +++ b/Documentation/git-replay.adoc
>>> @@ -23,6 +23,10 @@ instead get update commands that can be piped to
>>> `git update-ref --stdin`
>>>
>>>  THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
>>>
>>> +Note that `git replay --onto main topic` replays the topic branch starting
>>> +from the root commit, not from main. What you might want instead is
>>> +`git replay --onto main main..topic`.
>>> +
>>
>> Definitely would help, not sure it needs to be part of this series.
>
> Where else should the patch to add such a note to the documentation
> go, though?

> Where else should the patch to add such a note to the documentation
> go, though?  Without this patch, we do not is because the command
> will not take such a command line.  With this patch that adds the
> "now we allow replay to take a single tip commit and replay the
> history leading to the tip all the way down to root" feature, the
> note may become relevant.
>
> So to me, it looks like it is either we will never add such a note
> because it is irrelevant and everybody should know the consequence
> of passing "topic", not "main..topic", or we will have to add such a
> note as part of the series (if the note would help the readers).
>
> Even though I am on the fence about the need for this specific note
> in the documentation, it does not make sense to me to say "this will
> help but we are not doing so here".

> Christian Couder <christian.couder@gmail.com> writes:
>
>> So if we are about to fix that main issue in a separate patch or
>> series, and if we plan to emit something like the following in the
>> regular case:
>>
>> "fatal: replaying failed due to conflict"
>>
>> and something like the following when replaying from a root commit:
>>
>> "fatal: replaying from root commit XXX failed due to conflict"
>>
>> then I think it would alleviate the need for a doc update.
>
> Hmph, what would you do to the other side (i.e., replay from some
> specified boundary) of the message?  When the version of "git
> replay" command a user who sees for the first time comes with the
> ability to replay from a root on day one, "from root commit" is not
> so special from "from these boundary commits", so I am not sure if
> it makes sense to have such a message that treats the down-to-root
> case any specially.

> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> Even though I am on the fence about the need for this specific note
>> in the documentation, ...
> ...
> But to summarize: I'm not sure a documentation change is needed, but if
> you insist, I'm attaching a fixup patch (it's based on
> sa/replay-revert). I'm leaving it to Christian an Junio to decide
> whether it should be included. I'm happy to take it to a separate series
> if you consider that a better idea.

>
> Toon Claes <toon@iotcl.com> writes:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> > ...
> >> Even though I am on the fence about the need for this specific note
> >> in the documentation, ...
> > ...
> > But to summarize: I'm not sure a documentation change is needed, but if
> > you insist, I'm attaching a fixup patch (it's based on
> > sa/replay-revert). I'm leaving it to Christian an Junio to decide
> > whether it should be included. I'm happy to take it to a separate series
> > if you consider that a better idea.
>
> As I already said, I am not enthusiastic about the "how about adding
> something like this" Christian gave us and I think we can do without
> it, so I'll leave it up to Christian ;-)