Re: [PATCH 1/2] contrib/subtree: parse using --stuck-long

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Kristoffer Haugsbakk" <kristofferhaugsbakk@xxxxxxxxxxxx> writes:

> On Wed, Jun 4, 2025, at 15:56, Patrik Weiskircher wrote:
>>>
>>> Here we mention "-S", but that flag isn't implemented yet, right?
>>>
>>> Perhaps something like:
>>>
>>>     Optional parameter handling only works unambiguous with git rev-parse
>>>     --parseopt when using the --stuck-long option. To prepare for future commits
>>>     which add flags with optional parameters, parse with --stuck-long.
>>>
>>
>> Makes sense! Changing that. What is a good policy to resubmit
>> something? Should I wait longer? Sorry, very new here!
>
> • Force-push your branch to gitgitgadget
> • Edit the PR description with something like “Changes since v1:” to
>   summarize the changes
> • (`/preview` comment)
> • To send the next version: `/submit` comment again
>
> I think that’s it. :)
>
> I don’t think there’s a need to wait if you don’t want to.

It would be nice for potential reviewers to give at least 24 hours
to ensure people anywhere on the globe have a chance to comment, and
a chance for you to respond to them, before sending your next
iteration.

Also, for future reference, when responding to a review comment that
causes you to drastically change the course of the series, you can
respond whenever you want to, but it is nice to other potential
reviewers to give at least 24 hours to voice their opinions, before
sending an updated series based on that comment, since suggested
changes in such a comment may be controversial and after seeing you
spend some time already to adjust to it, others may feel discouraged
to make you redo your series again even whey they think the
suggested changes are not taking us in the right direction.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux