empty commits

[Mathieu Arnold]

Hi,

I've been playing with gitflow quite a bit for a few days, and first, I'd
like to say that I find it very good.

Now, I have question, when merging branches, it does the merge with
--no-ff, which generates an empty merge commit.

Now, I don't see any good reason for it to be so, I mean, gratuitous empty
commits in my history hurt my eyes :-)

So, for my questions, what exactly is the point of doing such an empty
commit ? And would it be possible not to do so ?

Regards,

--
Mathieu Arnold

[Vincent Driessen]

Hi Mathieu,

Thanks for trying out git-flow. The empty merge commit you are talking about is there for a very deliberate reason. It is discussed in the original branching model blog post. It's mainly about not losing historical information. For a more in-depth discussion, please look under the heading "Incorporating a finished feature on develop" on http://nvie.com/posts/a-successful-git-branching-model/ (sorry, no permalink to the paragraph there).

Hope that clarifies the intentions.

Cheers,

Vincent

[Mathieu Arnold]

+--On 2 février 2011 19:56:49 +0100 Vincent Driessen <vin...@datafox.nl>
wrote:

| Hi Mathieu,
|
| Thanks for trying out git-flow. The empty merge commit you are talking
| about is there for a very deliberate reason. It is discussed in the
| original branching model blog post. It's mainly about not losing
| historical information. For a more in-depth discussion, please look under
| the heading "Incorporating a finished feature on develop" on
| http://nvie.com/posts/a-successful-git-branching-model/ (sorry, no
| permalink to the paragraph there).
|
| Hope that clarifies the intentions.

Ok, it does, thank you.

But, as I was more likely to do rebase than merge so that I did not have
extra commits, do you think it would be possible to have the possibility to
have a mode in git-flow where the merge --no-ff were replaced with a rebase

[Vincent Driessen]

Hi Mathieu,

You could use feature rebase for that purpose:

$ git flow feature rebase

That rebases the current feature branch onto develop.

Cheers,
Vincent

[Mark Derricutt]

Vincent,

That however keeps the feature branch open ( use that command often - love it ), but my reading of this was that Mathieu more wanted to rebase the feature onto develop and delete the feature brach.

Effectively the same of "feature finish", but with a rebase instead of a merge, so that you only have a linear revision history, rather than a diverging/rejoining path of commits.

As it is currently, you'll still get the merge commit after a rebase.

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree

[Mathieu Arnold]

+--On 4 février 2011 01:07:09 +1300 Mark Derricutt <ma...@talios.com> wrote:
| Effectively the same of "feature finish", but with a rebase instead of a
| merge, so that you only have a linear revision history, rather than a
| diverging/rejoining path of commits.

And not only for feature but also release or hotfix or... :-)

--
Mathieu Arnold

[Alexander Sorokin]

You can always use plain git to do all the magic.

The point of gitflow is to make sure the merge history is preserved.
Specifically, if you must revert the changes, you won't need to track
down individual commits.

I love rebasing and squashing feature branches to make them easier to
understand, but I try to avoid --ff merges to develop/master branches.

Cheers!
Alex

[Vincent Driessen]

Hi Mathieu, Mark,

Don't forget that there exists a -r flag to the finish command, which rebases instead of merges when finishing. I think this is what you are looking for.

The option was broken for a while, due to a flag parsing bug, but it should work again on the latest develop.

Cheers,

Vincent