Remi Galan Alfonso <remi.galan-alfo...@ensimag.grenoble-inp.fr> writes:
> Junio C Hamano <gits...@pobox.com> writes: >> The place where an error can be introduced is (assuming that what >> "rebase -i" writes out itself is perfect ;-) where we allow the user >> to edit, so instead of checking before "--continue", I would expect >> a sane design would check immediately after the editor we spawned >> returns. > > Makes sense but we would have the problem mentioned by Matthieu: >> Warning: the command isn't recognized ... >> >> # Hmm, let's ignore that warning >> $ git rebase --continue There's an alternative: $ git rebase --edit-todo # Make mistakes, save and quit Your todo-list has the following issues: - ... Do you want to edit again (no aborts the rebase) [Y/n]? There's a precedent with the 'e' command of "git add -p". I have a slight preference for non-interactive commands so I prefer not going this way though. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
