Re: [PATCH] commit: replace rebase/sequence booleans with single pick_state enum

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jan 20, 2020, 17:09 UTC
Message-ID: <bfe569ea-93c7-382f-18fe-d81d8f9cbf4f@gmail.com>
In-Reply-To: <bb0e232924305697596743d3fa93d5bf3b0e8d4d.camel@nowsci.com>

Hi Ben

[Cc'ing dscho as it relates to issue management on gitgitgadget]

On 18/01/2020 16:34, Ben Curtis wrote:

Show 28 quoted lines

> On Fri, 2020-01-17 at 20:01 +0000, Phillip Wood wrote:
>> Hi Ben
>>
>> On 17/01/2020 13:45, Ben Curtis via GitGitGadget wrote:
>>> From: Ben Curtis <nospam@nowsci.com>
>>>
>>> In 116a408,
>>
>> That commit is no longer in pu, it has been replaced by 430b75f720
>> ("commit: give correct advice for empty commit during a rebase",
>> 2019-12-06). There is now a preparatory commit 8d57f75749 ("commit:
>> use
>> enum value for multiple cherry-picks", 2019-12-06) which replaces
>> the
>> booleans with an enum. I need to reroll the series
>> (pw/advise-rebase-skip) that contains them, if you've got any
>> comments
>> please let me know.
>>
>> Best Wishes
>>
>> Phillip
>>
> 
> Hi Phillip,
> 
> Thank you for the feedback, I assume that means my patch is no longer
> required?

Unfortunately yes

> Also, is there a formal issue assignment method with `git`? I hopped on
> this particular issue on GitGitGadget to get my feet wet here but was
> not sure if there was a separate maintained list to track overlap like
> the above.

Unfortunately there is no formal issue management. There is the mailing list which is where patches are picked up but it does not provide any issue management. In practice when an issue is reported on the list there is either a fix posted relatively quickly or someone notes it down somewhere and may work on it later. There is a convention of adding #leftoverbits to an email in the hope that someone will search for that and find things but I've never seen someone reference that when submitting a new patch and if the fix comes in a different email thread then there's no way to see that the issue has been fixed.

There is gitgitgadet's list of issues but not everyone uses it (and it's only triaged by a small subset of people so there's no guarantee that a feature requested there will be accepted once it gets submitted to the mailing list). If someone posts directly to the mailing list then they probably wont see that there is an issue open there. Further confusion is provided by https://bugs.chromium.org/p/git/issues/list which has a different list of issues.

The best thing would be to check the history of the 'pu' branch before starting work on an issue to see if it has already been fixed.

I'm really sorry that you've had a bad experience, the idea of the gitgitgadget issue tracker is to make it easier for new contributors, not to waste their time. I hope it wont put you off making another contribution.

Best Wishes

Phillip

> Thanks!
> Ben
>