Gitflow: feature finish not doing a --no-ff merge

Hi Scott,

By design, git-flow uses the --no-ff option when merging in order to record that the commits belong together historically. However, when the feature branch contains only a single commit, the extra merge commit does not add anything and only complicates the branch tree needlessly. So for single-commit branches, fast-forward merges are being made as if the commit was done on develop directly.

Cheers,
Vincent

Hi Vincent,

I can definitely understand the thinking behind that design, but I think that the choice of whether the merge commit should be created should be dictated by whether the user chooses to start a feature branch. Sometimes I might do quick changes on the develop branch, but I'll choose to create a feature branch _specifically_ because I want to see the merge commit. I might make only a single commit to a feature branch, but it may not be what I as a user consider to be insignificant enough to warrant disregarding an explicit merge commit.

Ultimately, I think that the choice should be the user's, and I think that the user is expressing a different choice by using a feature branch versus making a quick commit to the develop branch.

Any pointers on where I might go in the code base to make this change in a private form would be very greatly appreciated!

Many thanks for a great tool!
-Scott

This is where the magic happens: https://github.com/nvie/gitflow/blob/develop/git-flow-feature#L310

I'm not going to add an option for making the single-commit feature branches merge explicitly with --no-ff, as I still don't think it adds anything (other than the added complexity of another command line flag), but feel free to make it a private change if you insist on it.

Cheers,
Vincent

Thanks, Vincent! I appreciate the pointer!

Best,
Scott

If I may add my 5 cents,

I very much would like an option to have a merge commit even when finishing one commit features.

In the way I use git flow, my features include in their name the ticket number I'm working on. When I finish a feature I would like very much to see the merge commit specifying the feature name (that includes the ticket number).

This is useful to backtrace every commit to the actual ticket without having to write the ticket number in every commit message.

@DonGiulio Don't know if you've already checked it out, but I'm pretty sure the AVH edition does what you want.

Thanks, I didn't know that, I'll check it out.

I'm also opting for simply adding an option to have single commit no-ff behaviour. It would be nice if you could reconsider this.

(I'm not sure what else is in the AVH edition).

@nvie May I as why?! "_I still don't think it adds anything_"
I honestly thought when bunch of people believe it does add something and some think it doesn't we add an option there somewhere or at least document it so people don't need to find it by trial and error. This can't be such a big decision to make!

If the user went to the trouble of making a feature and chose to do a single commit in it, this means s/he needed it to be that way (say for the sake of visual history keeping) and not to push to the develop directly. I would argue the other way around and ignoring the path the user took doesn't make sense.

Would you be keen to elaborate? We should agree that, not everybody might want to branch off such a solid piece of work because of such minor changes.

@Mehradzie There hasn't been a commit on this repo in 5 years. The AVH edition has been the go-to fork for some time now and is quite stable. I wouldn't hold my breath for a response here, much less a code change.

@jawshooah to be honest I didn't even check the repo name when I ended up here as I was chasing the same issue in SourceTree.
Is gitflow what SourceTree uses to do it's flows? I am a bit confused right now :D
And if so, can it me chop and changes as you suggested to use some other repos' work instead!

@Mehradzie AFAIK SourceTree embeds a slightly modified version of the original nvie version. There are outstanding requests for them to update to the AVH version (see here and here).