Re: git merging

[Peter Rosin]

Den 2009-01-24 15:25 skrev Ralf Wildenhues:
> > Just as a minor note, it would not have been necessary to create a
> > separate branch for each single ChangeLog entry.  You could have done
> > them all on one pr-fix-changelog-entries branch.  :-)
> > But it really doesn't matter much.
>
> Ahh, I didn't look properly.  You used one branch only, renamed it a few
> times, and merged it several times.  This is all fine and well, but it
> highlights one data point you may not be aware of:

No, I actually used four branches. I think you are reading the graph wrong,
each of those four branches with a ChangeLog addition are based on the commit
which it adds the ChangeLog entry for. I did it that way because I
though it might be easier to revert the tail of those patches that way
(they were never approved). But those merges make everything depend on each
other anyway, so that was pretty futile to begin with.

So yeah, it was overkill to make four branches. I will let the dent
in the graph be a reminder that I should be more carefull about what I
push...

> "git merge" merges not just the tip of some branch, it adds all changes
> which are in the to-be-merged-branch into the current branch.  More
> precisely, if you look at the directed graph of change history, then it
> picks all changes from the branch for which there is no (directed) path
> to the current branch tip yet.  This is why criss-cross merges work, and
> this is one of the distinctive features you won't find in most other
> version control systems.
>
> Just thought I'd mention it.

I realized that the whole branch was merged when I experimented with the
pr-tests-newline-fixes branch, and this was the reason I decided to base
that branch on the common ancestor.

Cheers,
Peter