Re: [PATCH v3 00/12] Finish converting git bisect to C part 2

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

 



Miriam Rubio <mirucam@xxxxxxxxx> writes:

> --- Changes since v2 Finish converting git bisect to C part 2 patch series ---
>
> General changes
> ---------------
>
> * Rebase on master branch: efe3874640 (Sync with v2.26.1, 2020-04-13)

Was there a particular reason why you needed to do this rebase?  It
seems that the patches apply cleanly on the same base as v2 has been
queued?  Does the result cause hard-to-resolve conflicts when merged
to the 'master', 'next' or 'pu' branches unless you do that rebase?

> Specific changes
> ----------------
>
> [1/12] bisect--helper: fix `cmd_*()` function switch default return
>
> * Use `BUG()` instead of `return error()` in default switch.

This rings a bell.  range-diff looks good.

> [2/12] bisect--helper: use '-res' in 'cmd_bisect__helper' return
>
> * New patch: use '-res' instead of 'abs(res)'.

Alright.

> [3/12] bisect--helper: introduce new `write_in_file()` function
>
> * Rename input parameter `filepath` to `path`.
> * Change `error_errno()` to `error()` in mode checking.
> * Change error message when file cannot be opened.
> * Add `fclose()` before error return.

OK.  I am not sure if the error behaviour when fclose() fails is
ideal, but I do not think it is worth further polishing.

> [4/12] bisect--helper: reimplement `bisect_autostart` shell function in C
>
> * Reorder patch before `reimplement `bisect_next` and `bisect_auto_next`
> shell functions in C` to use `bisect_autostart()` function in 
> `bisect_append_log_quoted()`.

OK.

Will take a look at individual patches later.

Thanks.



[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