asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yingyi Bu <>
Subject Re: Integrating the folder change and package change into topic branches
Date Fri, 28 Aug 2015 22:06:39 GMT
I tried Chris' method but the format-patch (step 1) somehow doesn't seem to
give me the right patch --- maybe it's because I have created multiple
Gerrit CLs on the branch --- though the earlier CLs were merged, they seem
to go into the generated patch anyway...

I slightly modified Chris' steps and it works for me now:

1. On your local master,  manually revert the master to the commit (Till's)
before the packaging change, by:
git reset --soft HEAD~1
Do that iteratively until the head is Till's commit (using "git log" to
check that).
git reset --hard #clear all staged files

(After you reset, an annoying file
"asterix-app/src/test/resources/AQLTS/queries/IfThenElse.aql" will show up,
just commit it temporarily...  It seems the file has some OS-dependent
formatting issue and "git checkout" couldn't clear it...)

2. Switch to your branch and merge master.  That makes your branch good up
to Till's commit.
    Then, generate a diff between your branch and master, using Chris'
    git diff master your_branch| perl -pe 's#edu(.)uci.ics#org\1apache#g' >

3. Now fetch the new master, and create a new local branch from it:
   git checkout master
   git reset --soft HEAD~1 #revert the temporary commit for
   git pull
   git checkout -B newbranch

4. Apply your tweaked patch:

   patch -p1 /tmp/my.patch

Resolve conflicts as usual and that's it:-)


On Thu, Aug 27, 2015 at 4:28 AM, Chris Hillery <>

> Hey - I've been working on integrating my "clean JSON" changes, which is
> kind of the perfect catastrophe to try and merge with the org.apache
> package change. In the JSON branch I had done a lot of moving Java files
> from one package to another, so I had a bunch of git "renames"
> (adds/deletes) as well as a bunch of import changes related to them. And
> they all produced merge/rebase conflicts.
> I've found a workaround, though! By getting git to give you a textual patch
> and tweaking it, you can rebase any number of changes onto the new master
> seamlessly. Here's how:
> 1. On your local branch, find the *parent* of the first commit you want to
> migrate onto the new master. If you were fully up-to-date before the
> repackaging commits went in, this will be Till's
> change 95350e253f3462b1fb8d08396b4fddadaa33bf53, so I'll use that here.
> 2. Run this magic command:
>    git format-patch --stdout 95350e253f3462b1fb8d08396b4fddadaa33bf53 |
> perl -pe 's#edu(.)uci.ics#org\1apache#g' > /tmp/my.patch
> 3. Now fetch the new master, and create a new local branch from it:
>    git switch master; git pull; git checkout -B newbranch
> 4. Apply your tweaked patch:
>    git am /tmp/my.patch
> That's it! If this produces any sort of merge conflicts, you might try
> again "rebasing" onto commit f18bba2 instead (that is, in step 3, do "git
> checkout -B newbranch f18bba2") - that way you'll *only* pick up the
> mechanical edu.uci.ics -> org.apache changes, none of the later ones.
> Hope that helps someone,
> Ceej
> aka Chris Hillery
> On Tue, Aug 25, 2015 at 9:31 AM, Ian Maxon <> wrote:
> > Hi all,
> > With the last few patches that have been submitted, integrating them back
> > into all of our open topic branches may be a little more complex than
> > usual.
> >
> > In the simplest case, if you have a change that doesn't add .java files
> nor
> > edit import or package statements, 'git gerrit update' should just work
> > without complaint or conflict. If you do have changes of that type, 'git
> > gerrit update' will still work, but you'll have to resolve the rebase
> > conflict.
> >
> > If you use merge typically instead of 'git gerrit update' or rebase to
> pull
> > in new changes, you should take extra caution. Just a plain 'git merge'
> > will most likely create many ugly conflicts when it attempts to merge
> both
> > the path renaming change, and the package renaming change, at once. The
> > work around for this is to merge them one at a time (e.g. in asterix, git
> > merge 34d8163 for the path renaming change, and git merge f18bba26 for
> the
> > package rename). In the first step you'll have to move any java files you
> > created with a folder under edu/uci/ics to org/apache, and in the second
> > resolve all the conflicts related to imports and package naming. If in
> the
> > last step there are a lot of conflicts, sometimes it is easier to merge
> > while taking your local changes first, and then re-doing the package
> change
> > from edu.uci.ics to org.apache with sed on the affected files, instead of
> > trying to resolve them all one by one.
> >
> > In short, you run into a really bad merge conflict,  please don't
> hesitate
> > to ask for advice about it here. Hopefully the above advice is helpful,
> but
> > every situation is unique.
> >
> > Thanks,
> > -Ian
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message