Junio C Hamano venit, vidit, dixit 25.02.2015 19:22: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > >> Junio C Hamano venit, vidit, dixit 24.02.2015 19:29: >>> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: >>> >>>>> Hmm, wouldn't it introduce a grave regression for users who >>>>> explicitly ask to clean crufty messages up (by setting their own >>>>> commit.cleanup configuration) if you unconditionally force >>>>> "--cleanup=verbatim" here? >>>>> >>>> >>>> That's what I meant by possible side-effects below. >>>> ... >>>> But git cherry-pick without conflict should no re-cleanup the commit >>>> message either, should it? >>> >>> Hmm, but if it does not, wouldn't that countermand the wish of the >>> user who explicitly asked to clean crufty messages up by setting >>> their own commit.cleanup configuration? >> >> Note that "verbatim" is not the default - we cleanup commits even >> without being asked to. And this makes sense for "git commit", of course. > > I am fine with the result of the updated code if the user does not > have anything in the config and uses the "default". Not touching in > "cherry-pick" would be more desirable than cleaning. We are in > agreement for that obvious case. I didn't know we were. It's clear now. > But your response is sidestepping my question, isn't it? I simply misunderstood it. > What does your change do to the user who wants that the clean-up to > always happen and expresses that desire by setting > commit.cleanup=strip in the config? Doesn't the internal invocation > of "commit --cleanup=verbatim" that is unconditional override it? > Yes, it obviously overrides it. I have to re-check which cleanups rebase does. I hope none. But I would think that to clean up a commit message according to the current config settings, a user should have to "commit --amend" or "rebase -i with reword" explicitly. I still think of rebase and cherry-picks as means to transplant a commit as unchanged as possible. Now, if there are conflicts and the user has to resolve them, they will use "git commit" themselves with their current config in effect. That is to be effected, and the user can use "git commit --cleanup=..." however they want. That leaves the case of "git cherry-pick --edit". I could easily catch that and not overrride config in this case. But the user cannot influence that other than by using "git -c commit.cleanup=... cherry-pick --edit". Hmm. With "--edit", current config being in effect should be expected, right? So how about: In case of no conflict: force cleanup=verbatim unless --edit is used? Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html