Bruno Haible <bruno@xxxxxxxxx> writes:
>> If you think "git merge" _copies_, you will never understand what "merge"
>> does. ... There is no copying involved anywhere . It only creates a new
>> commit
>
> There are two cases of "git merge" operation: the one that creates a diamond
> commit, and the one that doesn't (the "simple" case of "git merge"). The latter
> operation I found useful in achieving this surgery:
>
> C---D---E topic
> /
> A---B master
>
> =>
>
> C---D---E topic
> /
> A---B---C---D---E master
If C, D, E on the above two lines are the _same_ commit, i.e. with the
same history and same object IDs, then the picture should instead look
like this:
C---D---E topic
/
A---B master
=>
master
C---D---E topic
/
A---B master@{1}
If that is the case, you drew the picture incorrectly, and it shows the
misunderstanding of your git object model and what a git branch is.
The latter I have already explained to you, but here is a hint.
Do not think of a branch as "the upper line is topic, the lower line
is master". A branch is just a pointer to _a commit_. IOW, in the
picture I drew to correct yours, master and topic point at "E". It
does _not_ point at the line that C, D, and E are on. Similarly,
master@{1} points at the commit "B", not at the line A and B are on.
You claimed that you understand in your response, but judging from the way
you wrote the above picture, I can tell that you don't understand what a
branch in git is. Otherwise you would have drew it like how I did, and
you wouldn't have used the word "copy".
If you instead for some reason _want_ a forked history where C, D and E
are _duplicated_, then you would start from the first picture, fast
forward master to "E", and would force rebase onto B, to end up with
a picture like this.
C---D---E topic
/
A---B---C'--D'--E' master
But there is no reason to do this.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html