[Pharo-dev] Iceberg experience report - synchronising README change made on github
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 "Update class comment" -- edited the class comment, then from Iceberg synchronised, added commit comment and clicked "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 +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 However the same "Updated README" commit still shows in [New commits to be imported] tab, but now its right-click menu item now shows only rather than . So it seem
Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github
> > 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
Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github
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
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 +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
