[GiNaC-devel] (git) spurious merges

[Alexei Sheplyakov]

Hello,

On Tue, Apr 01, 2008 at 10:27:55AM +0200, Jens Vollinga wrote:

> > These merges 
> > 
> > 83a7ee99a947cbbf331018b803ad6be43a9ccd45
> > eb9e62507fb1d2a0d5ddfdfcc2977a57ce40ca21
> > 357698c2ef153870a31d33a9b53a5a01d582f942
> > 
> > look really strange (as in "this should not happen"). What's going on?
> 
> I've no idea. When I pushed something into git Richy had already done 
> some changes there (and vice versa), so I had to pull first.

A better way is to fetch the "official" code and rebase your changes onto
that, i.e.

git fetch origin
git rebase origin
git push origin

There are also different methods (google for 'git avoiding merge commits').

> I don't know why this merge was not fast-forward.

\begin{quote}
Fast-forward merges
-------------------

There is one special case not mentioned above, which is treated
differently.  Normally, a merge results in a merge commit, with two
parents, one pointing at each of the two lines of development that
were merged.

However, if the current branch is a descendant of the other--so every
commit present in the one is already contained in the other--then git
just performs a "fast forward"; the head of the current branch is moved
forward to point at the head of the merged-in branch, without any new
commits being created.
\end{quote}

Hope this helps,
	Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20080401/6a1bd719/attachment.sig