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

"Updated README" -- on github, used the built-in editor to easily
preview markdown. Clicked its <Commit directly to the master branch.>

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 <Fetch new versions>
and listed under [commits to be imported] is "Updated README". Good.
3. Then clicked on <Pull> 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 <Pull> 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 <[hidden email]>
Date: Thu Feb 8 11:55:34 2018 +0800
Merge with refs/remotes/origin/master

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 <Merge and load> 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 <Fetch> and <Pull>
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 <Merge and load> which correctly
fast-forwarded the disk working directory...
$ git log
commit 587bed95c4b8fb3986c9962c9206405c81c99e3d
Author: Ben Coman <[hidden email]>
Date: Thu Feb 8 11:54:20 2018 +0800
Updated README

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
<Load> rather than <Merge and load>. So it seem to correctly identify
the disk working directory is up to date but clicking on <Load>
doesn't change anything. Perhaps because there is no Pharo code to
load? Since only the README outside the "src" directory changed?

Moving to the [Push] tab, this shows the four commits seen in the last `git log`
This is confusing since I'd expect this to be empty since...
$ git log > /tmp/x1
$ git log traadh/master > /tmp/x2
$ diff /tmp/x1 /tmp/x2
is empty

SUMMARY
In the end I seem to got done what I needed. I'm enjoying Iceberg
more and more as I rub off the rough edges my understanding it.
Hopefully my report will help smooth things for others.

My only remaining niggle is not being able to get rid of this "1 incoming",
but maybe that will disappear when I've got a code update to upload.

cheers -ben

P.S. It might be if the Iceberg [Remotes] could have a "Log" menu item
that worked like `git log`.

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.

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

>
> 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.

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

"Updated README" -- on github, used the built-in editor to easily
preview markdown. Clicked its <Commit directly to the master branch.>

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 <Fetch new versions>
and listed under [commits to be imported] is "Updated README". Good.
3. Then clicked on <Pull> 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 <Pull> 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 <[hidden email]>
Date: Thu Feb 8 11:55:34 2018 +0800
Merge with refs/remotes/origin/master

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 <Merge and load> 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 <Fetch> and <Pull>
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 <Merge and load> which correctly
fast-forwarded the disk working directory...
$ git log
commit 587bed95c4b8fb3986c9962c9206405c81c99e3d
Author: Ben Coman <[hidden email]>
Date: Thu Feb 8 11:54:20 2018 +0800
Updated README

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
<Load> rather than <Merge and load>. So it seem to correctly identify
the disk working directory is up to date but clicking on <Load>
doesn't change anything. Perhaps because there is no Pharo code to
load? Since only the README outside the "src" directory changed?

Moving to the [Push] tab, this shows the four commits seen in the last `git log`
This is confusing since I'd expect this to be empty since...
$ git log > /tmp/x1
$ git log traadh/master > /tmp/x2
$ diff /tmp/x1 /tmp/x2
is empty

SUMMARY
In the end I seem to got done what I needed. I'm enjoying Iceberg
more and more as I rub off the rough edges my understanding it.
Hopefully my report will help smooth things for others.

My only remaining niggle is not being able to get rid of this "1 incoming",
but maybe that will disappear when I've got a code update to upload.

What version of Pharo/Icerberg are you using?

There is a couple of glitches/bugs in iceberg 0.6.x regarding merges.

- it ignores a commit when a commit only has changes in non smalltalk code (e.g., your README file)

- it creates an extra merge commit in many situations that are not necessary

These two problems should be fixed in the latest development version, where we revised the merge algorithm.

The pull should effectively fast-forward and the commit that only touches the README should be recognized.

Now, I read a separate issue in your email: the pull button does not do the same than the "Merge and Load" button of the last commit. I think that should be fixed also, but I should check.

We should sync with Esteban to see when we can integrate/merge this new version.

cheers -ben

P.S. It might be if the Iceberg [Remotes] could have a "Log" menu item
that worked like `git log`.

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.