From: Michael J Gruber <git@drmicha.warpmail.net>
To: michael.meeks@novell.com
Cc: git@vger.kernel.org, kendy@novell.com,
Norbert Thiebaud <nthiebaud@gmail.com>
Subject: Re: libreoffice merge(tool?) issue #3 ...
Date: Wed, 23 Feb 2011 12:18:42 +0100 [thread overview]
Message-ID: <4D64ED12.5050802@drmicha.warpmail.net> (raw)
In-Reply-To: <1298398479.32648.184.camel@lenovo-w500>
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
next prev parent reply other threads:[~2011-02-23 11:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 15:34 libreoffice merge(tool?) issue #3 Michael Meeks
2011-02-22 15:55 ` Brian Gernhardt
2011-02-24 16:39 ` libreoffice merge(tool?) issue #3 ... (bogus) Michael Meeks
2011-02-25 10:08 ` Michael J Gruber
2011-02-25 20:55 ` Andres Freund
2011-02-28 14:25 ` copying git repositories Michael Meeks
2011-02-28 15:03 ` Andres Freund
2011-02-28 15:10 ` Brian Gernhardt
2011-02-22 17:30 ` libreoffice merge(tool?) issue #3 Michael J Gruber
2011-02-22 18:14 ` Michael Meeks
2011-02-23 11:18 ` Michael J Gruber [this message]
2011-02-23 13:22 ` Michael J Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D64ED12.5050802@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=kendy@novell.com \
--cc=michael.meeks@novell.com \
--cc=nthiebaud@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).