git-flow-feature-finish should allow fast-forward merges #203

Open
jgonggrijp opened this Issue Mar 15, 2012 · 2 comments

Comments

Projects
None yet
3 participants
@jgonggrijp

Currently, git flow feature finish will always merge with --no-ff, even if you explicitly specify that you want to rebase with the -r flag. This is completely backwards, because rebase is very often used for short topic branches exactly in order to keep the history clean by enabling a fast-forward.

When I want to rebase and fast-forward I can't do this:

$ git flow feature finish -r <name>

Instead, I have to run this kludge:

$ git flow feature rebase
$ git checkout develop
$ git merge feature/<name>
$ git branch -d feature/<name>

Users should at least be able to control this behaviour with an additional flag to flow-feature-finish, and preferably also with a configuration setting. Personally, I think flow-feature-finish -r should default to merging with --ff.

@Diablo-D3

This comment has been minimized.

Show comment Hide comment
@Diablo-D3

Diablo-D3 Mar 30, 2012

I feel dirty +1ing on in a github comment, but +1 anyways. I think empty merge commits in a log are a dirty and ugly thing that should be avoided at all costs. Git flow flow tries to avoid bad git behavior in my opinion, and this would only improve git flow's day to day usage.

I feel dirty +1ing on in a github comment, but +1 anyways. I think empty merge commits in a log are a dirty and ugly thing that should be avoided at all costs. Git flow flow tries to avoid bad git behavior in my opinion, and this would only improve git flow's day to day usage.

@vaz

This comment has been minimized.

Show comment Hide comment
@vaz

vaz May 14, 2012

I would agree that the option should be there for those who would prefer a straight-line history, but I don't think it should be the default.

The merge --no-ff is by design, if you re-read the original article it explains the rationale. It lets you very quickly see a grouping of commits that make up a single feature. Especially if you rebase the feature branch before merging it, then you have a nice, very short-lived branch that doesn't really clutter it up (imo).

I still think the option should be there, just not that the default should change.

vaz commented May 14, 2012

I would agree that the option should be there for those who would prefer a straight-line history, but I don't think it should be the default.

The merge --no-ff is by design, if you re-read the original article it explains the rationale. It lets you very quickly see a grouping of commits that make up a single feature. Especially if you rebase the feature branch before merging it, then you have a nice, very short-lived branch that doesn't really clutter it up (imo).

I still think the option should be there, just not that the default should change.

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