"Sverre Hvammen Johansen" [off-list ref] writes:
... However, it might take some time. What is the
time-frame for inclusion in 1.5.5?
The 1.5.4 cycle was too long (5 months). A regular interval
ought to be about 3 months but I'd really like to keep 1.5.5
focused on obvious and unanimously supported changes that do not
impact the existing semantics deeply, and keep it shorter than
that.
I think it is too early to tell if this topic falls into that
category. The patch is only a few day old, and there has been
no real discussion nor comments on it yet. I also felt that the
backstory was lacking and it would be hard to judge for people
other than yourself how useful the new ff substrategies are in
what context.
The documentation updates talked about what the options do, but
it was unclear why they could be useful in what situations and
workflows. At least it was not apparent to me on my cursory
read.
--ff=never will turn this off together with fast forward. Maybe we
should have --ff=traditional that is the old behavior.
Sure, and I mildly suspect that it should be the default.
On Feb 4, 2008 12:22 AM, Junio C Hamano [off-list ref] wrote:
The documentation updates talked about what the options do, but
it was unclear why they could be useful in what situations and
workflows. At least it was not apparent to me on my cursory
read.
Common, fork, and path only make sense where there are at least three
repositories or two plus an observer involved.
Lets explain the observer cases.
The observer is interested in changes that X, Y and Z agree upon. He
can merge as follows:
git merge --ff=common X Y Z
The observer is interested in changes up to the point where someone is
known to disagree. He can merge as follows:
git merge --ff=fork X Y Z
The observer is interested in any give path up to one of the true
parents. He can merge as follows:
git merge --ff=path X Y Z
This will give priority to X then Y.
This + only are all the interesting cases for fast forward. Some work
flows between more than two repositories in the general case would
require additional features for rebase: Rebase on any patch, the fork
point, or common ancestor of the remote branches. This is something I
would like to discuss at some later time.
quoted
--ff=never will turn this off together with fast forward. Maybe we
should have --ff=traditional that is the old behavior.
Sure, and I mildly suspect that it should be the default.
I would argue that it should not be the default, simply because we
already use the real parents when only two branches are involved, This
is most convenient for most users. Exactly the same argument holds
when there are more than two branches involved. The history may be
simplified in a similar way. Most projects would however not care
simply because they never merge more than two branches. It is quite
common to have one topic branch that is based on the tip of another
topic branch and if those are merged back to the main branch you would
like it to be reduced down to two real heads (or even a fast forward),
exactly as one branch would result in a fast forward if it happened to
be based on the tip of master.
--
Sverre Hvammen Johansen
"Sverre Hvammen Johansen" [off-list ref] writes:
On Feb 4, 2008 12:22 AM, Junio C Hamano [off-list ref] wrote:
quoted
The documentation updates talked about what the options do, but
it was unclear why they could be useful in what situations and
workflows. At least it was not apparent to me on my cursory
read.
Common, fork, and path only make sense where there are at least three
repositories or two plus an observer involved.
Lets explain the observer cases.
The observer is interested in changes that X, Y and Z agree upon. He
can merge as follows:
git merge --ff=common X Y Z
The observer is interested in changes up to the point where someone is
known to disagree. He can merge as follows:
git merge --ff=fork X Y Z
The observer is interested in any give path up to one of the true
parents. He can merge as follows:
git merge --ff=path X Y Z
This will give priority to X then Y.
Could you please provide ascii-art diagrams for above explanations
(above cases), such as the following diagrams for fast-forward, and
for forced merge (no fast-forward)? This would make your explanations
much easier to follow, I think.
1. Fast-forward ("traditional", 2 heads)
before merge
a---b---c---d <-- main
\
\-E---F---G <-- side
after merge
a---b---c---d---E---F---G <-- main
^
\----- side
2. Forced merge commits ("never", 2 heads)
before merge
a---b---c---d <-- main
\
\-E---F---G <-- side
after merge
a---b---c---d-------------* <-- main
\ /
\-E---F---G <-- side
--
Jakub Narebski
Poland
ShadeHawk on #git