gitflow
gitflow copied to clipboard
nvie
feature branch with single commit merged using fast-forward
Hi,
The git-flow-feature has an explicit check around line 310 where it explicitly merges fast forward if the feature branch has one commit in it.
I don't really understand the rationale for this because though it's one commit it's still really useful to know it implemented a particular feature (which a real merge commit acts as the metadata for). It also seems very unaligned with proposed development model.
Happy to offer up a patch to make the --no-ff branch the default.
Thanks, Alex J Burke.
Just found this myself today as well. There was an issue already raised and closed for this here: https://github.com/nvie/gitflow/issues/100 but I agree that it does not match with the development model. Hopefully if enough people make a fuss we can get something changed here. (I'm not savvy enough to make this change privately.)
Started watching both issues. I'm not sure about which way I prefer yet, but an option is almost always better than no option at all, isn't it?
A flag is introduced for this feature in my fork git-flow (AVH Edition) My fork has diverged to much to make this into an easy pull request for nvie's gitflow,
Checkout the changelog for more information about bugfixes and new features implemented in my fork.
One reason for having this flag is a workflow that involves a review process. I would like to be able to annotate the merge request with a ticket number, even when the ticket involved only a single commit. Yes, extra merge commits might add noise in general, but in a workflow like this it's important to track back to a ticket, without having to necessarily edit the commit message itself (since the ticket number may not have been there from the beginning)
I've been very bad at commenting, but aside from my original observation I think many others have contributed their use cases and further justifyied the utility.
As it stands though the thing I am confused about is where to be contributing patches & improvements - with the original git-flow project being seemingly unmaintained and none of the forks blessed as a successor.
For the record I believe the 'AVH' fork included something like this change which was sat behind a flag (I beliee disabled by default), but it also had a late number of various other changes last I checked.
+1 for at least adding an option to let the user force --no-ff even with the branch contains only one commit :+1:
I was struggling today to understand why I didn't had my merge commit and why it suddenly performed a fast-forward, had to wonder what I did wrong etc… until I discovered it was gitflow itself which was doing this without telling me about it.
If I start a quick fix that only takes one commit and I explicitly don't want a merge commit and fast-forward, I simply commit directly on my develop branch. I always did this. If I create a feature branch, even for one commit, that's for that branch to be kept, not to magically disappear (because of the fast-forward) when I merge. If I don't wanted this branch I would have commited directly on develop and wouldn't have created the feature branch from the beginning.
At least please add a flag or config entry to let the user choose which behavior he wishes, instead of unexpectidly disabling the fast-forward on some (understandable but arbitrary) conditions :wink:
My fork git-flow (AVH Edition) has the option to set flags as defaults, that way you can always do a --no-ff without typing it. See the Wiki for more information.
My fork has diverged to much to make this into an easy pull request for nvie's gitflow,
Checkout the changelog for more information about bugfixes and new features implemented in my fork.
@petervanderdoes Thanks.
Actually to be fair I'm not using gitflow command line but SourceTree GUI which seems to use @nvie 's gitflow command line internally. Not sure if I can make SourceTree use an alternate git-flow version/executable and how?
In closing issue #100, @nvie is simply mistaken: he comments that “the extra merge commit does not add anything and only complicates the branch tree needlessly” whereas, in fact, the merge’s comment is the only record left for future generations denoting the fact that (a) a feature branch was created, and (b) what the name of the feature branch actually was. Without an explicit, no-fast-forward merge, the project history completely loses the information that the commit was a branch, and was a feature, at all!
I would be tempted to remove the explicit --ff option from the single commit case. Then, the built-in git merge configuration merge.ff=false can be used to set --no-ff for all merges (including those by flow finish), with the default git configuration replicating the current behaviour.
Any progress on this, I know I'm rehashing an old one but we are seeing no way to use sourcetree to close a feature with it not fast forwarding the merge. There is a setting in the prefs, but it does not seem to respect it
Not documented, and not give a use an option. These type of decisions should be taken on the user's side. Why not to put a little checkbox on the "Finish Release" dialog and if you're really a big fan of this feature let it be ticked by default but since I am not I can go untick it, right?
Every new release, this is the first thing I go check :D and it's never there :/
Just found that there is also a checkbox for this in the preferences. So no need to check it for every branch merge.
