Re: Possible bug in git-rebase man page

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Apr 11, 2023, 09:50 UTC
Message-ID: <53849a41-405c-e488-8c9f-49b211d9a7d4@gmail.com>
In-Reply-To: <dda64e68-1390-0b4d-bb93-65f745ab1300@haller-berlin.de>

On 07/04/2023 07:12, Stefan Haller wrote:

> On 06.04.23 14:07, Phillip Wood wrote:

> Ah, I missed that, thanks. But it does this only after special-casing
> the "[new root]" label, which does contain a space and needs to go to
> the end of the line. This is weird.

I think it is by design. Unlike normal labels "[new root]" is not a ref and by choosing a name that is not a valid refname it will never conflict with a normal label.

Show 14 quoted lines

> This whole topic started because the todo parser that we are using in
> lazygit has a bug where it doesn't recognize the "[new root]" label
> properly, and this is because it does split the line at the first
> whitespace, but without special-casing "[new root]" like git does.
> 
> How would you recommend we fix this? We could replicate git's current
> behavior exactly, but then this would break when you introduce comments
> later. Or we could anticipate that comments are added at some point, and
> already split the line at the first # (trimming whitespace before that).
> This would not exactly match git's current behavior, but it would be
> good enough because git never actually uses whitespace in label or reset
> lines except for the "[new root]" case.
> 
> I'm leaning towards the second option myself. Any thoughts?

I'd got for a slight variation of the second one where you just ignore everything after the required arguments for each command just like the reset command does - it does not require the comment to start with a '#', it will accept "reset mylabel this is a comment".

Best Wishes

Phillip

> 
> -Stefan