You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Geertjan Wielenga <ge...@googlemail.com> on 2017/09/24 22:54:23 UTC
To branch or to fork.
Hi all,
The Apache Way is to branch, rather than fork -- the idea being that via
branches, the code stays at Apache, rather than being somewhere else, i.e.,
in someone else's Git repo.
From the branch, reviews are done, prior to merging.
We'll (I'll) also stop pushing straight to the ASF repo, i.e., was doing
this for batch license header changes -- and ended up including local OS
files, which I'm now fixing.
So it appears that for everything we're doing its best and safest to create
a branch.
Questions/comments welcome.
Gj
Re: To branch or to fork.
Posted by Neil C Smith <ne...@googlemail.com>.
On Mon, Sep 25, 2017 at 10:29 AM Daniel Gruno <hu...@apache.org> wrote:
> However, do note that if you merge from
> a fork via a PR, GitHub does some weird magic where it silently inserts
> the changes into our repo and then merges it. This messes up the diffs
>
>
Out of interest, I noticed a little while ago that GitHub had changed the
pull request UI to allow squash & merge and rebase & merge options as well
as the default. Would either of these do better on the "weird magic" issue?
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: To branch or to fork.
Posted by Daniel Gruno <hu...@apache.org>.
On 09/25/2017 11:24 AM, Geertjan Wielenga wrote:
> I would prefer this approach too, also since we're working in this way
> naturally already, however I have seen "Can't you do that in a branch of
> the ASF repository instead? It's better IMO if things stay here.” from
> Bertrand, one of our mentors. Hoping there'll be clarity on this point from
> our mentors via this thread.
You are really free to do as you please there. Typically, once you have
the commit bit to the ASF repo, you'll wanna work on branches on that
repo, so you can collaborate on changes with others, but for drive-by
commits, forking is acceptable. However, do note that if you merge from
a fork via a PR, GitHub does some weird magic where it silently inserts
the changes into our repo and then merges it. This messes up the diffs
you get to the mailing list (they'll appear as having already been
committed to the repo before the merge in some cases), which means
you'll risk getting a merge summary but no diff on the mailing list. So
I'd recommend that _committers_ at least work off the main repo.
With regards,
Daniel.
>
> Gj
>
> On Mon, Sep 25, 2017 at 1:38 AM, Matthias Bläsing <mblaesing@doppel-helix.eu
>> wrote:
>
>> Hi,
>>
>> Am Montag, den 25.09.2017, 01:05 +0200 schrieb Geertjan Wielenga:
>>> See:
>>> https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+in
>>> frastructure-puppet+repo
>>>
>>> Gj
>>>
>>> On Mon, Sep 25, 2017 at 12:54 AM, Geertjan Wielenga <
>> geertjan.wielenga@googlemail.com> wrote:
>>>
>>>> The Apache Way is to branch, rather than fork -- the idea being
>>>> that via
>>>> branches, the code stays at Apache, rather than being somewhere
>>>> else, i.e.,
>>>> in someone else's Git repo.
>>>>
>>>> From the branch, reviews are done, prior to merging.
>>
>> The means everybody that wants code merged needs write access to the
>> netbeans git repository.
>>
>> I don't see any benefit here. The normal github way is:
>>
>> * fork the project
>> * create a working branch for your changeset from the development
>> branch/target branch and name it matching your intention
>> * do your changes
>> * create a PR (on github via their system, in other environment via
>> Email), which details your changes
>>
>> Now this PR is reviewed:
>>
>> * Has the author an ICLA on file @apache (this might be
>> interesting...)
>> * Are the changes ok?
>>
>> If review fails, the necessary adjustments can be done on the "working
>> branch" created above, as the PR tracks that.
>>
>> If all changes are ok, this branch is merged in the target branch (pull
>> the target branch, merge the "working branch", push changes to the
>> central repository). The "Merge changes" Button in github PRs does
>> exactly that ans there is also a "Command line instructions" link, that
>> shows what happens under the hood.
>>
>> For the merge to master a committer is needed, all interaction on the
>> PR can be done by "non-committers".
>>
>> The current PR on github show the "normal" way. A committer would now
>> merge these (after review or whatever).
>>
>> The big question: Is the github mirroring of the netbeans repository
>> two way? So are merges done on github cloned into the apache
>> repository?
>>
>>
>> Am I missing something?
>>
>> Greetings
>>
>> Matthias
>>
>
Re: To branch or to fork.
Posted by Geertjan Wielenga <ge...@googlemail.com>.
I would prefer this approach too, also since we're working in this way
naturally already, however I have seen "Can't you do that in a branch of
the ASF repository instead? It's better IMO if things stay here.” from
Bertrand, one of our mentors. Hoping there'll be clarity on this point from
our mentors via this thread.
Gj
On Mon, Sep 25, 2017 at 1:38 AM, Matthias Bläsing <mblaesing@doppel-helix.eu
> wrote:
> Hi,
>
> Am Montag, den 25.09.2017, 01:05 +0200 schrieb Geertjan Wielenga:
> > See:
> > https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+in
> > frastructure-puppet+repo
> >
> > Gj
> >
> > On Mon, Sep 25, 2017 at 12:54 AM, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com> wrote:
> >
> > > The Apache Way is to branch, rather than fork -- the idea being
> > > that via
> > > branches, the code stays at Apache, rather than being somewhere
> > > else, i.e.,
> > > in someone else's Git repo.
> > >
> > > From the branch, reviews are done, prior to merging.
>
> The means everybody that wants code merged needs write access to the
> netbeans git repository.
>
> I don't see any benefit here. The normal github way is:
>
> * fork the project
> * create a working branch for your changeset from the development
> branch/target branch and name it matching your intention
> * do your changes
> * create a PR (on github via their system, in other environment via
> Email), which details your changes
>
> Now this PR is reviewed:
>
> * Has the author an ICLA on file @apache (this might be
> interesting...)
> * Are the changes ok?
>
> If review fails, the necessary adjustments can be done on the "working
> branch" created above, as the PR tracks that.
>
> If all changes are ok, this branch is merged in the target branch (pull
> the target branch, merge the "working branch", push changes to the
> central repository). The "Merge changes" Button in github PRs does
> exactly that ans there is also a "Command line instructions" link, that
> shows what happens under the hood.
>
> For the merge to master a committer is needed, all interaction on the
> PR can be done by "non-committers".
>
> The current PR on github show the "normal" way. A committer would now
> merge these (after review or whatever).
>
> The big question: Is the github mirroring of the netbeans repository
> two way? So are merges done on github cloned into the apache
> repository?
>
>
> Am I missing something?
>
> Greetings
>
> Matthias
>
Re: To branch or to fork.
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Montag, den 25.09.2017, 01:05 +0200 schrieb Geertjan Wielenga:
> See:
> https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+in
> frastructure-puppet+repo
>
> Gj
>
> On Mon, Sep 25, 2017 at 12:54 AM, Geertjan Wielenga <ge...@googlemail.com> wrote:
>
> > The Apache Way is to branch, rather than fork -- the idea being
> > that via
> > branches, the code stays at Apache, rather than being somewhere
> > else, i.e.,
> > in someone else's Git repo.
> >
> > From the branch, reviews are done, prior to merging.
The means everybody that wants code merged needs write access to the
netbeans git repository.
I don't see any benefit here. The normal github way is:
* fork the project
* create a working branch for your changeset from the development
branch/target branch and name it matching your intention
* do your changes
* create a PR (on github via their system, in other environment via
Email), which details your changes
Now this PR is reviewed:
* Has the author an ICLA on file @apache (this might be
interesting...)
* Are the changes ok?
If review fails, the necessary adjustments can be done on the "working
branch" created above, as the PR tracks that.
If all changes are ok, this branch is merged in the target branch (pull
the target branch, merge the "working branch", push changes to the
central repository). The "Merge changes" Button in github PRs does
exactly that ans there is also a "Command line instructions" link, that
shows what happens under the hood.
For the merge to master a committer is needed, all interaction on the
PR can be done by "non-committers".
The current PR on github show the "normal" way. A committer would now
merge these (after review or whatever).
The big question: Is the github mirroring of the netbeans repository
two way? So are merges done on github cloned into the apache
repository?
Am I missing something?
Greetings
Matthias
Re: To branch or to fork.
Posted by Dave Schoorl <ds...@bkwi.nl>.
Hi Geertjan,
I assume you quote the workflow for infrastructure-puppet repo, because it also applies to Netbeans workflow?
More concrete, for NETBEANS-54, will you, or another committer, create such a topic branch, and we will do PR against that branch?
Kind regards,
/Dave
>
> Op 25 september 2017 om 1:05 schreef Geertjan Wielenga <ge...@googlemail.com>:
>
> See:
> https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo
>
> Gj
>
> On Mon, Sep 25, 2017 at 12:54 AM, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com> wrote:
>
> > >
> > Hi all,
> >
> > The Apache Way is to branch, rather than fork -- the idea being that via
> > branches, the code stays at Apache, rather than being somewhere else, i.e.,
> > in someone else's Git repo.
> >
> > From the branch, reviews are done, prior to merging.
> >
> > We'll (I'll) also stop pushing straight to the ASF repo, i.e., was doing
> > this for batch license header changes -- and ended up including local OS
> > files, which I'm now fixing.
> >
> > So it appears that for everything we're doing its best and safest to
> > create a branch.
> >
> > Questions/comments welcome.
> >
> > Gj
> >
> > >
Re: To branch or to fork.
Posted by Geertjan Wielenga <ge...@googlemail.com>.
See:
https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo
Gj
On Mon, Sep 25, 2017 at 12:54 AM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> Hi all,
>
> The Apache Way is to branch, rather than fork -- the idea being that via
> branches, the code stays at Apache, rather than being somewhere else, i.e.,
> in someone else's Git repo.
>
> From the branch, reviews are done, prior to merging.
>
> We'll (I'll) also stop pushing straight to the ASF repo, i.e., was doing
> this for batch license header changes -- and ended up including local OS
> files, which I'm now fixing.
>
> So it appears that for everything we're doing its best and safest to
> create a branch.
>
> Questions/comments welcome.
>
> Gj
>