On Mon, May 20, 2019 at 8:49 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > On Mon, May 20 2019, Matheus Tavares wrote: > > > Hi, Ævar > > > >> Give "rebase -i" some option so when you "reword" the patch is > >> included in the message. > >> > >> I keep going to the shell because I have no idea what change I'm > >> describing. > > > > I have the same problem, so I wanted to try solving this. The patch > > bellow creates a "rebase.verboseCommit" configuration that includes > > a diff when rewording or squashing. I'd appreciate knowing your thoughts > > on it. > > > > As Christian wisely pointed out to me, though, we can also achieve this > > behavior by setting "commit.verbose" to true. The only "downside" of it > > is that users cannot choose to see the diff only when rebasing. Despite > > of that, if we decide not to go with this patch, what do you think of > > adding a "commit.verbose" entry at git-rebase's man page? > > Thanks for working on this. I'd somehow missed the addition of the > commit.verbose option, so the problem I had is 100% solved by it (and > I've turned it on). > > I think it's better to just document it with rebase, perhaps rather than > mention that option specifically (but that would also be fine) promise > that we support "commit" options in general. Indeed, it seems to be the right way to go. > Do we promise anywhere that interactive rebase is going to run the > "normal" git-commit command. From a quick skimming of the docs it > doesn't seem so, perhaps we should explicitly promise that, and then > test for it if we don't (e.g. by stealing the tests you added). Ok, sounds good to me. In order to avoid duplicate tests, is it OK to assume that if one commit configuration is being respected by rebase, then all will be? Or should a patch adding such a promise include rebase tests for all commit.* configurations?
