From: Phillip Wood Date: Tue, 11 Apr 2023 09:50:36 GMT Subject: Re: Possible bug in git-rebase man page Message-ID: <53849a41-405c-e488-8c9f-49b211d9a7d4@gmail.com> In-Reply-To: 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