Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

2 messages, 2 authors, 2018-02-15 · open the first message on its own page

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

From: Sergey Organov <hidden>
Date: 2018-02-15 04:35:15

Hi Johannes,
Johannes Schindelin [off-list ref] writes:

[...]
quoted
quoted
I'd not argue this way myself. If there are out-of-git-tree non-human
users that accept and tweak todo _generated_ by current "git rebase -p"
_command_, I also vote for a new option.
To be fair, I have not seen anything that actually reads the todo list
and tweaks it in such a manner. The closest example is the git garden
shears script, which simply replaces the todo list.

It's certainly *possible* that such a script would exist though,
We actually know of such scripts.
Please consider to explain this in the description of the change. I
believe readers deserve an explanation of why you decided to invent new
option instead of fixing the old one, even if it were only a suspicion,
more so if it is confidence.

-- Sergey

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

From: Johannes Schindelin <hidden>
Date: 2018-02-15 16:50:15

Hi,

On Thu, 15 Feb 2018, Sergey Organov wrote:
Johannes Schindelin [off-list ref] writes:

[...]
quoted
quoted
quoted
I'd not argue this way myself. If there are out-of-git-tree non-human
users that accept and tweak todo _generated_ by current "git rebase -p"
_command_, I also vote for a new option.
To be fair, I have not seen anything that actually reads the todo list
and tweaks it in such a manner. The closest example is the git garden
shears script, which simply replaces the todo list.

It's certainly *possible* that such a script would exist though,
We actually know of such scripts.
Please consider to explain this in the description of the change. I
believe readers deserve an explanation of why you decided to invent new
option instead of fixing the old one, even if it were only a suspicion,
more so if it is confidence.
I considered.

And since even the absence of this use case would *still* not be a
convincing case against keeping --preserve-merges backwards-compatible, I
will not mention it.

Just saying that --preserve-merges is not changed, in order to keep
backwards-compatibility, is plenty enough.

It probably already convinced the Git maintainer, who is very careful
about backwards-compatibility, and rightfully so.

Ciao,
Johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help