Dear Richard, On Sat, Mar 29, 2008 at 10:12:49PM +0100, Richard B. Kreckel wrote:

They all correspond to the same commit on refs/heads/master?

No.

I have no clue what these merges are. How did you find them, anyways?

I was reading email generated by post-receive hook, and noticed this bogus merge:

- Log ----------------------------------------------------------------- commit eb9e62507fb1d2a0d5ddfdfcc2977a57ce40ca21 Merge: 92bef99606b90934ec00043959cace7f4545e533 357698c2ef153870a31d33a9b53a5a01d582f942

Next I ran git whatchanged -m and saw few more. Best regards, Alexei -- All science is either physics or stamp collecting.

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.

Dear Richard, On Wed, Apr 02, 2008 at 10:57:04PM +0200, Richard B. Kreckel wrote:

I still fail to understand what has happened

1. Jens' repository was not up to date. 2. Instead of rebasing his changes onto appropriate branch he merged them with that branch. 3. The merge was not a fast-forward (and could not be a fast-forward for the reasons I've explained in the previous mail). 4. Jens pushed his changes. 5. At this stage your repository is not up to date, and you did one more merge (which was not fast-forfard, and could not be a fast-forward).

and what it means.

We've got several bogus merge commits in the repository. That's not fatal at all. But such merges can make a number of operations (*real* merges, bisecting, etc.) more difficult than necessary. It would be nice to avoid such merges in the future.

What I gathered is that I'll do the fetch/rebase cycle before pushing some patch next time.

OK. Best regards, Alexei -- All science is either physics or stamp collecting.