Hi Jake, On Tue, 13 Feb 2018, Jacob Keller wrote: > On Mon, Feb 12, 2018 at 11:15 PM, Sergey Organov <sorganov@xxxxxxxxx> wrote: > > > > Jacob Keller <jacob.keller@xxxxxxxxx> writes: > > > >> On Mon, Feb 12, 2018 at 12:39 PM, Johannes Schindelin > >> <Johannes.Schindelin@xxxxxx> wrote: > >>> > >>> On Mon, 12 Feb 2018, Sergey Organov wrote: > >>>> > Have a look at https://github.com/git/git/pull/447, especially the > >>>> > latest commit in there which is an early version of the deprecation I > >>>> > intend to bring about. > >>>> > >>>> You shouldn't want a deprecation at all should you have re-used > >>>> --preserve-merges in the first place, and I still don't see why you > >>>> haven't. > >>> > >>> Keep repeating it, and it won't become truer. > >>> > >>> If you break formats, you break scripts. Git has *so* many users, there > >>> are very likely some who script *every* part of it. > >>> > >>> We simply cannot do that. > >>> > >>> What we can is deprecate designs which we learned on the way were not only > >>> incomplete from the get-go, but bad overall and hard (or impossible) to > >>> fix. Like --preserve-merges. > >>> > >>> Or for that matter like the design you proposed, to use --first-parent for > >>> --recreate-merges. Or to use --first-parent for some --recreate-merges, > >>> surprising users in very bad ways when it is not used (or when it is > >>> used). I get the impression that you still think it would be a good idea, > >>> even if it should be obvious that it is not. > >> > >> If we consider the addition of new todo list elements as "user > >> breaking", then yes this change would be user-script breaking. > > > > It _is_ user script breaking, provided such script exists. Has anybody > > actually seen one? Not that it's wrong to be extra-cautious about it, > > just curios. Note that to be actually affected, such a script must > > invoke "git rebase -p" _command_ and then tweak its todo output to > > produce outcome. > > > >> Since we did not originally spell out that todo-list items are subject > >> to enhancement by addition of operations in the future, scripts are > >> likely not designed to allow addition of new elements. > > > > Out of curiosity, are you going to spell it now, for the new todo > > format? > > > >> Thus, adding recreate-merges, and deprecating preserve-merges, seems > >> to me to be the correct action to take here. > > > > Yes, sure, provided there is actual breakage, or at least informed > > suspicion there is one. > > > >> One could argue that users should have expected new todo list elements > >> to be added in the future and thus design their scripts to cope with > >> such a thing. If you can convincingly argue this, then I don't > >> necessarily see it as a complete user breaking change to fix > >> preserve-merges in order to allow it to handle re-ordering properly.. > > > > 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. Remember how rewriting parts of rebase -i in C broke somebody's script because the todo list was not re-read after a successful `exec`? Guess three times why that script was broken? Precisely: it modified the todo list! To see the fix (and the explanation) in all its glory, just have a look at 54fd3243dae (rebase -i: reread the todo list if `exec` touched it, 2017-04-26). And even if we did not know about any user. What does that mean? Does it mean that there is no such user? Or does it not rather mean that our imagination is rather limited, but we *still* should practice safe software development and use the totally appropriate vehicle of deprecating, rather than replacing, functionality? Obviously, the latter option is what I favor, that's why I suggested it in the first place. Ciao, Dscho
