git feature request

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, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
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, 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 3:11 PM, Peter Uhnak <[hidden email]> wrote:
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, Jul 22, 2016 at 09:14:25PM +0800, Ben Coman wrote:
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:
Oh, and after this you would follow the same approach.

Let's hope IceBerg streamlines this.

>
> We should be documenting these things somewhere…
>
> Peter

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 07/22/2016 07:11 AM, Peter Uhnak wrote: 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

On Fri, Jul 22, 2016 at 10:57 PM, Nicolas Passerini
<[hidden email]> 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.

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/