[ANN] Magritte moved to github
Locked
 
|
I moved magritte code today from smalltalkhub to github. I also changed the dependencies of magritte for grease and seaside to be the github repositories and not smalltalkhub.
Please let us work on github for magritte and update smalltalkhub when necessary. Hope you like it! Travis build has also been added. Norbert |
Re: [ANN] Magritte moved to github
|
|
Forgot a link to the repo
|
Re: [ANN] Magritte moved to github
|
Administrator
|
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?! Thanks 1. https://github.com/seandenigris/Magritte3 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
Re: [ANN] Magritte moved to github
|
|
In reply to this post by NorbertHartl
Le 08/08/2018 à 18:46, Norbert Hartl a écrit :
> I moved magritte code today from smalltalkhub to github. I also changed the dependencies of magritte for grease and seaside to be the github repositories and not smalltalkhub. > > Please let us work on github for magritte and update smalltalkhub when necessary. > > Hope you like it! Travis build has also been added. > > Norbert > > Hi Norbert, Thank you. It is great if with this repo we can archive an official magritte repository! Especially if we can get Sean enhancements. -- Cyril Ferlicot https://ferlicot.fr |
signature.asc (836 bytes) |
|
In reply to this post by Sean P. DeNigris
Hi Sean, On 9 August 2018 at 03:00, Sean P. DeNigris <[hidden email]> wrote: NorbertHartl wrote 2. I created a "new_master" branch to merge both histories, based off the best way, but cautioned that the commits will have different SHA's i.e., 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.
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 [hidden email]:magritte-metamodel/magritte.git $ git remote add sean [hidden email]: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 [hidden email]: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 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 [hidden email]:bencoman/magritte.git $ git fetch ben $ git checkout -b rest-rebase ben/rest-rebase HTH, cheers -ben |
Re: [ANN] Magritte moved to github
|
Administrator
|
Ben Coman wrote
> An interesting challenge. I've had a go at it and got it as far as I can > without knowing Magritte. Thanks for the push! Not knowing all that much about git, I tried a different way and seem to have successfully rebuilt the master branch of my fork (https://github.com/seandenigris/Magritte3) on top of the master from the upstream, based on the last shared (content) commit (upstream 51f648b vs fork 47df0a5, both titled "[FIX]: Respect action shortcuts…") In case it helps anyone in the future, here is what I did: 1. Create new branch from upstream master and revert to 51f648b 2. Create git log of commits from fork's first divergent commit (bff9c25 "Dynamic Options…") to HEAD, via git log `47df0a5..eedd386 --pretty=fuller > ../export.txt` 3. For each commit in log: a. `git mv source repository` - temporarily rename "source" (code subfolder from upstream) to "repository" (subfolder from fork) to ease merging b. `git cherry-pick -n $sha1` (where sha1 = e.g. bff9c25) - replay changes without committing c. `git rm -f */methodProperties.json` and then `git rm -f */version` - remove metadata, since upstream commits are metadata-less d. `git reset HEAD` - reset git so it forgets about steps a and c, which are just to conform the fork commits to upstream, but leaves the actual changes in place e. `mv repository/ source` f. `git add -A` - inform git about all changes now that everything is how we want it g. `git commit --date="Sun Mar 25 22:57:40 2018 -0400" -m "Fix #17…" --author="Sean DeNigris <[hidden email]>"`- commit preserving original author and author date The above process was eased by a single Pharo helper class, `GitCommit`, which parsed the log from #2 above into domain objects and created and executed the commands in #3. I used quick and dirty `LibC system:…` messages instead of libgit since I'm a novice and the whole task was a hack. Now my fork's master is branched off upstream master, so hopefully that eases integration of my enhancements. I'm not exactly sure how to proceed from here, so suggestions welcome… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |