Re: [PATCH] format-patch: allow a non-integral version numbers
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 17, 2021, 19:17 UTC
- Message-ID
- <xmqq1rcdvbcn.fsf@gitster.g>
- In-Reply-To
- <YFHsHg/R9la3IwEv@danh.dev>
Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:
Show 10 quoted lines
>> If we were to do this, I would probably suggest a preliminary patch >> that refactors the hardcoded "reroll_count - 1" out of diff_title() >> so that the helper takes two "reroll count strings", i.e. reroll >> count for this round, and the previous round, as two separate >> parameters. Teach the caller to pass "reroll_count - 1" for the new >> parameter in this preliminary step. > > However, if it's only a minor correction to the major version, > I _think_ it makes better sense to compare with the major version > instead of comparing with another minor version.
I wanted to have no opinion on this, as what is expected out of the fractional iteration count by people would be different depending on whom you ask. The "-1" suggestion was a fallback to allow those who supply integral reroll count not to explicitly say what the previous round was from the command line. I do not particularly care how the previous round for fractional iteration count were computed by default when the user did not give one explicitly from the command line.
Show 21 quoted lines
> When a reviewer reviews v3.5, they can just compare to v3. > In a hypothetical world, when another reviewer jump in and a major > change required, v4 reroll also compare with v3. > > In other words, we will have something likes: > > - v3 vs v2 > - v3.1 vs v3 > - v3.2 vs v3 > .... > - v4 vs v3 > > The good side of this approach is: the logic to choose previous > version is simple. > > The downside of this approach is: reviewers need to re-read the > changes in v3.1 v3.2, etc... However, we can reasonably expect those > changes are small enough, they're minor changes after all. > > And they will need to re-read all the change if the major verison was > increased.