Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github

2018-02-12 Thread Guillermo Polito
On Thu, Feb 8, 2018 at 6:28 AM, Ben Coman  wrote:

> Could the Iceberg gurus try and comment on the following workflow.
>
> Please familiarise with the first four commits here...
> https://github.com/Traadh/cloudflareun/network
>
> from these actions...
>
> "first commit" -- on github I created it as an unitialized repo to try
> to push a "new repo" to it per my other post, but when that failed
> from the command line I did `git init; git add README; git remote ...;
> git push ...`)
>
> "First Pharo code" -- cloned the repo with Iceberg, added a package,
> synchronised, added commit comment and clicked  master>
>
> "Update class comment" -- edited the class comment, then from Iceberg
> synchronised, added commit comment and clicked  master>
>
> "Updated README" -- on github, used the built-in editor to easily
> preview markdown.  Clicked its 
>
>
> PROBLEM...
>
> Now I'm at a point having trouble synchronising Iceberg to pick up
> that last change.
> 1. Right-clicked on "cloudflareun" and chose "Synchronise repository..."
> 2. In [Update] tab, clicked 
> and listed under [commits to be imported] is "Updated README". Good.
> 3. Then clicked on  which I expected would load that commit into
> the Image,
> and a new commit "Merge with ref/remotes/origin/master" showed up in
> [commit to be imported]
>
> So now I'm lost.
> It seems the  only operates on the disk?
> But why does it create a merge commit?
> It should have fast-forwarded.


> Checking from the command line, only shows the first three commits are
> common with the github network graph. The fourth commit is the new
> merge commit.
> $ git log
> commit f49c64a7751f95712acc30dab692fc7e85e0c810
> Merge: c818e9a 52ab6ac
> Author: Ben Coman 
> Date:   Thu Feb 8 11:55:34 2018 +0800
> Merge with refs/remotes/origin/master
>
> commit c818e9adebeb6be001b202aa48da009be97920eb
> Author: Ben Coman 
> Date:   Thu Feb 8 11:42:57 2018 +0800
> Update class comment.
>
> commit 6f2df89b219c56530412252ace96bc95eb78373a
> Author: Ben Coman 
> Date:   Thu Feb 8 11:37:01 2018 +0800
> First Pharo code
>
> commit 52ab6ac696760a60fe56af57e45f2e2ceaaae35e
> Author: Ben Coman 
> Date:   Thu Feb 8 11:31:28 2018 +0800
> first commit
>
> Checking the remote...
> $ git log origin/master
> commit 52ab6ac696760a60fe56af57e45f2e2ceaaae35e
> Author: Ben Coman 
> Date:   Thu Feb 8 11:31:28 2018 +0800
> first commit
>
> Whoops... not what I expected but I don't think that affected anything
> now.  Probably it was left over from early attempts to create a "new"
> "cloudflareun" repo.
>
> Try again...
> $ git remote --v
> origin g...@github.com:Traadh/cloudflareun.git (fetch)
> origin g...@github.com:Traadh/cloudflareun.git (push)
> traadh g...@github.com:Traadh/cloudflareun.git (fetch)
> traadh g...@github.com:Traadh/cloudflareun.git (push)
>
> $ git log traadh/master
> commit 587bed95c4b8fb3986c9962c9206405c81c99e3d
> Author: Ben Coman 
> Date:   Thu Feb 8 11:54:20 2018 +0800
> Updated README
>
> commit c818e9adebeb6be001b202aa48da009be97920eb
> Author: Ben Coman 
> Date:   Thu Feb 8 11:42:57 2018 +0800
> Update class comment.
>
> commit 6f2df89b219c56530412252ace96bc95eb78373a
> Author: Ben Coman 
> Date:   Thu Feb 8 11:37:01 2018 +0800
> First Pharo code
>
> commit 52ab6ac696760a60fe56af57e45f2e2ceaaae35e
> Author: Ben Coman 
> Date:   Thu Feb 8 11:31:28 2018 +0800
> first commit
>
> So there are the four commits matching github.  So it seems that
> Iceberg's FETCH did the right thing updating the remote. But the disk
> working directory should have just fast-forwarded rather than merging.
>
> Now seeing both these commits...
> * Merge with ref/remotes/origin/master
> * Updated README
> in the one [New commits to be imported] seems to be mixing results
> from the working repo and the remote repo in a way that makes it hard
> to guess the consequence of any next action here.
>
> I do see a  option when I right-click on one of those
> commits.
> Perhaps the "load" means to load from the disk working directory into
> the Image(?) but its a bit hidden compared to the  and 
> that are buttons.
> It seems dangerous to take that action right now, since I guess the
> Image would diverge from the disk working directory.
>
>
> FIXING...
>
> What I ended up doing was remove the "merge commit" from the disk
> working directory
> $ git reset --hard HEAD^
>
> then opened a new Iceberg which for [Updates] only showed only the
> single commit  "Updated README" fetched into the remote repo.  Good.
> I right-clicked on that and did  which correctly
> fast-forwarded the disk working directory...
> $ git log
> commit 587bed95c4b8fb3986c9962c9206405c81c99e3d
> Author: Ben Coman 
> Date:   Thu Feb 8 11:54:20 2018 

Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github

2018-02-10 Thread Ben Coman
On 11 February 2018 at 02:28, Stephane Ducasse 
wrote:

> >
> > P.P.S.  I think more thought needs to be given to whether mixing
> > updates from both the remote and disk working directory in the one
> > pane is beneficial?
> > As an alternative, perhaps some side-scrolling GTInspector-like panes
> >Image <--> Working Directory <--> Remote  <--> Server(github)
> > would better represent the git model.
> > Or maybe statically position those panes in one window with buttons on
> > directed lines showing which way and how far a commit moves when that
> > button is pushed.
>
>
> I was saying to esteban that the UI should let the user understand
> where the code is so I like you
>
> >Image <--> Working Directory <--> Remote  <--> Server(github)
>
> Mine was
>
> >Image <--> Local repository <--> Remote
>
> Stef
>
>
Actually the fourth one might be redundant.
The way you find out about the fourth one is you Fetch into the third one.

cheers -ben


Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github

2018-02-10 Thread Stephane Ducasse
>
> P.P.S.  I think more thought needs to be given to whether mixing
> updates from both the remote and disk working directory in the one
> pane is beneficial?
> As an alternative, perhaps some side-scrolling GTInspector-like panes
>Image <--> Working Directory <--> Remote  <--> Server(github)
> would better represent the git model.
> Or maybe statically position those panes in one window with buttons on
> directed lines showing which way and how far a commit moves when that
> button is pushed.


I was saying to esteban that the UI should let the user understand
where the code is so I like you

>Image <--> Working Directory <--> Remote  <--> Server(github)

Mine was

>Image <--> Local repository <--> Remote

Stef