Re: [PATCH 5/8] rebase: introduce the --recreate-merges option
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Feb 15, 2018, 16:51 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1802151750250.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
- In-Reply-To
- <87eflmzxjx.fsf@javad.com>
Hi,
On Thu, 15 Feb 2018, Sergey Organov wrote:
Show 28 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > On Tue, 13 Feb 2018, Sergey Organov wrote: > > > >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > >> > >> > The wording is poor either way, but you are also not a native speaker so > >> > we have to rely on, say, Eric to help us out here. > >> > >> Likely, but why didn't you keep original wording from --preserve-merges? > >> Do you feel it's somehow poor either? > > > > Yes, I felt it is poor, especially when --recreate-merges is present, that > > is indeed why I changed it. > > So, how about this (yeah, I noticed the option now got arguments, but > please, tweak this to the new implementation yourself): > > --recreate-merges:: > Recreate merge commits instead of flattening the history. Merge > conflict resolutions or manual amendments to merge commits are > not preserved. > > -p:: > --preserve-merges:: > (deprecated) This option is similar to --recreate-merges. It has > no proper support for interactive mode and thus is deprecated. > Use '--recreate-merges' instead.
I still don't like either.
I want something different there: descriptions that are a bit more self-contained, and only describe the differences to -i or --preserve-merges in a second paragraph.
Don't worry about it, though, I don't think you or me are capable of a good explanation. I will ask some native speakers I trust.
Ciao, Johannes