I've been reading the excellent Pro Git book to gain an understanding of git actions, however there is one scenario illustrated which I cannot understand from what the book is saying.
In the section on Basic Branching and Merging, under the heading Basic Merging, the following example is given.
The before state is this:
* master
C0 --- C1 --- C2 --- C4
\
--- C3 --- C5
* iss53
A merge is then performed of iss53 into master resulting in this.
* master
C0 --- C1 --- C2 --- C4 ------- C6
\ /
--- C3 --- C5
* iss53
This is a good result for the master branch as it now includes the work done on the iss53 branch. Or, in other words, master contains 'everything'.
However, there is talk in various parts of the book about "long running" branches. If iss53 were intended to be such a branch, I see a problem in that further change on that branch does not include anything from the master branch after C2 and so further work is (theoretically) necessitated on future merges.
From reading other questions, the apparent answer is to subsequently merge in the other direction, which would fast-forward iss53 to C6 from where it can once again diverge.
Furthermore, if C4 had not existed at the time of the original merge, it would (by default) have simply fast-forwarded master to C5 which negates the need for the reverse merge.
So these situations have me questioning whether to accept fast-forward merges as a time saving and always reverse-merge non-fast-forwards, or whether there is value in mandating --no-ff and the reverse merge simply for consistency.
Are there reasons not to do the reverse merge, and consequently, perhaps, to always use --no-ff?
As I stated at the beginning, I am just trying to understand git at this stage. I do not have a specific scenario I am working with. I'm still formulating an approach.
