I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo. I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork. Maybe even... 3. Issue a pull request to the original repository. cheers -ben
Actually you can , there was even a tool for Pharo that uses the github api to do most common git actions, github api does not need git installed because it does everything online. Alternatively you can use GitHub web GUI , you will have to be added to the repo as contributor though to have the required permissions to do commits, push and pulls , it should work also for pull requests . In the case of a pull request you won't need to be a contributor to the repo but you will have to fork it. Of course you can do that via github api, it's actually very powerful. You need git installed only to version control locally on your hard drive. But if you are fine with working online , the github api should be enough. You can learn more about it in the github website at the help section. On Fri, 22 Jul 2016 at 06:57, Ben Coman <btc@openinworld.com> wrote:
I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository.
cheers -ben
On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository.
This is indeed the idiomatic way to contribute on GitHub. 1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request Maybe IceBerg (https://github.com/npasserini/iceberg) could have some nice interface for this eventually. Peter
cheers -ben
Ah yes that's the tool. Generally speaking if you plan to contribute to the repo very frequently being a contributor will allow you to commit directly since in most cases you will be familiar with the repo and know what you doing. I see a pull request as a way to moderate commits by people that cannot be trusted or that are not regular contributors. In case of a pull request it's the workflow that Peter describes but I prefer an addition step, open an issue or link your request to an issue. It make tracking pull requests easier and cleaner. On Fri, 22 Jul 2016 at 10:12, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository.
This is indeed the idiomatic way to contribute on GitHub.
1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request
Maybe IceBerg (https://github.com/npasserini/iceberg) could have some nice interface for this eventually.
Peter
cheers -ben
On Fri, Jul 22, 2016 at 07:19:09AM +0000, Dimitris Chloupis wrote:
I see a pull request as a way to moderate commits by people that cannot be trusted or that are not regular contributors.
No. The purpose of pull request is to discuss and review the code. Code reviews should be done whether you are regular contributor or not, because it's valuable for both the code base, and all people involved. Furthermore if you have CI properly configured, then it can execute tests on the pull request so you know the code is healthy. Of course if you work alone or have this is a fun OSS side-project, then no rules apply. Peter
No. It may surprise you but pull requests having nothing to with code review, they are just a formality. To understand pull requests you have to understand character of the person that created git, Linus , the man behind Linux. He is not exactly the most easy going person, and he wanted a VCS that isolated developers rather than bringing together under one roof as SVN is doing. Its not very suprising when you consider the size and complexity of Linux kernel and his not so polite character. Furthermore a pull request offers no practical advantage other than isolation, you can review any commit done directly to the repo and revert back the commits you dont like and open a discussion about it in the issue tracker. Github also offer several other tools, like comments on commits , gist for easy pasting of experimental code etc etc And what makes pull request ever less uselful are branches, git already offers a form of isolation, you can create your own branch in the repo that wont affect the master branch, you can open then a discussion on the issue tracker and you or some other merge the branch to the master branch. Usually master branch is the unstable version anyway , an additional stable branch is usually created for the end users. Also pull requests come with a big disadvantage , fragmentation. Because they lead to the creation of forks . That is not a problem by itself when the fork only contains a handful of commits but a fork can easily deviate without issuing any pull request back to main repo. Its similar to Squeak / Pharo situation, the fork becoming more popular than the main repo. And in the case on Squeak/Pharo is fine because the fork is only one, but a trip to github disneyland will reveal a hell of forks especially for popular repos. This can easily lead to "a war of forks". Pull request essentially offer the advantage of isolation , when you have hundred of developers trying to commit to the project you need some way to keep the ones that you are not familar with out, this is why all very big projects in github use pull requests but also have main contributors. For much smaller projects say 5-10 people its not neccessary, since most likely they will work in branches anyway and because merging to master will be followed after a discussion in the issue tracker. On Fri, Jul 22, 2016 at 11:17 AM Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 07:19:09AM +0000, Dimitris Chloupis wrote:
I see a pull request as a way to moderate commits by people that cannot be trusted or that are not regular contributors.
No.
The purpose of pull request is to discuss and review the code. Code reviews should be done whether you are regular contributor or not, because it's valuable for both the code base, and all people involved.
Furthermore if you have CI properly configured, then it can execute tests on the pull request so you know the code is healthy.
Of course if you work alone or have this is a fun OSS side-project, then no rules apply.
Peter
On Fri, Jul 22, 2016 at 09:57:37AM +0000, Dimitris Chloupis wrote:
No.
It may surprise you but pull requests having nothing to with code review, they are just a formality.
To understand pull requests you have to understand character of the person that created git, Linus , the man behind Linux.
Pull request is not a git concept and has nothing to do with git. It's an abstraction over merge.
easy going person, and he wanted a VCS that isolated developers rather than bringing together under one roof as SVN is doing.
Git was not the first DVCS; Linus & co. merely adopted system they were already using.
Furthermore a pull request offers no practical advantage other than isolation, you can review any commit done directly to the repo and revert back the commits you dont like and open a discussion about it in the issue tracker.
This is factually false. Pull request is a group of interrelated commits, so while you can review individual commits, for anything larger than a bugfix reviewing individual commits is a waste of time. It's much easier to track changes and fixes after code reviews with a pull request.
And what makes pull request ever less uselful are branches
Pull requests and branches are complementary.
Also pull requests come with a big disadvantage , fragmentation. Because they lead to the creation of forks .
Is this your first encounter with _distributed_ version control systems? Forks are fundamental aspect.
the fork only contains a handful of commits but a fork can easily deviate without issuing any pull request back to main repo. Its similar to Squeak / Pharo situation, the fork becoming more popular than the main repo. And in the case on Squeak/Pharo is fine because the fork is only one, but a trip to github disneyland will reveal a hell of forks especially for popular repos. This can easily lead to "a war of forks".
I don't see any problem here, it's OSS and people have different opinions, so forks are natural resolution. People often fork on github because they can or because they want to experiment with something, but there is no "war of forks". Running large OSS is resource-intense so common forks cannot and do not compete (e.g. bootstrap has 44000 forks, but none of them competes), And if they do compete then it's usually on fundamental opinion differences, or systemic problems that are best addressed with forks (e.g. lodash vs underscore). There is no problem with the fork surpassing it's predecessor, the community benefits from it in the long-term. Many different forks can be a pain for small under-maintained projects, because a fork can much more easily have an impactful change â so it's easy to have two or three forks with each having a different important feature. On the other hand due to it's small-scale, it can also usually be also resolved. If the original dev does not have the time and resources to manage it (which is too common since a lot of OSS are side-projects), then forks are inevitable.
Pull request essentially offer the advantage of isolation , when you have hundred of developers trying to commit to the project you need some way to keep the ones that you are not familar with out, this is why all very big projects in github use pull requests but also have main contributors. For much smaller projects say 5-10 people its not neccessary, since most likely they will work in branches anyway and because merging to master will be followed after a discussion in the issue tracker.
We've successfully used pull requests in my previous company for years even on two-man projects, because they _can_ and do provide value. If you don't see it, or they are not valuable to you that's fine (Which can be easily true if you are a single dev/hobby programmer), but claiming that they are useless is just bullshit. Peter
On Fri, Jul 22, 2016 at 11:17 AM Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 07:19:09AM +0000, Dimitris Chloupis wrote:
I see a pull request as a way to moderate commits by people that cannot be trusted or that are not regular contributors.
No.
The purpose of pull request is to discuss and review the code. Code reviews should be done whether you are regular contributor or not, because it's valuable for both the code base, and all people involved.
Furthermore if you have CI properly configured, then it can execute tests on the pull request so you know the code is healthy.
Of course if you work alone or have this is a fun OSS side-project, then no rules apply.
Peter
On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository.
This is indeed the idiomatic way to contribute on GitHub.
1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request
That is how you do it if you *already* know you want to be contribute to an application or package. But what if I was just planning to *use* an application or package, only later I ended up tracing down a bug to that application and fixed it. What is the *easiest* for me to push to my personal github account from where I make the Pull Request. Something like this [1] from within Pharo (disclaimer, I've not performed these action before, I had to hunt a bit to find it as an example)... [1] https://gist.github.com/jagregory/710671
Maybe IceBerg (https://github.com/npasserini/iceberg) could have some nice interface for this eventually.
Thanks for the link. This will be interesting to watch. cheers -ben
First you open a bug report , then you do what Peter said and you attach your pull request to that bug report. Github will do most of this for you , the only tricky part is to add the remote so each time you do git pull you pull also from the original repo. Generally you should use as much as you can of the github GUI , it will make your life much easier. If all you want is provide a bug fix , pull requests are tailor made for such scenario. Is there a particular problem you have with this ? On Fri, 22 Jul 2016 at 16:16, Ben Coman <btc@openinworld.com> wrote:
On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository.
This is indeed the idiomatic way to contribute on GitHub.
1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request
That is how you do it if you *already* know you want to be contribute to an application or package. But what if I was just planning to *use* an application or package, only later I ended up tracing down a bug to that application and fixed it. What is the *easiest* for me to push to my personal github account from where I make the Pull Request. Something like this [1] from within Pharo (disclaimer, I've not performed these action before, I had to hunt a bit to find it as an example)...
[1] https://gist.github.com/jagregory/710671
Maybe IceBerg (https://github.com/npasserini/iceberg) could have some nice interface for this eventually.
Thanks for the link. This will be interesting to watch.
cheers -ben
On Fri, Jul 22, 2016 at 09:14:25PM +0800, Ben Coman wrote:
On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository.
This is indeed the idiomatic way to contribute on GitHub.
1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request
That is how you do it if you *already* know you want to be contribute to an application or package. But what if I was just planning to *use* an application or package, only later I ended up tracing down a bug to that application and fixed it. What is the *easiest* for me to push to my personal github account from where I make the Pull Request. Something like this [1] from within Pharo (disclaimer, I've not performed these action before, I had to hunt a bit to find it as an example)...
This would depend a bit on how you installed the project to start with. If you installed it with gitfiletree/remote git repo, then you can follow what you've just posted, because it's the same. However if you installed it via the github:// protocol (or it was automatically pulled in via some other project's BaselineOf or ConfigurationOf), then it's a bit of pain, because you can't just pull in another project with the same baseline (Metacello it thinks it's a different project). Luckily, you should be able to explicitly permit the conflict: Metacello new baseline: 'MyProject'; repository: 'gitfiletree://wherever'; onConflict: [:ex | ex allow ]; load We should be documenting these things somewhere⦠Peter
On Fri, Jul 22, 2016 at 04:11:32PM +0200, Peter Uhnak wrote:
On Fri, Jul 22, 2016 at 09:14:25PM +0800, Ben Coman wrote:
On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository.
This is indeed the idiomatic way to contribute on GitHub.
1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request
That is how you do it if you *already* know you want to be contribute to an application or package. But what if I was just planning to *use* an application or package, only later I ended up tracing down a bug to that application and fixed it. What is the *easiest* for me to push to my personal github account from where I make the Pull Request. Something like this [1] from within Pharo (disclaimer, I've not performed these action before, I had to hunt a bit to find it as an example)...
This would depend a bit on how you installed the project to start with.
If you installed it with gitfiletree/remote git repo, then you can follow what you've just posted, because it's the same.
However if you installed it via the github:// protocol (or it was automatically pulled in via some other project's BaselineOf or ConfigurationOf), then it's a bit of pain, because you can't just pull in another project with the same baseline (Metacello it thinks it's a different project).
Luckily, you should be able to explicitly permit the conflict:
Metacello new baseline: 'MyProject'; repository: 'gitfiletree://wherever'; onConflict: [:ex | ex allow ]; load
Oh, and after this you would follow the same approach. Let's hope IceBerg streamlines this.
We should be documenting these things somewhereâ¦
Peter
On 07/22/2016 07:11 AM, Peter Uhnak wrote:
On Fri, Jul 22, 2016 at 09:14:25PM +0800, Ben Coman wrote:
On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository. This is indeed the idiomatic way to contribute on GitHub.
1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request That is how you do it if you *already* know you want to be contribute to an application or package. But what if I was just planning to *use* an application or package, only later I ended up tracing down a bug to that application and fixed it. What is the *easiest* for me to push to my personal github account from where I make the Pull Request. Something like this [1] from within Pharo (disclaimer, I've not performed these action before, I had to hunt a bit to find it as an example)...
This would depend a bit on how you installed the project to start with.
If you installed it with gitfiletree/remote git repo, then you can follow what you've just posted, because it's the same.
However if you installed it via the github:// protocol (or it was automatically pulled in via some other project's BaselineOf or ConfigurationOf), then it's a bit of pain, because you can't just pull in another project with the same baseline (Metacello it thinks it's a different project).
Luckily, you should be able to explicitly permit the conflict:
Metacello new baseline: 'MyProject'; repository: 'gitfiletree://wherever'; onConflict: [:ex | ex allow ]; load
We should be documenting these things somewhere⦠Or create tools ... the Monticello Browser was created to manage Monticello packages and Pharo really needs a tool that manages projects --- not from the code browsing perspective, but from the Metacello project (baseline/configuration) management perspective --- I've mentioned this before and will probably mention it again:) ...
For tODE I've added a menu item to the `project list` that clones a `guthub://` project to the local disk, creates a new Metacello registration for the project, `locks` the project so that all references to the project moving forward will be mapped to your local clone, finally the working copy repository list is updated for each loaded package in the project so that it points to the git repo ... this is a hefty list of things that need to be done and a tool/gui is really needed to tie these kinds of operations up into a neat package ... I've described this `project list` before and if you care you can probalby find an old email of mine where I go into a bit more detail about the types of things that you are going to need to do as you start doing serious development with git ... I've been using git and Smalltalk for about 4 years now and there are a few lessons that I've learned along the way ... you'll want to take a slightly different route than what I've done, but it is really time to get serious about a 'Metacello Browser' of some kind ... Dale
Hi, This flow is taken into account in the new iceberg... I cannot go into details because I'm still on holidays (and no internet) until Monday... And Nico is also taking some days. Anyway, yes... We had this flow in mind (and others, of course) when we worked in the use cases we want to support. Cheers, Esteban
On 22 Jul 2016, at 15:14, Ben Coman <btc@openinworld.com> wrote:
On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote: I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository.
This is indeed the idiomatic way to contribute on GitHub.
1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request
That is how you do it if you *already* know you want to be contribute to an application or package. But what if I was just planning to *use* an application or package, only later I ended up tracing down a bug to that application and fixed it. What is the *easiest* for me to push to my personal github account from where I make the Pull Request. Something like this [1] from within Pharo (disclaimer, I've not performed these action before, I had to hunt a bit to find it as an example)...
[1] https://gist.github.com/jagregory/710671
Maybe IceBerg (https://github.com/npasserini/iceberg) could have some nice interface for this eventually.
Thanks for the link. This will be interesting to watch.
cheers -ben
In Iceberg you currently can: 1) Download a project using metacello github:// protocol 2) Use Iceberg to make it "writable" (i.e. transform it to an Iceberg repository, pointing to the same remote repository), this is just one step. 3) Commit and push using the new repo, etc. What it is not done yet is the integration with github (or whatever) fork/pr capabilities, it is in the roadmap but not just now because those are not standard git operations, so it will involve communicating directly to the github rest api (and others, we will not be attached to git nor github). So you should add two extra steps which are forking and pull requesting from outside Pharo (or requesting access to the respository to commit right there). This should be a normal flow for contributing to a tool you are using, right now is partially supported to be done from a git(hub) repository, I intend to extend it to be done also from tools installed from smalltalkhub, etc. Should be the same thing. About the discussion between commits and PRs... I've seen both models working right, I think that both have their advantages and I would like to build tools to support both schemas. Personally, I prefer to give people the possibility to commit, but even so I am used to work with PRs, because it really helps the code review. Yes you can have your own branch, and I can see the changes introduced by any commit, but usually is a PR that moves people towards looking to the code, and I think that it is a nice model that works well in practice. In other projects, you have to fork, commit there, then PR, if two people want to work together in an issue is not obvious how to do it... it adds more bureaucracy, it might be necessary for a large project like Pharo, but normally I prefer to avoid it. On Fri, Jul 22, 2016 at 4:42 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
This flow is taken into account in the new iceberg... I cannot go into details because I'm still on holidays (and no internet) until Monday... And Nico is also taking some days. Anyway, yes... We had this flow in mind (and others, of course) when we worked in the use cases we want to support.
Cheers, Esteban
On 22 Jul 2016, at 15:14, Ben Coman <btc@openinworld.com> wrote:
On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote: I'm not sure what the roadmap is for git integration, but just a use case that occurs to me while I work "a bit with git" for the first time from Pharo.
I install a project via a Baseline from git and makes a small improvement. What is the easiest way to contribute back? I can't push back to the personal repo I downloaded from, so the easiest thing would be a single menu item to: 1. Fork original repository 2. Push current in-Image code to a new branch in that fork.
Maybe even... 3. Issue a pull request to the original repository.
This is indeed the idiomatic way to contribute on GitHub.
1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request
That is how you do it if you *already* know you want to be contribute to an application or package. But what if I was just planning to *use* an application or package, only later I ended up tracing down a bug to that application and fixed it. What is the *easiest* for me to push to my personal github account from where I make the Pull Request. Something like this [1] from within Pharo (disclaimer, I've not performed these action before, I had to hunt a bit to find it as an example)...
[1] https://gist.github.com/jagregory/710671
Maybe IceBerg (https://github.com/npasserini/iceberg) could have some nice interface for this eventually.
Thanks for the link. This will be interesting to watch.
cheers -ben
On Fri, Jul 22, 2016 at 10:57 PM, Nicolas Passerini <npasserini@gmail.com> wrote:
In Iceberg you currently can:
1) Download a project using metacello github:// protocol 2) Use Iceberg to make it "writable" (i.e. transform it to an Iceberg repository, pointing to the same remote repository), this is just one step. 3) Commit and push using the new repo, etc.
Thank you for all the work you are doing ! I will try to use Iceberg to made a report.
What it is not done yet is the integration with github (or whatever) fork/pr capabilities, it is in the roadmap but not just now because those are not standard git operations, so it will involve communicating directly to the github rest api (and others, we will not be attached to git nor github).
So you should add two extra steps which are forking and pull requesting from outside Pharo (or requesting access to the respository to commit right there).
Be careful to not linked too much Iceberg to github specificities. PR are github specificities. Branches can be transformed as PR automatically on github.
This should be a normal flow for contributing to a tool you are using, right now is partially supported to be done from a git(hub) repository, I intend to extend it to be done also from tools installed from smalltalkhub, etc. Should be the same thing.
About the discussion between commits and PRs... I've seen both models working right, I think that both have their advantages and I would like to build tools to support both schemas. Personally, I prefer to give people the possibility to commit, but even so I am used to work with PRs, because it really helps the code review. Yes you can have your own branch, and I can see the changes introduced by any commit, but usually is a PR that moves people towards looking to the code, and I think that it is a nice model that works well in practice. In other projects, you have to fork, commit there, then PR, if two people want to work together in an issue is not obvious how to do it... it adds more bureaucracy, it might be necessary for a large project like Pharo, but normally I prefer to avoid it.
As you know git is agnostic in terms of workflow and several workflows have been proposed, like : centralized workflow, feature branch workflow, etc ... Do Iceberg will enforce some specific workflow ? I guess workflows for Pharo-dev and others projects might be different. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
participants (7)
-
Ben Coman -
Dale Henrichs -
Dimitris Chloupis -
Esteban Lorenzano -
Nicolas Passerini -
Peter Uhnak -
Serge Stinckwich