From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:05
merlyn@stonehenge.com (Randal L. Schwartz) writes:
Junio implemented a 7-line patch on the IRC channel (calling parts of it
"for randal" or something, I believe :) to do precisely this.
Perhaps you can test it, and submit it as if it were your idea. I, for one,
would use it as well. I'm doing ugly things with parsing the output of
git-status right now to achieve the same thing.
The mechanism itself is simple.
http://git.pastebin.com/m156a1856
A sane integration is a different story.
We have --ff and --no-ff options to merge. How should this new
option --ff-only mesh with them? Perhaps we would want to have
an option --ff that takes three values?
--ff=never
--ff=normal
--ff=only
and have the first one be synonym for existing --no-ff, the second
one to be a synonym for not giving anything (or giving --ff
explicitly), and the third one to be this new mode of operation?
On Jan 16, 2008 12:31 PM, Junio C Hamano [off-list ref] wrote:
A sane integration is a different story.
We have --ff and --no-ff options to merge. How should this new
option --ff-only mesh with them? Perhaps we would want to have
an option --ff that takes three values?
--ff=never
--ff=normal
--ff=only
and have the first one be synonym for existing --no-ff, the second
one to be a synonym for not giving anything (or giving --ff
explicitly), and the third one to be this new mode of operation?
Thanks for the patch. I can probably look into it tonight and do the
suggested integration and test it out, I keep you posted.
--
Sverre Hvammen Johansen
I know that the patch you wrote is not good. However, it is a good
starting point.
We need to consider cases where the branch we are merging with is an
ancestor or an descendant of HEAD. The patch only take descendants
into account. There may also be more than one branch we are merging
with. All these cases must be considered. In the case of an octopus, the
cases are slightly more complicated.
I have a patch that work for all cases except for some octopus cases. I
have written a few test case. All existing tests succeeds.
I will not be able to work on this for a few days, but I expect to have a
working patch some time this weekend.
I have not looked at the documentation but assume it should not be to
hard to add some documentation as well.
--
Sverre Hvammen Johansen
On Jan 16, 2008 10:53 PM, Sverre Hvammen Johansen [off-list ref] wrote:
We need to consider cases where the branch we are merging with is an
ancestor or an descendant of HEAD. The patch only take descendants
into account. There may also be more than one branch we are merging
with. All these cases must be considered. In the case of an octopus, the
cases are slightly more complicated.
I have been testing octopus merges and figured it is not very smart with
respect to fast forward. I would like it to do a fast forward whenever it
makes sense to do that. Consider the following:
-- c1 -- A
/ / \
c0 -- c2 -- C
\ \ /
-- c3 -- B
A is a merge between c1 and c2, B is a merge between c2 and c3, and C is a
merge between A and B.
c1 merged with A does a fast forward to A, A merged with C does a fast forward
to C, but an octopus merge of c1 with A and C does not fast forward to
C. I would
expect it to fast forward to C. The commit graph above have several other cases
where an octopus merge can be reduced to a fast forward or a recursive merge.
I suggest a separate pass before we choose merge strategy. Remove commits
that can be fast forwarded to any of the other commits from the
equation and fast
forward the current branch if possible. The remaining commits are then taken
into consideration. This may reduce the number of commits and thus result in
a fast forward or another merge strategy.
I intend to make the patch for the option --ff-only as simple as
possible, where it
will fail where more than two commits are involved. If the above suggested pass
is implemented it should also take affect for --ff-only.
Does this make sense?
--
Sverre Hvammen Johansen