Taewoo, I agree with Ildar now, after exploring both for a long time. The patch trick was breaking a lot of stuff without me realizing it until afterwards. The trick is, for files that you moved, you need to do the following three steps after merge:
1) git rm --cached on the file from master 2) git add on the renamed file on your branch 3) git mv the file from your branch to the appropriate folder (one level deeper) This is mostly scriptable. I have 130 files with moves/renames and this took me less than half of an hour. Steven On Thu, Apr 14, 2016 at 12:11 PM, Ildar Absalyamov < [email protected]> wrote: > Taewoo, > > I believe Steven’s patch method will not work if you were using merge to > get master’s changes into your branch. You would have to do interactive > rebase and move all your changes as if they were applied on top of master, > which I found to be a lot of work by itself. > Actually I would refrain everyone from using patch method, since it’s > error-prone (simple search and replace). > > I do think the method proposed by Ian (which uses merge) is the best one > can do in this situation. Yes, it will generate conflicts (especially if > you moved files in your topic branch), but I found that conflict resolution > was more of less scriptable. > > > On Apr 14, 2016, at 11:31, Taewoo Kim <[email protected]> wrote: > > > > Hello Steven, > > > > I tried to use Ian's straightforward method and it generated a few > hundred > > conflicts since I touched a lot of test files. I tried to go through one > by > > one and it took long time. So, I want to explore your method, too. The > one > > thing that I don't understand on your method is "finding the parent". Is > > that the last commit of the master branch that was merged into my local > > branch? Thank you. > > > > Best, > > Taewoo > > > > On Mon, Apr 4, 2016 at 1:12 PM, Steven Jacobs <[email protected]> wrote: > > > >> It seems that I might be the only one concerned here, but it seems like > >> there should be others, so I am continuing this thread. > >> > >> I modified the perl REGEX from Chris' summer solution, and it works! > >> > >> Once Ian has merged master: > >> > >> 1. On your local branch, find the *parent* of the first commit you want > to > >> migrate onto the new master, e.g. > de6e0da24c26037967eb9a937d2c77c6c43e8761 > >> > >> 2. Run this magic command: > >> > >> git format-patch --stdout de6e0da24c26037967eb9a937d2c77c6c43e8761 | > >> perl -pe 's#asterix-#asterixdb/asterix-#g' > /tmp/my.patch > >> > >> 3. Now fetch 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 > >> > >> > >> This recognized ALL of my file moves/renames and applied them > correctly. It > >> leaves only two issues: > >> 1) Something similar will probably need to be done for Hyracks changes > >> 2) My pom changes didn't apply. This isn't so bad since there are only a > >> few pom files total. > >> > >> > >> I hope this helps, > >> Steven > >> > >> > >> > >> > >> On Fri, Apr 1, 2016 at 11:31 AM, Steven Jacobs <[email protected]> > wrote: > >> > >>> Here is Chris's original solution to give context. I think changing the > >>> REGEX might be enough to re-use the solution: > >>> > >>> 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 > >>> > >>> > >>> Steven > >>> > >>> On Fri, Apr 1, 2016 at 11:07 AM, Steven Jacobs <[email protected]> > wrote: > >>> > >>>> I've tried doing this now on my branch. > >>>> As I feared, all of the files that are renamed/moved become conflicts > >>>> (just a few hundred conflicts in my case 😑). > >>>> I'm wondering if we could use a similar technique for what we did > during > >>>> the summer (for the apache change) to get around this. > >>>> > >>>> Steven > >>>> > >>>> On Fri, Apr 1, 2016 at 9:40 AM, Till Westmann <[email protected]> > wrote: > >>>> > >>>>> I’m not sure I completely understand what you are saying. Is this a > >>>>> temporary state that will get cleaned up later or is this supposed to > >>>>> stay this way (having "-fullstack" in the names)? > >>>>> > >>>>> Thanks, > >>>>> Till > >>>>> > >>>>> > >>>>> On 31 Mar 2016, at 19:39, Ian Maxon wrote: > >>>>> > >>>>> I'm not sure if it was necessary to rename it, but the original issue > >> is > >>>>>> that the hyracks repo itself has a folder named hyracks, that > contains > >>>>>> hyracks. I thought this might confuse git if I did something like > >> make a > >>>>>> new temporary folder, move everything into that, and then rename it > to > >>>>>> 'hyracks'. > >>>>>> > >>>>>> On Thu, Mar 31, 2016 at 6:35 PM, Till Westmann <[email protected]> > >>>>>> wrote: > >>>>>> > >>>>>> Interesting! > >>>>>>> > >>>>>>> One thing I’m wondering about is why you’ve added "-fullstack" to > the > >>>>>>> artifactId and the hyracks module. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Till > >>>>>>> > >>>>>>> > >>>>>>> On 31 Mar 2016, at 17:21, Ian Maxon wrote: > >>>>>>> > >>>>>>> I've gone ahead and tried merging my topic branch with this change, > >>>>>>> and it > >>>>>>> > >>>>>>>> turned out surprisingly well. I really didn't have many issues. > I'll > >>>>>>>> summarize the process: > >>>>>>>> > >>>>>>>> 1) Merge the change from asterixdb with your topic branch checked > >>>>>>>> out, so > >>>>>>>> just 'git merge hyracks-merge2'. > >>>>>>>> The only real conflict should be the pom, if you altered that. I > >>>>>>>> found it > >>>>>>>> easiest to just replicate my changes and take the upstream, rather > >>>>>>>> than > >>>>>>>> trying anything funny, since usually pom changes are not major. > >>>>>>>> > >>>>>>>> 2) Add your hyracks folder as a remote (for me, 'git remote add > >>>>>>>> hyracks-local file:///home/...') > >>>>>>>> > >>>>>>>> 3) Merge your hyracks topic branch into asterixdb ( ' git merge > >>>>>>>> hyracks-local/imaxon/hdfs') > >>>>>>>> This also worked pretty well, the only extra hiccup besides the > pom > >>>>>>>> was > >>>>>>>> files I had created. Those appeared at the top level again after > the > >>>>>>>> merge. > >>>>>>>> But, all you have to do is move them back down one folder into > >>>>>>>> hyracks-fullstack. > >>>>>>>> > >>>>>>>> That's about it really. I went ahead and pushed this up to github > as > >>>>>>>> well > >>>>>>>> so if anyone would like to take a look at the process or check out > >> the > >>>>>>>> branch to see what happened (at least for me), the branch is here: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >> > https://github.com/parshimers/incubator-asterixdb/tree/imaxon/hdfs-plus-hyracks > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> -Ian > >>>>>>>> > >>>>>>>> On Wed, Mar 30, 2016 at 6:17 PM, Ian Maxon <[email protected]> > wrote: > >>>>>>>> > >>>>>>>> Chris found an issue with the way git histories were being handled > >> in > >>>>>>>> the > >>>>>>>> > >>>>>>>>> way I merged things, so I have revised the proposed branch: > >>>>>>>>> > >>>>>>>>> > >> > https://github.com/parshimers/incubator-asterixdb/commits/hyracks-merge2 > >>>>>>>>> > >>>>>>>>> Basically I was trying to fit everything into one commit, > because I > >>>>>>>>> thought at first that I could submit it to Gerrit that way. > However > >>>>>>>>> that > >>>>>>>>> doesn't work for other reasons, basically Gerrit tries to treat > >>>>>>>>> every new > >>>>>>>>> commit from Hyracks as a new change. Splitting the commits of the > >>>>>>>>> repository merge fixes the issue. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> @Till, I think that creating a textual patch would just be more > >>>>>>>>> work. If > >>>>>>>>> I > >>>>>>>>> were to do it that way I would try fetching the Gerrit patch, and > >>>>>>>>> then > >>>>>>>>> cherry-picking it onto a new branch that has the hyracks+asterix > >>>>>>>>> master > >>>>>>>>> as > >>>>>>>>> the head. > >>>>>>>>> > >>>>>>>>> On Wed, Mar 30, 2016 at 5:42 PM, Till Westmann <[email protected] > > > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> To get existing patches in, could we just create a textual patch > >>>>>>>>> (e.g. > >>>>>>>>> > >>>>>>>>>> from gerrit), apply that with the necessary -p option to a new > >> local > >>>>>>>>>> checkout of the merged repositories and submit a new review to > >>>>>>>>>> gerrit? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Till > >>>>>>>>>> > >>>>>>>>>> On 30 Mar 2016, at 12:36, Ian Maxon wrote: > >>>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>>> I went ahead preliminarily merged the Hyracks and AsterixDB > >>>>>>>>>>> repositories > >>>>>>>>>>> into one. Unfortunately this can't be reviewed in Gerrit so you > >>>>>>>>>>> all can > >>>>>>>>>>> check it out here: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >> > https://github.com/parshimers/incubator-asterixdb/tree/imaxon/merge-hyracks > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> You will likely have to do some ugly rebasing for whatever > >> changes > >>>>>>>>>>> you > >>>>>>>>>>> might have open once this gets done, since it moves asterixdb > >> down > >>>>>>>>>>> one > >>>>>>>>>>> folder and swaps out pom.xml in the repository root. Hyracks is > >> in > >>>>>>>>>>> a > >>>>>>>>>>> similar situation, though you would want to reapply your change > >> to > >>>>>>>>>>> the > >>>>>>>>>>> AsterixDB repo from Hyracks (which is a bit odd). If you would > >>>>>>>>>>> like to > >>>>>>>>>>> > >>>>>>>>>>> see > >>>>>>>>>> > >>>>>>>>>> how this affects your branch please do try fetching the branch I > >>>>>>>>>>> linked > >>>>>>>>>>> above and testing it out on a copy of your topic branch. > >>>>>>>>>>> > >>>>>>>>>>> I'm still making sure all of the tests pass but nothing's > failed > >> so > >>>>>>>>>>> far. > >>>>>>>>>>> Unless anyone has objections I think we should push this change > >>>>>>>>>>> either > >>>>>>>>>>> > >>>>>>>>>>> this > >>>>>>>>>> > >>>>>>>>>> week or early next week. > >>>>>>>>>>> > >>>>>>>>>>> Let me know what you all think. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> - Ian > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>> > >>> > >> > > Best regards, > Ildar > >
