libreoffice merge issue #2 ...

Hi guys,

	So - again, I'm a clueless git user :-) basically the same setup and
reproduction issue as last time, except I'm now purely using (hopefully)
a stable git: version 1.7.3.4

Setup:
        git clone git://anongit.freedesktop.org/libreoffice/libs-core
        git checkout integration/dev300_m98
	git remote add stage git://anongit.freedesktop.org/libreoffice/staging/libs-core
        git fetch stage

Reproduce:
	git merge stage/dev300

	Then have a look at:

	ucb/qa/complex/tdoc/CheckTransientDocumentsDocumentContent.java

	a file that (AFAICS) we have made no change on in our master branch,
but has had a couple of changes in dev300; I see sections like this:

import com.sun.star.ucb.XContent; <<<<<<< HEAD import com.sun.star.ucb.XContentAccess; import com.sun.star.ucb.XContentIdentifier; import com.sun.star.ucb.XContentIdentifierFactory; import com.sun.star.ucb.XContentProvider; =======

	I would expect no conflicts. These conflicts seem to come from a later
commit on the ooo/dev300 branch:

commit 01ed463f7e1ea8b5d290273203386c0a76378c08
Author: Lars Langhans <lla@openoffice.org>
Date:   Tue Jun 8 08:35:09 2010 +0200

    sb123:#i111449# cleanups in ucb qa/complex tests

	yet, this was based on the previous commit:

commit 89f7530c91745d16ab2cb59014c7b1543967e0b4
Author: Jens-Heiner Rechtien <hr@openoffice.org>
Date:   Fri Feb 12 15:01:35 2010 +0100

    changefileheader2: #i109125#: change source file copyright notice
from Sun Microsystems to Oracle; remove CVS style keywords (RCSfile,
Revision)

	That is present (although clearly with a different hash) in both
repositories.

	So if I have a branch with commits A -> F and master has commits A -> D
- (and nothing else) I would expect merging that branch to yield state
'F' without conflicts; but most likely I'm missing something, and
perhaps there is some subtle (whitespace related?) difference that I do
not see.

	Of course, this is not the only instance I see of this sort of thing,
but hopefully it is a reasonably simple one, for a file with only a
handful of commits.

	Kendy - do you think this could be caused by the application of the
de-tab-ification logic ? or do you apply that for every change ?

	Thanks,

		Michael.