Hi Sean, On 9 August 2018 at 03:00, Sean P. DeNigris <s...@clipperadams.com> wrote:
> NorbertHartl wrote > > https://github.com/magritte-metamodel/magritte > > I'm trying to get my fork [1] back in sync with the upstream now that > you've > ported the code there. > > Conceptually, I'd like to replay the changes in my Magritte fork on top the > last commit that is content-equivalent between the two. After some digging, > this appears to be the upstream's commit `51f648b`, which is equivalent to > the fork's `47df0a5` (both titled "[FIX]: Respect action shortcuts if > specified. Otherwise, default to t…") > > This is the process I've followed so far. Feedback appreciated. > 1. I created an "original_master" branch to preserve the fork's original > history. Maybe this is not necessary long-term? 2. I created a "new_master" branch to merge both histories, based off > upstream/master > 3. I reverted that branch to the shared base commit, `51f648b` > 4. I started a `cherry-pick 47df0a5..eedd386`. A few SO threads said this > is the best way, but cautioned that the commits will have different SHA's i.e., > A..D will become A'..D'. Maybe this is a good thing if we want to preserve > the original history as well (although do we, see #1 above)? OTOH, issues > that referenced commits will now point to old_master, and not master… > > On step #4, I've run into merge hell due to metadata. I guess I committed > at > that time with metadata and upstream is metadata-less. How do I dig myself > out without manually approving each file for potentially hundreds of > commits?! > An interesting challenge. I've had a go at it and got it as far as I can without knowing Magritte. I think the remaining conflicts are legitimate and need manual intervention. > > Thanks > > 1. https://github.com/seandenigris/Magritte3 TLDR; You can see the result here... https://github.com/magritte-metamodel/magritte/network Here we go, clone upstream, add your repo as a remote, and check which commits are in which branches. $ git clone g...@github.com:magritte-metamodel/magritte.git $ git remote add sean g...@github.com:seandenigris/Magritte3.git $ git fetch sean $ git log --grep='Respect action shortcuts' ==>51f648b... $ git log --remotes=sean --grep='Respect action shortcuts' ==>47df0a5... $ git checkout 51f648b -b target $ ls ==> README.md source/ $ git checkout 47df0a5 -b cleanup $ ls ==> README.md respository/ So each branch storing the files in two different directories, I don't see how anything can be automatically merged or even cherry picked like this. To get an idea of the problem need both folders to exist at the same time... $ cp -r repository .. $ git checkout newform $ diff -qr source/ ../repository/ | grep differ | head ==>Files source/Magritte-ContactManager.package/CMAddress.class/properties.json and ../repository/Magritte-ContactManager.package/CMAddress.class/properties.json differ The difference here is the order of fields and the curly brace on its own line, To cleanup of these file... $ find ../repository/ -name "properties.json" -print -exec rm {} \; $ diff -qr source/ ../repository/ | grep differ | head indicates cleanup for .filetree files... $ find ../repository/ -name ".filetree" -print -exec rm {} \; $ diff -qr source/ ../repository/ | grep differ | head now has no output. good. no conflicting files, but what other meta-files need to be cleaned up... $ diff -qr source/ ../repository/ | grep "Only in ../repository/" $ find ../repository/ -name "methodProperties.json" -print -exec rm {} \; $ diff -qr source/ ../repository/ | grep "Only in ../repository/" $ find ../repository/ -name "version" -print -exec rm {} \; $ diff -qr source/ ../repository/ | grep "Only in ../repository/" now has no output, so lets double check new stuff only remains in target... $ diff -qr source/ ../repository/ only shows "Only in source/" items which we will keep. So get our cleanup into a commit... $ git checkout cleanup $ rm -r repository $ cp -r ../repository . $ git add -A $ git commit -m "Removed meta data to match upstream" $ mv repository source $ git add -A $ git commit -m "Renamed source folder to match upstream" On github, I forked the repo then added it here as a remote $ git remote add ben g...@github.com:bencoman/magritte.git $ git push ben cleanup $ git branch cleanupmerge $ git checkout cleanupmerge $ git merge target and since that was successful... $ git push ben cleanupmerge Now here https://github.com/bencoman/magritte/network it shows there are 66 commits in your 'master' added after 47df0a5, which is where I branched 'cleanup' from. I am guessing the way to go is to first rebase those onto the 'cleanup' commit, then merge that result into 'cleanupmerge' commit. The trouble is, that while the files moved to 'source' folder and meta-files deleted in 'cleanup' should carry through, any newly introduced files will reintroduced the 'repository' directory and associated meta-files. For example... $ git checkout -b rest-rebase sean/master $ git rebase cleanup rest-rebase $ git status ==> Changes to be committed: new file: repository/Magritte-Model.package/Collection.extension/instance/maAllOptionsFor..st new file: repository/Magritte-Model.package/Collection.extension/instance/maSelectMatching..st new file: repository/Magritte-Model.package/MADynamicOptions.class/README.md new file: repository/Magritte-Model.package/MADynamicOptions.class/class/block..st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/block..st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/block.st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/includes..st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/maAllOptionsFor..st new file: repository/Magritte-Model.package/MADynamicOptions.class/instance/maSelectMatching..st new file: repository/Magritte-Model.package/MADynamicOptions.class/methodProperties.json new file: repository/Magritte-Model.package/MADynamicOptions.class/properties.json modified: source/Magritte-Model.MetaGUI.package/MAOptionDescription.class/instance/allOptions.st Unmerged paths: deleted by us: repository/Magritte-Model.package/Collection.extension/methodProperties.json deleted by us: repository/Magritte-Model.package/MAOptionDescription.class/methodProperties.json deleted by us: repository/Magritte-Model.package/monticello.meta/version The 'modified: source...' line is a positive sign, showing that previous 'cleanup' changes are tracking forward for existing files. All the other lines refer to new files, confirmed by counting them... $ find repository/ -type f | wc -l ==> 14 So for each individual commit is rebased, we need to do the same cleaning steps as above. After some experimentation I came up with this script... $ vi /tmp/clean find repository/ -name "properties.json" -print -exec rm {} \; find repository/ -name ".filetree" -print -exec rm {} \; find repository/ -name "methodProperties.json" -print -exec rm {} \; find repository/ -name "version" -print -exec rm {} \; cd repository cp -r . ../source/ cd .. rm -r repository git reset # ignore files auto-staged by rebase. i.e. make git status empty git add -A git status # show us what we'll be committing I'm still in the middle of the rebase, so now alternate doing the following two lines until the rebase is completed... $ sh /tmp/clean $ rebase --continue I could tell when it was finished when the output matched your current 'master' HEAD. > Applying: Added builders to Magritte-Seaside, so components are builded > Applying: [Enh]: Add `#fieldDescription` and also `git branch` indicated I was back on the... * rest-rebase branch rather than in the middle of rebasing. Now committing & pushing (since I like github graphical network view https://github.com/bencoman/magritte/network) $ git commit -m "Finished rest-rebase" $ git push ben rest-rebase And merge this into 'cleanupmerge' and then merge with the upstream 'master' (creating a new branch only to help the flow be visible on github insights) $ git branch rest-merge $ git checkout rest-merge $ git merge cleanupmerge which looks good. But... $ git merge master throws up some conflicts. However these look legitimate. e.g. diff -r master-source/Magritte-Model.MetaGUI.package/MADescription.class/instance/descriptionLabel.st rest-rebase-source/Magritte-Model.MetaGUI.package/MADescription.class/instance/descriptionLabel.st 8c8 < default: self class defaultLabel; --- > default: self defaultLabel; I don't know how to get `git diff` to do what I want, so.... $ cp -r source ../rest-merge-source $ git checkout master $ cp -r source ../master-source $ cd .. $ diff -qr master-source/ rest-rebase-source/ | grep "differ" | wc -l ==> 44 $ diff -qr master-source/ rest-rebase-source/ | grep "Only in rest-rebase" | grep "\.st" | wc -l ==>58 $ diff -qr master-source/ rest-rebase-source/ | grep "Only in rest-rebase" | grep -v "\.st" | wc -l ==> 22 $ diff -qr master-source/ rest-rebase-source/ | grep "Only in master-source" | grep -v "\.st" | wc -l ==> 465 Whoops. I notice that 'master' has a lot of 'properties.json' files and I killed all the ones in 'rest-rebase'. Was I bit over-zealous there? Anyway, perhaps you can take it from there. To pull my updates. $ git remote add ben g...@github.com:bencoman/magritte.git $ git fetch ben $ git checkout -b rest-rebase ben/rest-rebase HTH, cheers -ben
