On Thu, Aug 10, 2017 at 11:55 AM, Pavel Krivanek <pavel.kriva...@gmail.com>
> currently we are fighting with several issues that make contributions to
> Pharo 7 much more complicated than we would like. Even in case you have no
> troubles with long paths (on Windows) nor SSH keys, it is now not easy now
> to start to contribute or review pull requests.
> Let's say you already have:
> - a Github fork of pharo-project/pharo repository
> - a local clone of pharo-project/pharo repository on your disk
> - this repository has a 'remote' pointing to your fork that is named by
> your GitHub user name
> During bootstrap the Iceberg registers a repository from which the image
> was bootstrapped and binds Monticello working copies history to it. This
> repository is hidden by default, to see it in the repositories list you
> need to enable Iceberg setting named 'Include system repositories by
> default'. If you will do it, you will see that this repository is red. You
> need to manually set the real path to you local clone (Edit).
> Then you should set your fork as default push target (in Iceberg: select
> 'pharo' repository - 'Remotes' tab - context menu on your fork remote -
> Make default push remote).
> It is good to synchronize your fork with the origin so it will contain
> recent commits on the development branch. You can do it by doing PULL from
> the origin (pharo-project/pharo) and PUSH to your fork. The alternative is
> to create a pull request from the original repository to your fork in the
> GitHub web interface and then let merge it)
> The next optional step is to checkout the particular commit hash from
> which the image was bootstrapped. It is optional because the Iceberg now
> supports cherry picking so you can avoid of committing changes you do not
> want. But to start your branches from a state when the image working copy
> is in sync with the git working copy is of course cleaner.
> Currently the bootstrapped image has some packages that are marked as
> dirty and it will make mess if you will try to commit your changes. You can
> avoid it by reloading of these dirty packages. This will be not needed in
> All these steps you can automatized by the following code. You need to at
> least customize your repository clone path and GitHub user name. It is
> supposed to be run only once on freshly downloaded Pharo 7 image.
> | location userName pharoRepository fork |
> location := '/path/to/your/pharo/repository'.
> userName := 'github-user-name'.
> Iceberg showSystemRepositories: true.
> pharoRepository := IceRepository registry detect: [ :each | each name =
> 'No name' ].
> pharoRepository location: location asFileReference.
> fork := pharoRepository remotes detect: [ :remote | remote remoteName =
> userName ].
> pharoRepository pushRemote: fork.
> pharoRepository pullRemote: pharoRepository origin.
> pharoRepository checkoutBranch: 'development'.
pharoRepository backend pullFrom: pharoRepository origin.
Take into account this particular two lines can break your working copy if
you have uncommited changes.
> pharoRepository push.
> pharoRepository checkoutBranch: (SystemVersion current commitHash).
> [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded
> and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning do:
> [ :warning | warning resume: true ]
And this is a patch because bootstrapped images have 3 dirty packages. We
should just fix the issue instead of patching it.
In any case, I vote to put this in the Pharo plugin in iceberg.
> As the result you should get a clean image based on the latest code that
> is ready to to create or review pull requests.
> -- Pavel
French National Center for Scientific Research - *http://www.cnrs.fr*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13