Re: libreoffice merge(tool?) issue #3 ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Meeks venit, vidit, dixit 22.02.2011 19:14:
> Hi Michael,
> 
> On Tue, 2011-02-22 at 18:30 +0100, Michael J Gruber wrote:
>> I get thousands of conflicts. Have the branches moved since your post?
>> It may be better to give us sha1 or stable tags.
> 
> 	Nope; there are thousands of conflicts; a subset of these are (I would
> like to think ;-) erroneous; but I'm picking out individual files with
> problems that I can repeat easily and that have (I hope) simple history
> to try to isolate the problems for you.
> 
>> Are you doing any builds before merging?
> 
> 	Builds of what ? git - no; LibreOffice - sure, it builds before the
> merge - and then there is a huge slew of work to do to make it build
> afterwards ;-) but then that is not so suprising.

Builds of LO, naturally. The point is that possibly one branch tracks
some build products that the other doesn't track - e.g., autogenerated
make or autoconf stuff etc. (This happens easily when you change your
build chain.) That would lead to a message like that:

> 	Anyhow - thanks for looking at it; can you replicate the suprising
> result in that file: ucb/source/ucp/ext/makefile.mk ? what does
> 'refusing to loose untracked file' mean in that context ?

Say, you build on branch A, that generates an untracked file foo, but
branch B (which you want to merge) tracks that. Merges refuses to
overwrite foo (even though A does not have foo) so that you don't loose
the contents of the untracked file.

But I'm really wondering whether we're merging the same revs. As I
mentioned, I don't see that branch in "stage" that you're merging, only
"stage/ooo/dev300", see below. Also, I'm getting

AA ucb/source/ucp/ext/makefile.mk

which has a somewhat surprising markup (the left side introduces no
change, the right side does - should have a trivial resolution), without
building LO before.

Note that you're merging branches which are way off,

git rev-list --count --left-right
origin/integration/dev300_m98...stage/ooo/dev300
3566    3126

and that the merge base is quite old:

af61642 (#i105937# Fixed a few remaining gradient glitches, 2010-01-16)

The latter explains many of the problems (and the "surprising" above):
compared to the merge base, both branches add
ucb/source/ucp/ext/makefile.mk as a *new* file with different contents,
so that the conflict can't be resolved automatically, and that's how it
is marked up.

Is that merge really what you're after?

Michael

Branches with your recipe:

* integration/dev300_m98
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/feature/bootstrap-build
  remotes/origin/feature/currency-64bit
  remotes/origin/feature/gnumake2.1
  remotes/origin/feature/helppack
  remotes/origin/feature/layout
  remotes/origin/feature/pptx-export-ooxml11
  remotes/origin/feature/rodatastrings
  remotes/origin/feature/sqlite
  remotes/origin/feature/winshrink
  remotes/origin/integration/dev300_m98
  remotes/origin/libreoffice-3-3
  remotes/origin/libreoffice-3-3-0
  remotes/origin/libreoffice-3-3-1
  remotes/origin/master
  remotes/stage/ooo/dev300
  remotes/stage/ooo/dev300_m100
  remotes/stage/premerge/dev300_m98


Michael
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]