Re: Possible bug in git-rebase man page

[Phillip Wood <phillip.wood123@gmail.com>]

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.


> 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