feature branch with single commit merged using fast-forward #292

Open
alexjeffburke opened this Issue Jan 18, 2013 · 24 comments

Comments

Projects
None yet
@alexjeffburke

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.

@dorner

This comment has been minimized.

Show comment
Hide comment
@dorner

dorner Jan 21, 2013

Just found this myself today as well. There was an issue already raised and closed for this here: #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.)

dorner commented Jan 21, 2013

Just found this myself today as well. There was an issue already raised and closed for this here: #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.)

@Wizek

This comment has been minimized.

Show comment
Hide comment
@Wizek

Wizek Feb 18, 2013

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?

Wizek commented Feb 18, 2013

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?

@petervanderdoes

This comment has been minimized.

Show comment
Hide comment
@petervanderdoes

petervanderdoes Feb 19, 2013

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.

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.

@diversario

This comment has been minimized.

Show comment
Hide comment
@diversario

diversario Aug 20, 2013

Agreed. At least I would like to see the rationale behind this.

Agreed. At least I would like to see the rationale behind this.

@shatskiy

This comment has been minimized.

Show comment
Hide comment
@shatskiy

shatskiy Aug 20, 2013

Agreed - the behavior is not obvious, especially for new git flow users.

Agreed - the behavior is not obvious, especially for new git flow users.

@zkat

This comment has been minimized.

Show comment
Hide comment
@zkat

zkat Sep 20, 2013

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)

zkat commented Sep 20, 2013

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)

@alexjeffburke

This comment has been minimized.

Show comment
Hide comment
@alexjeffburke

alexjeffburke Sep 20, 2013

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.

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.

@alexjeffburke

This comment has been minimized.

Show comment
Hide comment
@alexjeffburke

alexjeffburke Sep 20, 2013

  • late -> large
  • late -> large
@AliSoftware

This comment has been minimized.

Show comment
Hide comment
@AliSoftware

AliSoftware Oct 8, 2013

+1 for at least adding an option to let the user force --no-ff even with the branch contains only one commit 👍

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 😉

+1 for at least adding an option to let the user force --no-ff even with the branch contains only one commit 👍

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 😉

@petervanderdoes

This comment has been minimized.

Show comment
Hide comment
@petervanderdoes

petervanderdoes Oct 8, 2013

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.

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.

@AliSoftware

This comment has been minimized.

Show comment
Hide comment
@AliSoftware

AliSoftware Oct 8, 2013

@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?

@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?

@brandon-rhodes

This comment has been minimized.

Show comment
Hide comment
@brandon-rhodes

brandon-rhodes Oct 29, 2013

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!

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!

@andrew13

This comment has been minimized.

Show comment
Hide comment
@andrew13

andrew13 Jan 3, 2014

It would be nice to have this addressed

andrew13 commented Jan 3, 2014

It would be nice to have this addressed

@petervanderdoes petervanderdoes referenced this issue in petervanderdoes/gitflow-avh Jan 11, 2014

Closed

Remove fast-forward merge in feature finish #140

@SlainVeteran

This comment has been minimized.

Show comment
Hide comment
@SlainVeteran

SlainVeteran Mar 6, 2014

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.

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.

@killerwolf

This comment has been minimized.

Show comment
Hide comment

+1

@skyellin

This comment has been minimized.

Show comment
Hide comment
@skyellin

skyellin Jan 12, 2015

At the very least, it would be nice if this "feature" were documented.

At the very least, it would be nice if this "feature" were documented.

@PLaRoche

This comment has been minimized.

Show comment
Hide comment
@PLaRoche

PLaRoche Mar 15, 2016

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

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

@killerwolf

This comment has been minimized.

Show comment
Hide comment

+1

@zainfathoni

This comment has been minimized.

Show comment
Hide comment

+1

@petervanderdoes

This comment has been minimized.

Show comment
Hide comment
@petervanderdoes

petervanderdoes Aug 13, 2016

See "Is this repository dead? #6340"

See "Is this repository dead? #6340"

@diversario

This comment has been minimized.

Show comment
Hide comment
@diversario

diversario Aug 13, 2016

Turns out you can just use git without this! 😝

Turns out you can just use git without this! 😝

@Mehradzie

This comment has been minimized.

Show comment
Hide comment
@Mehradzie

Mehradzie Feb 15, 2017

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?

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?

@Mehradzie

This comment has been minimized.

Show comment
Hide comment
@Mehradzie

Mehradzie Jun 20, 2017

Every new release, this is the first thing I go check :D and it's never there :/

Every new release, this is the first thing I go check :D and it's never there :/

@mtrezza

This comment has been minimized.

Show comment
Hide comment
@mtrezza

mtrezza Mar 3, 2018

Just found that there is also a checkbox for this in the preferences. So no need to check it for every branch merge.

mtrezza commented Mar 3, 2018

Just found that there is also a checkbox for this in the preferences. So no need to check it for every branch merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment