Can gitflow populate commit messages on finishing features? aka "git merge --log"

[Yves-Eric Martin]

Hi all,

Can gitflow populate the commit messages of the merge commits it does when finishing a feature, similar to what "git merge --log" does?

Bonus: can we also force a non-fastforward merge, like "git merge --no-ff", to keep the fact there was a feature branch there, even though it was a single commit?

The same question came up already on the list but was not answered.

Thanks,

-- 

Yves-Eric

[Yves-Eric Martin]

Sorry for replying to myself.

It was easy to figure out looking at the code: the answer is no, there is no way to do any of these directly.

But it is also trivial to modify the code. If anyone is interested, here is a fork with the folllowing added to all merge operations:

  --log, for more useful log messages of merge commits.

  --no-ff even for single commit feature branches, to preserve these branches existence in history.

Code is at:

  https://github.com/yemartin/gitflow.git

  branch: feature/merge_log_noff

Anyone else thinking it would make sense to have the above as the default behavior?

Cheers,

--

Yves-Eric

[Aseem Kishore]

Great questions.

I don't feel strongly one way or the other over the `git merge --log` behavior (I didn't know of that before) -- having the individual commits' one-liners doesn't seem super helpful to me since they can already be easily seen via `git log`, but it doesn't seem harmful either -- but I *have* on occasion felt it useful/important to actually explain the entire feature via the merge's message. I achieve that by just doing a `git commit --amend` (which I have aliased to `git amend`) after the merge.

In other words, what I found useful was entering a *new* message, that's actually a cohesive summary and explanation, rather than a list of one-liners.

I don't believe that forcing a custom message should at all be the default behavior (just like it's not for a regular `git merge`), but having it as an option might be nice, maybe `-m` (with an optional message passed on the command-line after that).

For the single-commit `--no-ff` feature, I think it'd be a fine option, but I again don't think it should be the default behavior. The primary purpose of `--no-ff` in git-flow (to my understanding) is revertability of a feature. If the feature is a single commit, it's already revertable. And I would say that the single commit's message is a better description of the feature than the branch name, as well.

Great work again!

Aseem