Re: [Pharo-users] [ANN] Magritte moved to github

[Sean P. DeNigris]

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 "`- 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

Re: [Pharo-users] [ANN] Magritte moved to github

[Ben Coman]

Hi Sean,

On 9 August 2018 at 03:00, Sean P. DeNigris  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.mdsource/

$ 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 r

Re: [Pharo-users] [ANN] Magritte moved to github

[Cyril Ferlicot D.]

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
Description: OpenPGP digital signature

Re: [Pharo-users] [ANN] Magritte moved to github

[Sean P. DeNigris]

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

Re: [Pharo-users] [ANN] Magritte moved to github

[Norbert Hartl]

Forgot a link to the repo

https://github.com/magritte-metamodel/magritte 




> Am 08.08.2018 um 18:46 schrieb Norbert Hartl :
> 
> 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
> 
>