This is the mail archive of the
mailing list for the binutils project.
Re: git problems/question
- From: Fred Cooke <fred dot cooke at gmail dot com>
- To: Christian Groessler <chris at groessler dot org>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Fri, 30 Sep 2016 08:41:05 +1300
- Subject: Re: git problems/question
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
One approach you could try is to make your changes committing each
distinct one in sequence where they belong, then cherry pick them in
sequence onto the target base version.
Merging divergent branches is always going to be a pain when both
sides touched the same files due to backports etc. I didn't check, but
from what I've seen of binutils dev style, the base 2.23 was likely
already branched off of trunk prior to being tagged, so it's probably
similar to 2.23.2 in that respect.
What i would likely do is this:
git checkout -b mynewbase `git merge-base 2.23.2 2.27` # only your
changes can conflict, now
<make changes and commit in sensible chunks>
git rebase 2.27 # abort if necessary, retry etc
This might work well for you, depending on what changes happened on
To ease that, and get your changes gradually closer to 2.27 you can
rebase onto intermediate points in the line between your base and your
target after reviewing the intermediate history of the files you
touched in that series of commits. For example:
You have 10 commits to rebase, but you know commit 6 is a big conflict
that will be tricky. Rebase to commit 5 first, validate your state is
good. Then repeatedly attempt rebase onto 6 until you're happy, then
take the final step to the end if the rest of the road is clear.
Good luck! :-)
On Fri, Sep 30, 2016 at 7:53 AM, Christian Groessler
> I'm maintaining a local architecture, where our code is based on 2.23.2,
> I want to update it to 2.27.
> My general idea is:
> 1) checkout 2.23.2 (tag "binutils-2_23_2")
> 2) create a new branch from here
> 3) add our changes
> 4) merge 2.27
> This doesn't work. I'm getting many conflicts.
> So I made a test, omitting step 3 from above, and using 2.23 instead of
> $ git clone ssh://sourceware.org/git/binutils-gdb.git
> ... (downloading) ...
> $ git checkout -b test-branch binutils-2_23
> Switched to a new branch 'test-branch'
> $ git merge binutils-2_27
> ... (getting many conflicts) ...
> $ git status
> ... (many changed files)... and:
> Unmerged paths:
> (use "git add/rm <file>..." as appropriate to mark resolution)
> deleted by us: .gitignore
> both modified: ChangeLog
> both modified: Makefile.in
> both modified: bfd/ChangeLog
> both modified: bfd/Makefile.am
> both modified: bfd/Makefile.in
> both modified: bfd/archures.c
> both modified: bfd/bfd-in2.h
> both modified: bfd/config.bfd
> both modified: bfd/configure
> deleted by them: bfd/configure.in
> both added: bfd/cpu-aarch64.c
> added by them: bfd/development.sh
> ... (many more) ...
> I would have expected a few conflicts, for sure, since both 2.23 and 2.27
> are from branches. But they seem to be too many to me.
> Also, many of the conflicts are gdb related, which aren't important here. Is
> there an easy way to get rid of them?
> Does anyone have a good idea how I could accomplish my task without manually
> checking a huge number of files for conflicts/changes?