Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

I meant that you *should* configure something like this. I don't
remember if it was per project or global, but I remember there was
something.

--
Tom.

On Thu, Nov 30, 2017 at 7:46 AM, Stefan Schmidt  wrote:
> Hello.
>
>
> On 11/29/2017 06:04 PM, Tom Hacohen wrote:
>> You need to add them to "ignore branches" on phab. Stefan? :P
>
> I never configured something like this on Phab. Did you mean someone else?
>
> regards
> Stefan Schmidt
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Git Feature/ Proposal

[Stefan Schmidt]

Hello.


On 11/29/2017 06:04 PM, Tom Hacohen wrote:
> You need to add them to "ignore branches" on phab. Stefan? :P

I never configured something like this on Phab. Did you mean someone else?

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

You need to add them to "ignore branches" on phab. Stefan? :P

On Wed, Nov 29, 2017 at 4:30 AM, Jean-Philippe André  wrote:
> Hi,
>
> Patches pushed to a feature branch should not close the opened revisions or
> tickets on phab, only mention the commit ids.
>
> Not sure who can make sure of this?
>
> Thanks,
>
>
> On Thu, Nov 23, 2017 at 7:52 AM, Simon Lees  wrote:
>
>>
>>
>> On 22/11/17 18:42, Andrew Williams wrote:
>> > Can we instead ask people to pull master into their branch before asking
>> > for review / merging it up to master? That’s pretty common practice - in
>> > fact for a long lived branch I would expect that to happen on a regular
>> > basis.
>> >
>> > Andy
>>
>> Yeah I presumed this would be a minimal expectation of any review, I
>> guess it should be explicitly documented somewhere.
>>
>> > On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André 
>> wrote:
>> >
>> >> My problem is that those branches won't be in sync with master.
>> >> This will lead to merge conflicts. I am these days reviewing a lot of
>> work
>> >> done in dev branches or phab patches and it almost never applies nicely
>> on
>> >> master, because the interfaces change.
>> >> A lot of work is done in branches (model, c#, eo widgets, ...) and those
>> >> tasks are both long term and involve more than a single dev. They
>> require
>> >> constant rebasing on master or the final rebase will be a nightmare.
>> Right
>> >> now this is done by people pulling other devs branches, and then
>> rebasing
>> >> onto master in their own dev branch.
>> >>
>> >> Rewriting history on a shared branch has major downsides too. No problem
>> >> for dev branches as there's only one committer, but anyone pulling a
>> >> rewritten history will endure pain.
>> >>
>> >> Honestly I don't have a solution.
>> >>
>> >> It's a move in the right direction, but I'm not sure it's solving the
>> >> problems I'm facing :(
>> >>
>> >>
>> >>
>> >> 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
>> >>
>> >>> Only problem would be the commit emails being resent (because
>> >>> technically they are new commits). One can mitigate that by first
>> >>> pushing them to a dev branch. Commits there have first been there
>> >>> don't trigger emails.
>> >>>
>> >>> On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
>> >>>  wrote:
>>  In the issue where a significant rebase against master is necessary
>> >> then
>>  it's trivial enough to either push to a new feature branch or delete
>> >> and
>>  re-create the existing branch.
>> 
>>  On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
>> 
>> > As Mike said, the rebase/sync to master is being done locally before
>> > the merge. If you are talking about keeping this branch in sync with
>> > master constantly while developing, yes it's a problem. But I guess
>> > it's not intended for long term features.
>> >
>> > On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
>> >  wrote:
>> >> I don't see a difference in the merge process? A feature branch
>> >>> should be
>> >> treated exactly the same as master; the only difference is that
>> >> it's a
>> >> branch which people must specifically pull in order to use instead
>> >> of
>> > being
>> >> master.
>> >>
>> >> When merging, you can either do a regular rebase/merge as in the git
>> >> practices documentation or you can choose to rebase/squash on the
>> > branched
>> >> commits prior to pushing the merge. There is no rewriting within the
>> >> branch, but you can still rewrite anything which has not been pushed
>> >>> to
>> >> master just prior to pushing it to master.
>> >>
>> >> On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
>> >>> j...@videolan.org>
>> >> wrote:
>> >>
>> >>> Hey,
>> >>>
>> >>> If we can't rewrite history on those branches (rebase and push -f),
>> >>> how
>> >>> should we proceed with the merge to/from master?
>> >>> Usually when we merge a branch to master, we rebase it on top of
>> >>> master
>> >>> first and then rebase. That's how our history remains linear and
>> >>> simple.
>> >>>
>> >>> What's the idea here? I wonder.
>> >>>
>> >>> Thanks for implementing this btw,
>> >>>
>> >>> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
>> >>>
>>  I'm not sure about jenkins, that's Stefan's role.
>> 
>>  Anyhow, pushed the changes according to the wiki. Please consider
>>  especially mentioning probies when you say "everyone can push
>> >> to".
>> 
>>  --
>>  Tom.
>> 
>>  On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
>>   wrote:
>> > I've added all the necessary info to the documentation at
>> >
>> >>>
>> > 

Re: [E-devel] Git Feature/ Proposal

[Jean-Philippe André]

Hi,

Patches pushed to a feature branch should not close the opened revisions or
tickets on phab, only mention the commit ids.

Not sure who can make sure of this?

Thanks,


On Thu, Nov 23, 2017 at 7:52 AM, Simon Lees  wrote:

>
>
> On 22/11/17 18:42, Andrew Williams wrote:
> > Can we instead ask people to pull master into their branch before asking
> > for review / merging it up to master? That’s pretty common practice - in
> > fact for a long lived branch I would expect that to happen on a regular
> > basis.
> >
> > Andy
>
> Yeah I presumed this would be a minimal expectation of any review, I
> guess it should be explicitly documented somewhere.
>
> > On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André 
> wrote:
> >
> >> My problem is that those branches won't be in sync with master.
> >> This will lead to merge conflicts. I am these days reviewing a lot of
> work
> >> done in dev branches or phab patches and it almost never applies nicely
> on
> >> master, because the interfaces change.
> >> A lot of work is done in branches (model, c#, eo widgets, ...) and those
> >> tasks are both long term and involve more than a single dev. They
> require
> >> constant rebasing on master or the final rebase will be a nightmare.
> Right
> >> now this is done by people pulling other devs branches, and then
> rebasing
> >> onto master in their own dev branch.
> >>
> >> Rewriting history on a shared branch has major downsides too. No problem
> >> for dev branches as there's only one committer, but anyone pulling a
> >> rewritten history will endure pain.
> >>
> >> Honestly I don't have a solution.
> >>
> >> It's a move in the right direction, but I'm not sure it's solving the
> >> problems I'm facing :(
> >>
> >>
> >>
> >> 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
> >>
> >>> Only problem would be the commit emails being resent (because
> >>> technically they are new commits). One can mitigate that by first
> >>> pushing them to a dev branch. Commits there have first been there
> >>> don't trigger emails.
> >>>
> >>> On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
> >>>  wrote:
>  In the issue where a significant rebase against master is necessary
> >> then
>  it's trivial enough to either push to a new feature branch or delete
> >> and
>  re-create the existing branch.
> 
>  On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
> 
> > As Mike said, the rebase/sync to master is being done locally before
> > the merge. If you are talking about keeping this branch in sync with
> > master constantly while developing, yes it's a problem. But I guess
> > it's not intended for long term features.
> >
> > On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> >  wrote:
> >> I don't see a difference in the merge process? A feature branch
> >>> should be
> >> treated exactly the same as master; the only difference is that
> >> it's a
> >> branch which people must specifically pull in order to use instead
> >> of
> > being
> >> master.
> >>
> >> When merging, you can either do a regular rebase/merge as in the git
> >> practices documentation or you can choose to rebase/squash on the
> > branched
> >> commits prior to pushing the merge. There is no rewriting within the
> >> branch, but you can still rewrite anything which has not been pushed
> >>> to
> >> master just prior to pushing it to master.
> >>
> >> On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> >>> j...@videolan.org>
> >> wrote:
> >>
> >>> Hey,
> >>>
> >>> If we can't rewrite history on those branches (rebase and push -f),
> >>> how
> >>> should we proceed with the merge to/from master?
> >>> Usually when we merge a branch to master, we rebase it on top of
> >>> master
> >>> first and then rebase. That's how our history remains linear and
> >>> simple.
> >>>
> >>> What's the idea here? I wonder.
> >>>
> >>> Thanks for implementing this btw,
> >>>
> >>> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> >>>
>  I'm not sure about jenkins, that's Stefan's role.
> 
>  Anyhow, pushed the changes according to the wiki. Please consider
>  especially mentioning probies when you say "everyone can push
> >> to".
> 
>  --
>  Tom.
> 
>  On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
>   wrote:
> > I've added all the necessary info to the documentation at
> >
> >>>
> > https://www.enlightenment.org/contrib/devs/git-guide.md#
> >>> Feature_Branches
> >
> > If the jenkins concept is not possible then feel free to
> >> remove,
> >>> but
> >>> the
> > rest should be in line with what we want.
> >
> > On 

Re: [E-devel] Git Feature/ Proposal

[Simon Lees]

On 22/11/17 18:42, Andrew Williams wrote:
> Can we instead ask people to pull master into their branch before asking
> for review / merging it up to master? That’s pretty common practice - in
> fact for a long lived branch I would expect that to happen on a regular
> basis.
> 
> Andy

Yeah I presumed this would be a minimal expectation of any review, I
guess it should be explicitly documented somewhere.

> On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André  wrote:
> 
>> My problem is that those branches won't be in sync with master.
>> This will lead to merge conflicts. I am these days reviewing a lot of work
>> done in dev branches or phab patches and it almost never applies nicely on
>> master, because the interfaces change.
>> A lot of work is done in branches (model, c#, eo widgets, ...) and those
>> tasks are both long term and involve more than a single dev. They require
>> constant rebasing on master or the final rebase will be a nightmare. Right
>> now this is done by people pulling other devs branches, and then rebasing
>> onto master in their own dev branch.
>>
>> Rewriting history on a shared branch has major downsides too. No problem
>> for dev branches as there's only one committer, but anyone pulling a
>> rewritten history will endure pain.
>>
>> Honestly I don't have a solution.
>>
>> It's a move in the right direction, but I'm not sure it's solving the
>> problems I'm facing :(
>>
>>
>>
>> 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
>>
>>> Only problem would be the commit emails being resent (because
>>> technically they are new commits). One can mitigate that by first
>>> pushing them to a dev branch. Commits there have first been there
>>> don't trigger emails.
>>>
>>> On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
>>>  wrote:
 In the issue where a significant rebase against master is necessary
>> then
 it's trivial enough to either push to a new feature branch or delete
>> and
 re-create the existing branch.

 On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:

> As Mike said, the rebase/sync to master is being done locally before
> the merge. If you are talking about keeping this branch in sync with
> master constantly while developing, yes it's a problem. But I guess
> it's not intended for long term features.
>
> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
>  wrote:
>> I don't see a difference in the merge process? A feature branch
>>> should be
>> treated exactly the same as master; the only difference is that
>> it's a
>> branch which people must specifically pull in order to use instead
>> of
> being
>> master.
>>
>> When merging, you can either do a regular rebase/merge as in the git
>> practices documentation or you can choose to rebase/squash on the
> branched
>> commits prior to pushing the merge. There is no rewriting within the
>> branch, but you can still rewrite anything which has not been pushed
>>> to
>> master just prior to pushing it to master.
>>
>> On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
>>> j...@videolan.org>
>> wrote:
>>
>>> Hey,
>>>
>>> If we can't rewrite history on those branches (rebase and push -f),
>>> how
>>> should we proceed with the merge to/from master?
>>> Usually when we merge a branch to master, we rebase it on top of
>>> master
>>> first and then rebase. That's how our history remains linear and
>>> simple.
>>>
>>> What's the idea here? I wonder.
>>>
>>> Thanks for implementing this btw,
>>>
>>> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
>>>
 I'm not sure about jenkins, that's Stefan's role.

 Anyhow, pushed the changes according to the wiki. Please consider
 especially mentioning probies when you say "everyone can push
>> to".

 --
 Tom.

 On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
  wrote:
> I've added all the necessary info to the documentation at
>
>>>
> https://www.enlightenment.org/contrib/devs/git-guide.md#
>>> Feature_Branches
>
> If the jenkins concept is not possible then feel free to
>> remove,
>>> but
>>> the
> rest should be in line with what we want.
>
> On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen 
>>> wrote:
>
>> So what has been decided? What should I do? I need specs,
> preferably
>> already added to the git wiki page so there are docs for this
> thing.
>>
>> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
>>> ras...@rasterman.com
>
>> wrote:
>>> On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>>>  

Re: [E-devel] Git Feature/ Proposal

[Mike Blumenkrantz]

I think the most reliable method for handling rebases onto master is if
people working on the branch just communicate that there will be a rebase
at X time and then someone does the delete -> rebase -> create cycle.
Anyone interested in doing review can just request a rebase if there's been
significant deviation.

This is not an automated solution, but communication can easily make this a
non-issue.

On Wed, Nov 22, 2017 at 5:16 AM Carsten Haitzler 
wrote:

> On Wed, 22 Nov 2017 08:12:13 + Andrew Williams 
> said:
>
> > Can we instead ask people to pull master into their branch before asking
> > for review / merging it up to master? That’s pretty common practice - in
> > fact for a long lived branch I would expect that to happen on a regular
> > basis.
>
> That would be at a minimum.
>
> > Andy
> > On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André 
> wrote:
> >
> > > My problem is that those branches won't be in sync with master.
> > > This will lead to merge conflicts. I am these days reviewing a lot of
> work
> > > done in dev branches or phab patches and it almost never applies
> nicely on
> > > master, because the interfaces change.
> > > A lot of work is done in branches (model, c#, eo widgets, ...) and
> those
> > > tasks are both long term and involve more than a single dev. They
> require
> > > constant rebasing on master or the final rebase will be a nightmare.
> Right
> > > now this is done by people pulling other devs branches, and then
> rebasing
> > > onto master in their own dev branch.
> > >
> > > Rewriting history on a shared branch has major downsides too. No
> problem
> > > for dev branches as there's only one committer, but anyone pulling a
> > > rewritten history will endure pain.
> > >
> > > Honestly I don't have a solution.
> > >
> > > It's a move in the right direction, but I'm not sure it's solving the
> > > problems I'm facing :(
> > >
> > >
> > >
> > > 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
> > >
> > > > Only problem would be the commit emails being resent (because
> > > > technically they are new commits). One can mitigate that by first
> > > > pushing them to a dev branch. Commits there have first been there
> > > > don't trigger emails.
> > > >
> > > > On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
> > > >  wrote:
> > > > > In the issue where a significant rebase against master is necessary
> > > then
> > > > > it's trivial enough to either push to a new feature branch or
> delete
> > > and
> > > > > re-create the existing branch.
> > > > >
> > > > > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
> > > > >
> > > > >> As Mike said, the rebase/sync to master is being done locally
> before
> > > > >> the merge. If you are talking about keeping this branch in sync
> with
> > > > >> master constantly while developing, yes it's a problem. But I
> guess
> > > > >> it's not intended for long term features.
> > > > >>
> > > > >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> > > > >>  wrote:
> > > > >> > I don't see a difference in the merge process? A feature branch
> > > > should be
> > > > >> > treated exactly the same as master; the only difference is that
> > > it's a
> > > > >> > branch which people must specifically pull in order to use
> instead
> > > of
> > > > >> being
> > > > >> > master.
> > > > >> >
> > > > >> > When merging, you can either do a regular rebase/merge as in
> the git
> > > > >> > practices documentation or you can choose to rebase/squash on
> the
> > > > >> branched
> > > > >> > commits prior to pushing the merge. There is no rewriting
> within the
> > > > >> > branch, but you can still rewrite anything which has not been
> pushed
> > > > to
> > > > >> > master just prior to pushing it to master.
> > > > >> >
> > > > >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> > > > j...@videolan.org>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Hey,
> > > > >> >>
> > > > >> >> If we can't rewrite history on those branches (rebase and push
> -f),
> > > > how
> > > > >> >> should we proceed with the merge to/from master?
> > > > >> >> Usually when we merge a branch to master, we rebase it on top
> of
> > > > master
> > > > >> >> first and then rebase. That's how our history remains linear
> and
> > > > simple.
> > > > >> >>
> > > > >> >> What's the idea here? I wonder.
> > > > >> >>
> > > > >> >> Thanks for implementing this btw,
> > > > >> >>
> > > > >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> > > > >> >>
> > > > >> >> > I'm not sure about jenkins, that's Stefan's role.
> > > > >> >> >
> > > > >> >> > Anyhow, pushed the changes according to the wiki. Please
> consider
> > > > >> >> > especially mentioning probies when you say "everyone can push
> > > to".
> > > > >> >> >
> > > > >> >> > --
> > > > >> >> > Tom.
> > > > >> >> >
> > > > >> >> > On Mon, Nov 20, 

Re: [E-devel] Git Feature/ Proposal

[Carsten Haitzler]

On Wed, 22 Nov 2017 08:12:13 + Andrew Williams  said:

> Can we instead ask people to pull master into their branch before asking
> for review / merging it up to master? That’s pretty common practice - in
> fact for a long lived branch I would expect that to happen on a regular
> basis.

That would be at a minimum.

> Andy
> On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André  wrote:
> 
> > My problem is that those branches won't be in sync with master.
> > This will lead to merge conflicts. I am these days reviewing a lot of work
> > done in dev branches or phab patches and it almost never applies nicely on
> > master, because the interfaces change.
> > A lot of work is done in branches (model, c#, eo widgets, ...) and those
> > tasks are both long term and involve more than a single dev. They require
> > constant rebasing on master or the final rebase will be a nightmare. Right
> > now this is done by people pulling other devs branches, and then rebasing
> > onto master in their own dev branch.
> >
> > Rewriting history on a shared branch has major downsides too. No problem
> > for dev branches as there's only one committer, but anyone pulling a
> > rewritten history will endure pain.
> >
> > Honestly I don't have a solution.
> >
> > It's a move in the right direction, but I'm not sure it's solving the
> > problems I'm facing :(
> >
> >
> >
> > 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
> >
> > > Only problem would be the commit emails being resent (because
> > > technically they are new commits). One can mitigate that by first
> > > pushing them to a dev branch. Commits there have first been there
> > > don't trigger emails.
> > >
> > > On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
> > >  wrote:
> > > > In the issue where a significant rebase against master is necessary
> > then
> > > > it's trivial enough to either push to a new feature branch or delete
> > and
> > > > re-create the existing branch.
> > > >
> > > > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
> > > >
> > > >> As Mike said, the rebase/sync to master is being done locally before
> > > >> the merge. If you are talking about keeping this branch in sync with
> > > >> master constantly while developing, yes it's a problem. But I guess
> > > >> it's not intended for long term features.
> > > >>
> > > >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> > > >>  wrote:
> > > >> > I don't see a difference in the merge process? A feature branch
> > > should be
> > > >> > treated exactly the same as master; the only difference is that
> > it's a
> > > >> > branch which people must specifically pull in order to use instead
> > of
> > > >> being
> > > >> > master.
> > > >> >
> > > >> > When merging, you can either do a regular rebase/merge as in the git
> > > >> > practices documentation or you can choose to rebase/squash on the
> > > >> branched
> > > >> > commits prior to pushing the merge. There is no rewriting within the
> > > >> > branch, but you can still rewrite anything which has not been pushed
> > > to
> > > >> > master just prior to pushing it to master.
> > > >> >
> > > >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> > > j...@videolan.org>
> > > >> > wrote:
> > > >> >
> > > >> >> Hey,
> > > >> >>
> > > >> >> If we can't rewrite history on those branches (rebase and push -f),
> > > how
> > > >> >> should we proceed with the merge to/from master?
> > > >> >> Usually when we merge a branch to master, we rebase it on top of
> > > master
> > > >> >> first and then rebase. That's how our history remains linear and
> > > simple.
> > > >> >>
> > > >> >> What's the idea here? I wonder.
> > > >> >>
> > > >> >> Thanks for implementing this btw,
> > > >> >>
> > > >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> > > >> >>
> > > >> >> > I'm not sure about jenkins, that's Stefan's role.
> > > >> >> >
> > > >> >> > Anyhow, pushed the changes according to the wiki. Please consider
> > > >> >> > especially mentioning probies when you say "everyone can push
> > to".
> > > >> >> >
> > > >> >> > --
> > > >> >> > Tom.
> > > >> >> >
> > > >> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> > > >> >> >  wrote:
> > > >> >> > > I've added all the necessary info to the documentation at
> > > >> >> > >
> > > >> >>
> > > >> https://www.enlightenment.org/contrib/devs/git-guide.md#
> > > Feature_Branches
> > > >> >> > >
> > > >> >> > > If the jenkins concept is not possible then feel free to
> > remove,
> > > but
> > > >> >> the
> > > >> >> > > rest should be in line with what we want.
> > > >> >> > >
> > > >> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen 
> > > wrote:
> > > >> >> > >
> > > >> >> > >> So what has been decided? What should I do? I need specs,
> > > >> preferably
> > > >> >> > >> already added to the git wiki page 

Re: [E-devel] Git Feature/ Proposal

[Andrew Williams]

Can we instead ask people to pull master into their branch before asking
for review / merging it up to master? That’s pretty common practice - in
fact for a long lived branch I would expect that to happen on a regular
basis.

Andy
On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André  wrote:

> My problem is that those branches won't be in sync with master.
> This will lead to merge conflicts. I am these days reviewing a lot of work
> done in dev branches or phab patches and it almost never applies nicely on
> master, because the interfaces change.
> A lot of work is done in branches (model, c#, eo widgets, ...) and those
> tasks are both long term and involve more than a single dev. They require
> constant rebasing on master or the final rebase will be a nightmare. Right
> now this is done by people pulling other devs branches, and then rebasing
> onto master in their own dev branch.
>
> Rewriting history on a shared branch has major downsides too. No problem
> for dev branches as there's only one committer, but anyone pulling a
> rewritten history will endure pain.
>
> Honestly I don't have a solution.
>
> It's a move in the right direction, but I'm not sure it's solving the
> problems I'm facing :(
>
>
>
> 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
>
> > Only problem would be the commit emails being resent (because
> > technically they are new commits). One can mitigate that by first
> > pushing them to a dev branch. Commits there have first been there
> > don't trigger emails.
> >
> > On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
> >  wrote:
> > > In the issue where a significant rebase against master is necessary
> then
> > > it's trivial enough to either push to a new feature branch or delete
> and
> > > re-create the existing branch.
> > >
> > > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
> > >
> > >> As Mike said, the rebase/sync to master is being done locally before
> > >> the merge. If you are talking about keeping this branch in sync with
> > >> master constantly while developing, yes it's a problem. But I guess
> > >> it's not intended for long term features.
> > >>
> > >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> > >>  wrote:
> > >> > I don't see a difference in the merge process? A feature branch
> > should be
> > >> > treated exactly the same as master; the only difference is that
> it's a
> > >> > branch which people must specifically pull in order to use instead
> of
> > >> being
> > >> > master.
> > >> >
> > >> > When merging, you can either do a regular rebase/merge as in the git
> > >> > practices documentation or you can choose to rebase/squash on the
> > >> branched
> > >> > commits prior to pushing the merge. There is no rewriting within the
> > >> > branch, but you can still rewrite anything which has not been pushed
> > to
> > >> > master just prior to pushing it to master.
> > >> >
> > >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> > j...@videolan.org>
> > >> > wrote:
> > >> >
> > >> >> Hey,
> > >> >>
> > >> >> If we can't rewrite history on those branches (rebase and push -f),
> > how
> > >> >> should we proceed with the merge to/from master?
> > >> >> Usually when we merge a branch to master, we rebase it on top of
> > master
> > >> >> first and then rebase. That's how our history remains linear and
> > simple.
> > >> >>
> > >> >> What's the idea here? I wonder.
> > >> >>
> > >> >> Thanks for implementing this btw,
> > >> >>
> > >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> > >> >>
> > >> >> > I'm not sure about jenkins, that's Stefan's role.
> > >> >> >
> > >> >> > Anyhow, pushed the changes according to the wiki. Please consider
> > >> >> > especially mentioning probies when you say "everyone can push
> to".
> > >> >> >
> > >> >> > --
> > >> >> > Tom.
> > >> >> >
> > >> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> > >> >> >  wrote:
> > >> >> > > I've added all the necessary info to the documentation at
> > >> >> > >
> > >> >>
> > >> https://www.enlightenment.org/contrib/devs/git-guide.md#
> > Feature_Branches
> > >> >> > >
> > >> >> > > If the jenkins concept is not possible then feel free to
> remove,
> > but
> > >> >> the
> > >> >> > > rest should be in line with what we want.
> > >> >> > >
> > >> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen 
> > wrote:
> > >> >> > >
> > >> >> > >> So what has been decided? What should I do? I need specs,
> > >> preferably
> > >> >> > >> already added to the git wiki page so there are docs for this
> > >> thing.
> > >> >> > >>
> > >> >> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
> > >> >> ras...@rasterman.com
> > >> >> > >
> > >> >> > >> wrote:
> > >> >> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> > >> >> > >> >  said:
> > >> >> > >> >
> > >> >> > >> 

Re: [E-devel] Git Feature/ Proposal

[Jean-Philippe André]

My problem is that those branches won't be in sync with master.
This will lead to merge conflicts. I am these days reviewing a lot of work
done in dev branches or phab patches and it almost never applies nicely on
master, because the interfaces change.
A lot of work is done in branches (model, c#, eo widgets, ...) and those
tasks are both long term and involve more than a single dev. They require
constant rebasing on master or the final rebase will be a nightmare. Right
now this is done by people pulling other devs branches, and then rebasing
onto master in their own dev branch.

Rewriting history on a shared branch has major downsides too. No problem
for dev branches as there's only one committer, but anyone pulling a
rewritten history will endure pain.

Honestly I don't have a solution.

It's a move in the right direction, but I'm not sure it's solving the
problems I'm facing :(



2017-11-22 3:43 GMT+09:00 Tom Hacohen :

> Only problem would be the commit emails being resent (because
> technically they are new commits). One can mitigate that by first
> pushing them to a dev branch. Commits there have first been there
> don't trigger emails.
>
> On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
>  wrote:
> > In the issue where a significant rebase against master is necessary then
> > it's trivial enough to either push to a new feature branch or delete and
> > re-create the existing branch.
> >
> > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
> >
> >> As Mike said, the rebase/sync to master is being done locally before
> >> the merge. If you are talking about keeping this branch in sync with
> >> master constantly while developing, yes it's a problem. But I guess
> >> it's not intended for long term features.
> >>
> >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> >>  wrote:
> >> > I don't see a difference in the merge process? A feature branch
> should be
> >> > treated exactly the same as master; the only difference is that it's a
> >> > branch which people must specifically pull in order to use instead of
> >> being
> >> > master.
> >> >
> >> > When merging, you can either do a regular rebase/merge as in the git
> >> > practices documentation or you can choose to rebase/squash on the
> >> branched
> >> > commits prior to pushing the merge. There is no rewriting within the
> >> > branch, but you can still rewrite anything which has not been pushed
> to
> >> > master just prior to pushing it to master.
> >> >
> >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> j...@videolan.org>
> >> > wrote:
> >> >
> >> >> Hey,
> >> >>
> >> >> If we can't rewrite history on those branches (rebase and push -f),
> how
> >> >> should we proceed with the merge to/from master?
> >> >> Usually when we merge a branch to master, we rebase it on top of
> master
> >> >> first and then rebase. That's how our history remains linear and
> simple.
> >> >>
> >> >> What's the idea here? I wonder.
> >> >>
> >> >> Thanks for implementing this btw,
> >> >>
> >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> >> >>
> >> >> > I'm not sure about jenkins, that's Stefan's role.
> >> >> >
> >> >> > Anyhow, pushed the changes according to the wiki. Please consider
> >> >> > especially mentioning probies when you say "everyone can push to".
> >> >> >
> >> >> > --
> >> >> > Tom.
> >> >> >
> >> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> >> >> >  wrote:
> >> >> > > I've added all the necessary info to the documentation at
> >> >> > >
> >> >>
> >> https://www.enlightenment.org/contrib/devs/git-guide.md#
> Feature_Branches
> >> >> > >
> >> >> > > If the jenkins concept is not possible then feel free to remove,
> but
> >> >> the
> >> >> > > rest should be in line with what we want.
> >> >> > >
> >> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen 
> wrote:
> >> >> > >
> >> >> > >> So what has been decided? What should I do? I need specs,
> >> preferably
> >> >> > >> already added to the git wiki page so there are docs for this
> >> thing.
> >> >> > >>
> >> >> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
> >> >> ras...@rasterman.com
> >> >> > >
> >> >> > >> wrote:
> >> >> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> >> >> > >> >  said:
> >> >> > >> >
> >> >> > >> >> Key points for the implementation:
> >> >> > >> >>
> >> >> > >> >> * all commits send mails to the list
> >> >> > >> >> * no rewrite of pushed commits
> >> >> > >> >>
> >> >> > >> >> Things to consider:
> >> >> > >> >> * how are feature/ branches deleted?
> >> >> > >> >>  - maybe anyone can delete?
> >> >> > >> >
> >> >> > >> > Good point. these need deletion. after a few years it'll be a
> >> mess
> >> >> of
> >> >> > old
> >> >> > >> > feature branches no one will ever look at again. The merge to
> >> master
> >> >> > >> should
> >> 

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

Only problem would be the commit emails being resent (because
technically they are new commits). One can mitigate that by first
pushing them to a dev branch. Commits there have first been there
don't trigger emails.

On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
 wrote:
> In the issue where a significant rebase against master is necessary then
> it's trivial enough to either push to a new feature branch or delete and
> re-create the existing branch.
>
> On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
>
>> As Mike said, the rebase/sync to master is being done locally before
>> the merge. If you are talking about keeping this branch in sync with
>> master constantly while developing, yes it's a problem. But I guess
>> it's not intended for long term features.
>>
>> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
>>  wrote:
>> > I don't see a difference in the merge process? A feature branch should be
>> > treated exactly the same as master; the only difference is that it's a
>> > branch which people must specifically pull in order to use instead of
>> being
>> > master.
>> >
>> > When merging, you can either do a regular rebase/merge as in the git
>> > practices documentation or you can choose to rebase/squash on the
>> branched
>> > commits prior to pushing the merge. There is no rewriting within the
>> > branch, but you can still rewrite anything which has not been pushed to
>> > master just prior to pushing it to master.
>> >
>> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André 
>> > wrote:
>> >
>> >> Hey,
>> >>
>> >> If we can't rewrite history on those branches (rebase and push -f), how
>> >> should we proceed with the merge to/from master?
>> >> Usually when we merge a branch to master, we rebase it on top of master
>> >> first and then rebase. That's how our history remains linear and simple.
>> >>
>> >> What's the idea here? I wonder.
>> >>
>> >> Thanks for implementing this btw,
>> >>
>> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
>> >>
>> >> > I'm not sure about jenkins, that's Stefan's role.
>> >> >
>> >> > Anyhow, pushed the changes according to the wiki. Please consider
>> >> > especially mentioning probies when you say "everyone can push to".
>> >> >
>> >> > --
>> >> > Tom.
>> >> >
>> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
>> >> >  wrote:
>> >> > > I've added all the necessary info to the documentation at
>> >> > >
>> >>
>> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
>> >> > >
>> >> > > If the jenkins concept is not possible then feel free to remove, but
>> >> the
>> >> > > rest should be in line with what we want.
>> >> > >
>> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
>> >> > >
>> >> > >> So what has been decided? What should I do? I need specs,
>> preferably
>> >> > >> already added to the git wiki page so there are docs for this
>> thing.
>> >> > >>
>> >> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
>> >> ras...@rasterman.com
>> >> > >
>> >> > >> wrote:
>> >> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>> >> > >> >  said:
>> >> > >> >
>> >> > >> >> Key points for the implementation:
>> >> > >> >>
>> >> > >> >> * all commits send mails to the list
>> >> > >> >> * no rewrite of pushed commits
>> >> > >> >>
>> >> > >> >> Things to consider:
>> >> > >> >> * how are feature/ branches deleted?
>> >> > >> >>  - maybe anyone can delete?
>> >> > >> >
>> >> > >> > Good point. these need deletion. after a few years it'll be a
>> mess
>> >> of
>> >> > old
>> >> > >> > feature branches no one will ever look at again. The merge to
>> master
>> >> > >> should
>> >> > >> > contain all the history and log that is needed at that point for
>> >> > history
>> >> > >> > digging.
>> >> > >> >
>> >> > >> >> * do probies get feature/ push access?
>> >> > >> >>  - seems like they should?
>> >> > >> >>
>> >> > >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen 
>> wrote:
>> >> > >> >>
>> >> > >> >> > Yeah, good idea.
>> >> > >> >> >
>> >> > >> >> > I'll take a look into implementing it soon.
>> >> > >> >> >
>> >> > >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
>> >> > a...@andywilliams.me
>> >> > >> >
>> >> > >> >> > wrote:
>> >> > >> >> > > Hi,
>> >> > >> >> > >
>> >> > >> >> > > That sounds great - the ability to work together on features
>> >> > >> off-master
>> >> > >> >> > > would be really helpful.
>> >> > >> >> > >
>> >> > >> >> > > Andy
>> >> > >> >> > >
>> >> > >> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
>> >> > >> >> > > michael.blumenkra...@gmail.com> wrote:
>> >> > >> >> > >
>> >> > >> >> > >> After some discussions about git organization, it's become
>> >> clear
>> >> > >> to me
>> >> > >> >> > that
>> >> > >> >> > >> we should be trying to enact some changes which 

Re: [E-devel] Git Feature/ Proposal

[Mike Blumenkrantz]

In the issue where a significant rebase against master is necessary then
it's trivial enough to either push to a new feature branch or delete and
re-create the existing branch.

On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:

> As Mike said, the rebase/sync to master is being done locally before
> the merge. If you are talking about keeping this branch in sync with
> master constantly while developing, yes it's a problem. But I guess
> it's not intended for long term features.
>
> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
>  wrote:
> > I don't see a difference in the merge process? A feature branch should be
> > treated exactly the same as master; the only difference is that it's a
> > branch which people must specifically pull in order to use instead of
> being
> > master.
> >
> > When merging, you can either do a regular rebase/merge as in the git
> > practices documentation or you can choose to rebase/squash on the
> branched
> > commits prior to pushing the merge. There is no rewriting within the
> > branch, but you can still rewrite anything which has not been pushed to
> > master just prior to pushing it to master.
> >
> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André 
> > wrote:
> >
> >> Hey,
> >>
> >> If we can't rewrite history on those branches (rebase and push -f), how
> >> should we proceed with the merge to/from master?
> >> Usually when we merge a branch to master, we rebase it on top of master
> >> first and then rebase. That's how our history remains linear and simple.
> >>
> >> What's the idea here? I wonder.
> >>
> >> Thanks for implementing this btw,
> >>
> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> >>
> >> > I'm not sure about jenkins, that's Stefan's role.
> >> >
> >> > Anyhow, pushed the changes according to the wiki. Please consider
> >> > especially mentioning probies when you say "everyone can push to".
> >> >
> >> > --
> >> > Tom.
> >> >
> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> >> >  wrote:
> >> > > I've added all the necessary info to the documentation at
> >> > >
> >>
> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
> >> > >
> >> > > If the jenkins concept is not possible then feel free to remove, but
> >> the
> >> > > rest should be in line with what we want.
> >> > >
> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
> >> > >
> >> > >> So what has been decided? What should I do? I need specs,
> preferably
> >> > >> already added to the git wiki page so there are docs for this
> thing.
> >> > >>
> >> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
> >> ras...@rasterman.com
> >> > >
> >> > >> wrote:
> >> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> >> > >> >  said:
> >> > >> >
> >> > >> >> Key points for the implementation:
> >> > >> >>
> >> > >> >> * all commits send mails to the list
> >> > >> >> * no rewrite of pushed commits
> >> > >> >>
> >> > >> >> Things to consider:
> >> > >> >> * how are feature/ branches deleted?
> >> > >> >>  - maybe anyone can delete?
> >> > >> >
> >> > >> > Good point. these need deletion. after a few years it'll be a
> mess
> >> of
> >> > old
> >> > >> > feature branches no one will ever look at again. The merge to
> master
> >> > >> should
> >> > >> > contain all the history and log that is needed at that point for
> >> > history
> >> > >> > digging.
> >> > >> >
> >> > >> >> * do probies get feature/ push access?
> >> > >> >>  - seems like they should?
> >> > >> >>
> >> > >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen 
> wrote:
> >> > >> >>
> >> > >> >> > Yeah, good idea.
> >> > >> >> >
> >> > >> >> > I'll take a look into implementing it soon.
> >> > >> >> >
> >> > >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
> >> > a...@andywilliams.me
> >> > >> >
> >> > >> >> > wrote:
> >> > >> >> > > Hi,
> >> > >> >> > >
> >> > >> >> > > That sounds great - the ability to work together on features
> >> > >> off-master
> >> > >> >> > > would be really helpful.
> >> > >> >> > >
> >> > >> >> > > Andy
> >> > >> >> > >
> >> > >> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> >> > >> >> > > michael.blumenkra...@gmail.com> wrote:
> >> > >> >> > >
> >> > >> >> > >> After some discussions about git organization, it's become
> >> clear
> >> > >> to me
> >> > >> >> > that
> >> > >> >> > >> we should be trying to enact some changes which facilitate
> >> > >> >> > collaboration,
> >> > >> >> > >> both between existing contributors and keeping in mind
> future
> >> > >> >> > contributors.
> >> > >> >> > >>
> >> > >> >> > >> The current git branch policy is this:
> >> > >> >> > >>
> >> > >> >> > >> * master
> >> > >> >> > >> * $project-$version
> >> > >> >> > >> * devs/$name/$branchname
> >> > >> >> > >>
> >> > >> >> > >> No others are allowed. This fits many use cases, 

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

As Mike said, the rebase/sync to master is being done locally before
the merge. If you are talking about keeping this branch in sync with
master constantly while developing, yes it's a problem. But I guess
it's not intended for long term features.

On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
 wrote:
> I don't see a difference in the merge process? A feature branch should be
> treated exactly the same as master; the only difference is that it's a
> branch which people must specifically pull in order to use instead of being
> master.
>
> When merging, you can either do a regular rebase/merge as in the git
> practices documentation or you can choose to rebase/squash on the branched
> commits prior to pushing the merge. There is no rewriting within the
> branch, but you can still rewrite anything which has not been pushed to
> master just prior to pushing it to master.
>
> On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André 
> wrote:
>
>> Hey,
>>
>> If we can't rewrite history on those branches (rebase and push -f), how
>> should we proceed with the merge to/from master?
>> Usually when we merge a branch to master, we rebase it on top of master
>> first and then rebase. That's how our history remains linear and simple.
>>
>> What's the idea here? I wonder.
>>
>> Thanks for implementing this btw,
>>
>> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
>>
>> > I'm not sure about jenkins, that's Stefan's role.
>> >
>> > Anyhow, pushed the changes according to the wiki. Please consider
>> > especially mentioning probies when you say "everyone can push to".
>> >
>> > --
>> > Tom.
>> >
>> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
>> >  wrote:
>> > > I've added all the necessary info to the documentation at
>> > >
>> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
>> > >
>> > > If the jenkins concept is not possible then feel free to remove, but
>> the
>> > > rest should be in line with what we want.
>> > >
>> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
>> > >
>> > >> So what has been decided? What should I do? I need specs, preferably
>> > >> already added to the git wiki page so there are docs for this thing.
>> > >>
>> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
>> ras...@rasterman.com
>> > >
>> > >> wrote:
>> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>> > >> >  said:
>> > >> >
>> > >> >> Key points for the implementation:
>> > >> >>
>> > >> >> * all commits send mails to the list
>> > >> >> * no rewrite of pushed commits
>> > >> >>
>> > >> >> Things to consider:
>> > >> >> * how are feature/ branches deleted?
>> > >> >>  - maybe anyone can delete?
>> > >> >
>> > >> > Good point. these need deletion. after a few years it'll be a mess
>> of
>> > old
>> > >> > feature branches no one will ever look at again. The merge to master
>> > >> should
>> > >> > contain all the history and log that is needed at that point for
>> > history
>> > >> > digging.
>> > >> >
>> > >> >> * do probies get feature/ push access?
>> > >> >>  - seems like they should?
>> > >> >>
>> > >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:
>> > >> >>
>> > >> >> > Yeah, good idea.
>> > >> >> >
>> > >> >> > I'll take a look into implementing it soon.
>> > >> >> >
>> > >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
>> > a...@andywilliams.me
>> > >> >
>> > >> >> > wrote:
>> > >> >> > > Hi,
>> > >> >> > >
>> > >> >> > > That sounds great - the ability to work together on features
>> > >> off-master
>> > >> >> > > would be really helpful.
>> > >> >> > >
>> > >> >> > > Andy
>> > >> >> > >
>> > >> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
>> > >> >> > > michael.blumenkra...@gmail.com> wrote:
>> > >> >> > >
>> > >> >> > >> After some discussions about git organization, it's become
>> clear
>> > >> to me
>> > >> >> > that
>> > >> >> > >> we should be trying to enact some changes which facilitate
>> > >> >> > collaboration,
>> > >> >> > >> both between existing contributors and keeping in mind future
>> > >> >> > contributors.
>> > >> >> > >>
>> > >> >> > >> The current git branch policy is this:
>> > >> >> > >>
>> > >> >> > >> * master
>> > >> >> > >> * $project-$version
>> > >> >> > >> * devs/$name/$branchname
>> > >> >> > >>
>> > >> >> > >> No others are allowed. This fits many use cases, but it does
>> not
>> > >> >> > actually
>> > >> >> > >> help us work towards collaborating on features/patchsets and
>> > >> instead
>> > >> >> > >> promotes developing in isolation.
>> > >> >> > >>
>> > >> >> > >> A simple proposal could improve this without requiring or
>> > >> significantly
>> > >> >> > >> changing our workflow: add "feature/" branches. For example,
>> if
>> > >> Cedric
>> > >> >> > and
>> > >> >> > >> I decide to work on a "feature" which scrapes the archive of
>> > this
>> > >> >> 

Re: [E-devel] Git Feature/ Proposal

[Mike Blumenkrantz]

I don't see a difference in the merge process? A feature branch should be
treated exactly the same as master; the only difference is that it's a
branch which people must specifically pull in order to use instead of being
master.

When merging, you can either do a regular rebase/merge as in the git
practices documentation or you can choose to rebase/squash on the branched
commits prior to pushing the merge. There is no rewriting within the
branch, but you can still rewrite anything which has not been pushed to
master just prior to pushing it to master.

On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André 
wrote:

> Hey,
>
> If we can't rewrite history on those branches (rebase and push -f), how
> should we proceed with the merge to/from master?
> Usually when we merge a branch to master, we rebase it on top of master
> first and then rebase. That's how our history remains linear and simple.
>
> What's the idea here? I wonder.
>
> Thanks for implementing this btw,
>
> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
>
> > I'm not sure about jenkins, that's Stefan's role.
> >
> > Anyhow, pushed the changes according to the wiki. Please consider
> > especially mentioning probies when you say "everyone can push to".
> >
> > --
> > Tom.
> >
> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> >  wrote:
> > > I've added all the necessary info to the documentation at
> > >
> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
> > >
> > > If the jenkins concept is not possible then feel free to remove, but
> the
> > > rest should be in line with what we want.
> > >
> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
> > >
> > >> So what has been decided? What should I do? I need specs, preferably
> > >> already added to the git wiki page so there are docs for this thing.
> > >>
> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
> ras...@rasterman.com
> > >
> > >> wrote:
> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> > >> >  said:
> > >> >
> > >> >> Key points for the implementation:
> > >> >>
> > >> >> * all commits send mails to the list
> > >> >> * no rewrite of pushed commits
> > >> >>
> > >> >> Things to consider:
> > >> >> * how are feature/ branches deleted?
> > >> >>  - maybe anyone can delete?
> > >> >
> > >> > Good point. these need deletion. after a few years it'll be a mess
> of
> > old
> > >> > feature branches no one will ever look at again. The merge to master
> > >> should
> > >> > contain all the history and log that is needed at that point for
> > history
> > >> > digging.
> > >> >
> > >> >> * do probies get feature/ push access?
> > >> >>  - seems like they should?
> > >> >>
> > >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:
> > >> >>
> > >> >> > Yeah, good idea.
> > >> >> >
> > >> >> > I'll take a look into implementing it soon.
> > >> >> >
> > >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
> > a...@andywilliams.me
> > >> >
> > >> >> > wrote:
> > >> >> > > Hi,
> > >> >> > >
> > >> >> > > That sounds great - the ability to work together on features
> > >> off-master
> > >> >> > > would be really helpful.
> > >> >> > >
> > >> >> > > Andy
> > >> >> > >
> > >> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> > >> >> > > michael.blumenkra...@gmail.com> wrote:
> > >> >> > >
> > >> >> > >> After some discussions about git organization, it's become
> clear
> > >> to me
> > >> >> > that
> > >> >> > >> we should be trying to enact some changes which facilitate
> > >> >> > collaboration,
> > >> >> > >> both between existing contributors and keeping in mind future
> > >> >> > contributors.
> > >> >> > >>
> > >> >> > >> The current git branch policy is this:
> > >> >> > >>
> > >> >> > >> * master
> > >> >> > >> * $project-$version
> > >> >> > >> * devs/$name/$branchname
> > >> >> > >>
> > >> >> > >> No others are allowed. This fits many use cases, but it does
> not
> > >> >> > actually
> > >> >> > >> help us work towards collaborating on features/patchsets and
> > >> instead
> > >> >> > >> promotes developing in isolation.
> > >> >> > >>
> > >> >> > >> A simple proposal could improve this without requiring or
> > >> significantly
> > >> >> > >> changing our workflow: add "feature/" branches. For example,
> if
> > >> Cedric
> > >> >> > and
> > >> >> > >> I decide to work on a "feature" which scrapes the archive of
> > this
> > >> >> > mailing
> > >> >> > >> list and then crashes the session of anyone who replies to
> this
> > >> thread,
> > >> >> > we
> > >> >> > >> might jointly create a branch named
> "feature/discussion_helper"
> > >> and push
> > >> >> > >> commits to it.
> > >> >> > >>
> > >> >> > >> A key point of this proposal would be that the feature/
> branches
> > >> must
> > >> >> > >> trigger mails to the mailing list just like stable branches.
> > This
> > >> would
> > >> >> > >> increase 

Re: [E-devel] Git Feature/ Proposal

[Jean-Philippe André]

Hey,

If we can't rewrite history on those branches (rebase and push -f), how
should we proceed with the merge to/from master?
Usually when we merge a branch to master, we rebase it on top of master
first and then rebase. That's how our history remains linear and simple.

What's the idea here? I wonder.

Thanks for implementing this btw,

2017-11-21 8:49 GMT+09:00 Tom Hacohen :

> I'm not sure about jenkins, that's Stefan's role.
>
> Anyhow, pushed the changes according to the wiki. Please consider
> especially mentioning probies when you say "everyone can push to".
>
> --
> Tom.
>
> On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
>  wrote:
> > I've added all the necessary info to the documentation at
> > https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
> >
> > If the jenkins concept is not possible then feel free to remove, but the
> > rest should be in line with what we want.
> >
> > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
> >
> >> So what has been decided? What should I do? I need specs, preferably
> >> already added to the git wiki page so there are docs for this thing.
> >>
> >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler  >
> >> wrote:
> >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> >> >  said:
> >> >
> >> >> Key points for the implementation:
> >> >>
> >> >> * all commits send mails to the list
> >> >> * no rewrite of pushed commits
> >> >>
> >> >> Things to consider:
> >> >> * how are feature/ branches deleted?
> >> >>  - maybe anyone can delete?
> >> >
> >> > Good point. these need deletion. after a few years it'll be a mess of
> old
> >> > feature branches no one will ever look at again. The merge to master
> >> should
> >> > contain all the history and log that is needed at that point for
> history
> >> > digging.
> >> >
> >> >> * do probies get feature/ push access?
> >> >>  - seems like they should?
> >> >>
> >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:
> >> >>
> >> >> > Yeah, good idea.
> >> >> >
> >> >> > I'll take a look into implementing it soon.
> >> >> >
> >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
> a...@andywilliams.me
> >> >
> >> >> > wrote:
> >> >> > > Hi,
> >> >> > >
> >> >> > > That sounds great - the ability to work together on features
> >> off-master
> >> >> > > would be really helpful.
> >> >> > >
> >> >> > > Andy
> >> >> > >
> >> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> >> >> > > michael.blumenkra...@gmail.com> wrote:
> >> >> > >
> >> >> > >> After some discussions about git organization, it's become clear
> >> to me
> >> >> > that
> >> >> > >> we should be trying to enact some changes which facilitate
> >> >> > collaboration,
> >> >> > >> both between existing contributors and keeping in mind future
> >> >> > contributors.
> >> >> > >>
> >> >> > >> The current git branch policy is this:
> >> >> > >>
> >> >> > >> * master
> >> >> > >> * $project-$version
> >> >> > >> * devs/$name/$branchname
> >> >> > >>
> >> >> > >> No others are allowed. This fits many use cases, but it does not
> >> >> > actually
> >> >> > >> help us work towards collaborating on features/patchsets and
> >> instead
> >> >> > >> promotes developing in isolation.
> >> >> > >>
> >> >> > >> A simple proposal could improve this without requiring or
> >> significantly
> >> >> > >> changing our workflow: add "feature/" branches. For example, if
> >> Cedric
> >> >> > and
> >> >> > >> I decide to work on a "feature" which scrapes the archive of
> this
> >> >> > mailing
> >> >> > >> list and then crashes the session of anyone who replies to this
> >> thread,
> >> >> > we
> >> >> > >> might jointly create a branch named "feature/discussion_helper"
> >> and push
> >> >> > >> commits to it.
> >> >> > >>
> >> >> > >> A key point of this proposal would be that the feature/ branches
> >> must
> >> >> > >> trigger mails to the mailing list just like stable branches.
> This
> >> would
> >> >> > >> increase visibility for feature branches as well as promote
> further
> >> >> > >> collaboration even from those who are not directly involved in
> >> creating
> >> >> > the
> >> >> > >> feature. The initial feature development could be done in a dev/
> >> branch,
> >> >> > >> and then it could later move to a feature/ branch once it has
> >> >> > progressed to
> >> >> > >> the point where it is ready for public visibility and increased
> >> >> > >> collaboration.
> >> >> > >>
> >> >> > >> Lastly, feature branches would not be required use, just
> >> encouraged.
> >> >> > This
> >> >> > >> allows people to continue the current EFL standard of always
> >> committing
> >> >> > >> only to master without any prior testing or branching, the need
> for
> >> >> > which
> >> >> > >> has defeated other proposals which would prevent such action.
> >> >> > >>
> >> >> > >> I think this could yield significant 

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

I'm not sure about jenkins, that's Stefan's role.

Anyhow, pushed the changes according to the wiki. Please consider
especially mentioning probies when you say "everyone can push to".

--
Tom.

On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
 wrote:
> I've added all the necessary info to the documentation at
> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
>
> If the jenkins concept is not possible then feel free to remove, but the
> rest should be in line with what we want.
>
> On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:
>
>> So what has been decided? What should I do? I need specs, preferably
>> already added to the git wiki page so there are docs for this thing.
>>
>> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler 
>> wrote:
>> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>> >  said:
>> >
>> >> Key points for the implementation:
>> >>
>> >> * all commits send mails to the list
>> >> * no rewrite of pushed commits
>> >>
>> >> Things to consider:
>> >> * how are feature/ branches deleted?
>> >>  - maybe anyone can delete?
>> >
>> > Good point. these need deletion. after a few years it'll be a mess of old
>> > feature branches no one will ever look at again. The merge to master
>> should
>> > contain all the history and log that is needed at that point for history
>> > digging.
>> >
>> >> * do probies get feature/ push access?
>> >>  - seems like they should?
>> >>
>> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:
>> >>
>> >> > Yeah, good idea.
>> >> >
>> >> > I'll take a look into implementing it soon.
>> >> >
>> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams > >
>> >> > wrote:
>> >> > > Hi,
>> >> > >
>> >> > > That sounds great - the ability to work together on features
>> off-master
>> >> > > would be really helpful.
>> >> > >
>> >> > > Andy
>> >> > >
>> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
>> >> > > michael.blumenkra...@gmail.com> wrote:
>> >> > >
>> >> > >> After some discussions about git organization, it's become clear
>> to me
>> >> > that
>> >> > >> we should be trying to enact some changes which facilitate
>> >> > collaboration,
>> >> > >> both between existing contributors and keeping in mind future
>> >> > contributors.
>> >> > >>
>> >> > >> The current git branch policy is this:
>> >> > >>
>> >> > >> * master
>> >> > >> * $project-$version
>> >> > >> * devs/$name/$branchname
>> >> > >>
>> >> > >> No others are allowed. This fits many use cases, but it does not
>> >> > actually
>> >> > >> help us work towards collaborating on features/patchsets and
>> instead
>> >> > >> promotes developing in isolation.
>> >> > >>
>> >> > >> A simple proposal could improve this without requiring or
>> significantly
>> >> > >> changing our workflow: add "feature/" branches. For example, if
>> Cedric
>> >> > and
>> >> > >> I decide to work on a "feature" which scrapes the archive of this
>> >> > mailing
>> >> > >> list and then crashes the session of anyone who replies to this
>> thread,
>> >> > we
>> >> > >> might jointly create a branch named "feature/discussion_helper"
>> and push
>> >> > >> commits to it.
>> >> > >>
>> >> > >> A key point of this proposal would be that the feature/ branches
>> must
>> >> > >> trigger mails to the mailing list just like stable branches. This
>> would
>> >> > >> increase visibility for feature branches as well as promote further
>> >> > >> collaboration even from those who are not directly involved in
>> creating
>> >> > the
>> >> > >> feature. The initial feature development could be done in a dev/
>> branch,
>> >> > >> and then it could later move to a feature/ branch once it has
>> >> > progressed to
>> >> > >> the point where it is ready for public visibility and increased
>> >> > >> collaboration.
>> >> > >>
>> >> > >> Lastly, feature branches would not be required use, just
>> encouraged.
>> >> > This
>> >> > >> allows people to continue the current EFL standard of always
>> committing
>> >> > >> only to master without any prior testing or branching, the need for
>> >> > which
>> >> > >> has defeated other proposals which would prevent such action.
>> >> > >>
>> >> > >> I think this could yield significant improvements to the
>> community's
>> >> > >> overall workflow without massively changing the structure under
>> which
>> >> > the
>> >> > >> everyone has been functioning.
>> >> > >>
>> >> > >>
>> >> >
>> --
>> >> > >> Check out the vibrant tech community on one of the world's most
>> >> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> > >> ___
>> >> > >> enlightenment-devel mailing list
>> >> > >> enlightenment-devel@lists.sourceforge.net
>> >> > >> 

Re: [E-devel] Git Feature/ Proposal

[Mike Blumenkrantz]

I've added all the necessary info to the documentation at
https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches

If the jenkins concept is not possible then feel free to remove, but the
rest should be in line with what we want.

On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen  wrote:

> So what has been decided? What should I do? I need specs, preferably
> already added to the git wiki page so there are docs for this thing.
>
> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler 
> wrote:
> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> >  said:
> >
> >> Key points for the implementation:
> >>
> >> * all commits send mails to the list
> >> * no rewrite of pushed commits
> >>
> >> Things to consider:
> >> * how are feature/ branches deleted?
> >>  - maybe anyone can delete?
> >
> > Good point. these need deletion. after a few years it'll be a mess of old
> > feature branches no one will ever look at again. The merge to master
> should
> > contain all the history and log that is needed at that point for history
> > digging.
> >
> >> * do probies get feature/ push access?
> >>  - seems like they should?
> >>
> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:
> >>
> >> > Yeah, good idea.
> >> >
> >> > I'll take a look into implementing it soon.
> >> >
> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams  >
> >> > wrote:
> >> > > Hi,
> >> > >
> >> > > That sounds great - the ability to work together on features
> off-master
> >> > > would be really helpful.
> >> > >
> >> > > Andy
> >> > >
> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> >> > > michael.blumenkra...@gmail.com> wrote:
> >> > >
> >> > >> After some discussions about git organization, it's become clear
> to me
> >> > that
> >> > >> we should be trying to enact some changes which facilitate
> >> > collaboration,
> >> > >> both between existing contributors and keeping in mind future
> >> > contributors.
> >> > >>
> >> > >> The current git branch policy is this:
> >> > >>
> >> > >> * master
> >> > >> * $project-$version
> >> > >> * devs/$name/$branchname
> >> > >>
> >> > >> No others are allowed. This fits many use cases, but it does not
> >> > actually
> >> > >> help us work towards collaborating on features/patchsets and
> instead
> >> > >> promotes developing in isolation.
> >> > >>
> >> > >> A simple proposal could improve this without requiring or
> significantly
> >> > >> changing our workflow: add "feature/" branches. For example, if
> Cedric
> >> > and
> >> > >> I decide to work on a "feature" which scrapes the archive of this
> >> > mailing
> >> > >> list and then crashes the session of anyone who replies to this
> thread,
> >> > we
> >> > >> might jointly create a branch named "feature/discussion_helper"
> and push
> >> > >> commits to it.
> >> > >>
> >> > >> A key point of this proposal would be that the feature/ branches
> must
> >> > >> trigger mails to the mailing list just like stable branches. This
> would
> >> > >> increase visibility for feature branches as well as promote further
> >> > >> collaboration even from those who are not directly involved in
> creating
> >> > the
> >> > >> feature. The initial feature development could be done in a dev/
> branch,
> >> > >> and then it could later move to a feature/ branch once it has
> >> > progressed to
> >> > >> the point where it is ready for public visibility and increased
> >> > >> collaboration.
> >> > >>
> >> > >> Lastly, feature branches would not be required use, just
> encouraged.
> >> > This
> >> > >> allows people to continue the current EFL standard of always
> committing
> >> > >> only to master without any prior testing or branching, the need for
> >> > which
> >> > >> has defeated other proposals which would prevent such action.
> >> > >>
> >> > >> I think this could yield significant improvements to the
> community's
> >> > >> overall workflow without massively changing the structure under
> which
> >> > the
> >> > >> everyone has been functioning.
> >> > >>
> >> > >>
> >> >
> --
> >> > >> Check out the vibrant tech community on one of the world's most
> >> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > >> ___
> >> > >> enlightenment-devel mailing list
> >> > >> enlightenment-devel@lists.sourceforge.net
> >> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> > >>
> >> > > --
> >> > > http://andywilliams.me
> >> > > http://ajwillia.ms
> >> > >
> >> >
> --
> >> > > Check out the vibrant tech community on one of the world's most
> >> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > > ___
> >> > > enlightenment-devel 

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

So what has been decided? What should I do? I need specs, preferably
already added to the git wiki page so there are docs for this thing.

On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler  wrote:
> On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>  said:
>
>> Key points for the implementation:
>>
>> * all commits send mails to the list
>> * no rewrite of pushed commits
>>
>> Things to consider:
>> * how are feature/ branches deleted?
>>  - maybe anyone can delete?
>
> Good point. these need deletion. after a few years it'll be a mess of old
> feature branches no one will ever look at again. The merge to master should
> contain all the history and log that is needed at that point for history
> digging.
>
>> * do probies get feature/ push access?
>>  - seems like they should?
>>
>> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:
>>
>> > Yeah, good idea.
>> >
>> > I'll take a look into implementing it soon.
>> >
>> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams 
>> > wrote:
>> > > Hi,
>> > >
>> > > That sounds great - the ability to work together on features off-master
>> > > would be really helpful.
>> > >
>> > > Andy
>> > >
>> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
>> > > michael.blumenkra...@gmail.com> wrote:
>> > >
>> > >> After some discussions about git organization, it's become clear to me
>> > that
>> > >> we should be trying to enact some changes which facilitate
>> > collaboration,
>> > >> both between existing contributors and keeping in mind future
>> > contributors.
>> > >>
>> > >> The current git branch policy is this:
>> > >>
>> > >> * master
>> > >> * $project-$version
>> > >> * devs/$name/$branchname
>> > >>
>> > >> No others are allowed. This fits many use cases, but it does not
>> > actually
>> > >> help us work towards collaborating on features/patchsets and instead
>> > >> promotes developing in isolation.
>> > >>
>> > >> A simple proposal could improve this without requiring or significantly
>> > >> changing our workflow: add "feature/" branches. For example, if Cedric
>> > and
>> > >> I decide to work on a "feature" which scrapes the archive of this
>> > mailing
>> > >> list and then crashes the session of anyone who replies to this thread,
>> > we
>> > >> might jointly create a branch named "feature/discussion_helper" and push
>> > >> commits to it.
>> > >>
>> > >> A key point of this proposal would be that the feature/ branches must
>> > >> trigger mails to the mailing list just like stable branches. This would
>> > >> increase visibility for feature branches as well as promote further
>> > >> collaboration even from those who are not directly involved in creating
>> > the
>> > >> feature. The initial feature development could be done in a dev/ branch,
>> > >> and then it could later move to a feature/ branch once it has
>> > progressed to
>> > >> the point where it is ready for public visibility and increased
>> > >> collaboration.
>> > >>
>> > >> Lastly, feature branches would not be required use, just encouraged.
>> > This
>> > >> allows people to continue the current EFL standard of always committing
>> > >> only to master without any prior testing or branching, the need for
>> > which
>> > >> has defeated other proposals which would prevent such action.
>> > >>
>> > >> I think this could yield significant improvements to the community's
>> > >> overall workflow without massively changing the structure under which
>> > the
>> > >> everyone has been functioning.
>> > >>
>> > >>
>> > --
>> > >> Check out the vibrant tech community on one of the world's most
>> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > >> ___
>> > >> enlightenment-devel mailing list
>> > >> enlightenment-devel@lists.sourceforge.net
>> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> > >>
>> > > --
>> > > http://andywilliams.me
>> > > http://ajwillia.ms
>> > >
>> > --
>> > > Check out the vibrant tech community on one of the world's most
>> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > > ___
>> > > enlightenment-devel mailing list
>> > > enlightenment-devel@lists.sourceforge.net
>> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> >
>> >
>> > --
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > ___
>> > enlightenment-devel mailing list
>> > enlightenment-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> >
>> 

Re: [E-devel] Git Feature/ Proposal

[Carsten Haitzler]

On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
 said:

> Key points for the implementation:
> 
> * all commits send mails to the list
> * no rewrite of pushed commits
> 
> Things to consider:
> * how are feature/ branches deleted?
>  - maybe anyone can delete?

Good point. these need deletion. after a few years it'll be a mess of old
feature branches no one will ever look at again. The merge to master should
contain all the history and log that is needed at that point for history
digging.

> * do probies get feature/ push access?
>  - seems like they should?
> 
> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:
> 
> > Yeah, good idea.
> >
> > I'll take a look into implementing it soon.
> >
> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams 
> > wrote:
> > > Hi,
> > >
> > > That sounds great - the ability to work together on features off-master
> > > would be really helpful.
> > >
> > > Andy
> > >
> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> > > michael.blumenkra...@gmail.com> wrote:
> > >
> > >> After some discussions about git organization, it's become clear to me
> > that
> > >> we should be trying to enact some changes which facilitate
> > collaboration,
> > >> both between existing contributors and keeping in mind future
> > contributors.
> > >>
> > >> The current git branch policy is this:
> > >>
> > >> * master
> > >> * $project-$version
> > >> * devs/$name/$branchname
> > >>
> > >> No others are allowed. This fits many use cases, but it does not
> > actually
> > >> help us work towards collaborating on features/patchsets and instead
> > >> promotes developing in isolation.
> > >>
> > >> A simple proposal could improve this without requiring or significantly
> > >> changing our workflow: add "feature/" branches. For example, if Cedric
> > and
> > >> I decide to work on a "feature" which scrapes the archive of this
> > mailing
> > >> list and then crashes the session of anyone who replies to this thread,
> > we
> > >> might jointly create a branch named "feature/discussion_helper" and push
> > >> commits to it.
> > >>
> > >> A key point of this proposal would be that the feature/ branches must
> > >> trigger mails to the mailing list just like stable branches. This would
> > >> increase visibility for feature branches as well as promote further
> > >> collaboration even from those who are not directly involved in creating
> > the
> > >> feature. The initial feature development could be done in a dev/ branch,
> > >> and then it could later move to a feature/ branch once it has
> > progressed to
> > >> the point where it is ready for public visibility and increased
> > >> collaboration.
> > >>
> > >> Lastly, feature branches would not be required use, just encouraged.
> > This
> > >> allows people to continue the current EFL standard of always committing
> > >> only to master without any prior testing or branching, the need for
> > which
> > >> has defeated other proposals which would prevent such action.
> > >>
> > >> I think this could yield significant improvements to the community's
> > >> overall workflow without massively changing the structure under which
> > the
> > >> everyone has been functioning.
> > >>
> > >>
> > --
> > >> Check out the vibrant tech community on one of the world's most
> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >> ___
> > >> enlightenment-devel mailing list
> > >> enlightenment-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >>
> > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> > >
> > --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> 

Re: [E-devel] Git Feature/ Proposal

[Mike Blumenkrantz]

Key points for the implementation:

* all commits send mails to the list
* no rewrite of pushed commits

Things to consider:
* how are feature/ branches deleted?
 - maybe anyone can delete?
* do probies get feature/ push access?
 - seems like they should?

On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen  wrote:

> Yeah, good idea.
>
> I'll take a look into implementing it soon.
>
> On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams 
> wrote:
> > Hi,
> >
> > That sounds great - the ability to work together on features off-master
> > would be really helpful.
> >
> > Andy
> >
> > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> > michael.blumenkra...@gmail.com> wrote:
> >
> >> After some discussions about git organization, it's become clear to me
> that
> >> we should be trying to enact some changes which facilitate
> collaboration,
> >> both between existing contributors and keeping in mind future
> contributors.
> >>
> >> The current git branch policy is this:
> >>
> >> * master
> >> * $project-$version
> >> * devs/$name/$branchname
> >>
> >> No others are allowed. This fits many use cases, but it does not
> actually
> >> help us work towards collaborating on features/patchsets and instead
> >> promotes developing in isolation.
> >>
> >> A simple proposal could improve this without requiring or significantly
> >> changing our workflow: add "feature/" branches. For example, if Cedric
> and
> >> I decide to work on a "feature" which scrapes the archive of this
> mailing
> >> list and then crashes the session of anyone who replies to this thread,
> we
> >> might jointly create a branch named "feature/discussion_helper" and push
> >> commits to it.
> >>
> >> A key point of this proposal would be that the feature/ branches must
> >> trigger mails to the mailing list just like stable branches. This would
> >> increase visibility for feature branches as well as promote further
> >> collaboration even from those who are not directly involved in creating
> the
> >> feature. The initial feature development could be done in a dev/ branch,
> >> and then it could later move to a feature/ branch once it has
> progressed to
> >> the point where it is ready for public visibility and increased
> >> collaboration.
> >>
> >> Lastly, feature branches would not be required use, just encouraged.
> This
> >> allows people to continue the current EFL standard of always committing
> >> only to master without any prior testing or branching, the need for
> which
> >> has defeated other proposals which would prevent such action.
> >>
> >> I think this could yield significant improvements to the community's
> >> overall workflow without massively changing the structure under which
> the
> >> everyone has been functioning.
> >>
> >>
> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> > --
> > http://andywilliams.me
> > http://ajwillia.ms
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

Yeah, good idea.

I'll take a look into implementing it soon.

On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams  wrote:
> Hi,
>
> That sounds great - the ability to work together on features off-master
> would be really helpful.
>
> Andy
>
> On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
>
>> After some discussions about git organization, it's become clear to me that
>> we should be trying to enact some changes which facilitate collaboration,
>> both between existing contributors and keeping in mind future contributors.
>>
>> The current git branch policy is this:
>>
>> * master
>> * $project-$version
>> * devs/$name/$branchname
>>
>> No others are allowed. This fits many use cases, but it does not actually
>> help us work towards collaborating on features/patchsets and instead
>> promotes developing in isolation.
>>
>> A simple proposal could improve this without requiring or significantly
>> changing our workflow: add "feature/" branches. For example, if Cedric and
>> I decide to work on a "feature" which scrapes the archive of this mailing
>> list and then crashes the session of anyone who replies to this thread, we
>> might jointly create a branch named "feature/discussion_helper" and push
>> commits to it.
>>
>> A key point of this proposal would be that the feature/ branches must
>> trigger mails to the mailing list just like stable branches. This would
>> increase visibility for feature branches as well as promote further
>> collaboration even from those who are not directly involved in creating the
>> feature. The initial feature development could be done in a dev/ branch,
>> and then it could later move to a feature/ branch once it has progressed to
>> the point where it is ready for public visibility and increased
>> collaboration.
>>
>> Lastly, feature branches would not be required use, just encouraged. This
>> allows people to continue the current EFL standard of always committing
>> only to master without any prior testing or branching, the need for which
>> has defeated other proposals which would prevent such action.
>>
>> I think this could yield significant improvements to the community's
>> overall workflow without massively changing the structure under which the
>> everyone has been functioning.
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> --
> http://andywilliams.me
> http://ajwillia.ms
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Git Feature/ Proposal

[Andrew Williams]

Hi,

That sounds great - the ability to work together on features off-master
would be really helpful.

Andy

On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> After some discussions about git organization, it's become clear to me that
> we should be trying to enact some changes which facilitate collaboration,
> both between existing contributors and keeping in mind future contributors.
>
> The current git branch policy is this:
>
> * master
> * $project-$version
> * devs/$name/$branchname
>
> No others are allowed. This fits many use cases, but it does not actually
> help us work towards collaborating on features/patchsets and instead
> promotes developing in isolation.
>
> A simple proposal could improve this without requiring or significantly
> changing our workflow: add "feature/" branches. For example, if Cedric and
> I decide to work on a "feature" which scrapes the archive of this mailing
> list and then crashes the session of anyone who replies to this thread, we
> might jointly create a branch named "feature/discussion_helper" and push
> commits to it.
>
> A key point of this proposal would be that the feature/ branches must
> trigger mails to the mailing list just like stable branches. This would
> increase visibility for feature branches as well as promote further
> collaboration even from those who are not directly involved in creating the
> feature. The initial feature development could be done in a dev/ branch,
> and then it could later move to a feature/ branch once it has progressed to
> the point where it is ready for public visibility and increased
> collaboration.
>
> Lastly, feature branches would not be required use, just encouraged. This
> allows people to continue the current EFL standard of always committing
> only to master without any prior testing or branching, the need for which
> has defeated other proposals which would prevent such action.
>
> I think this could yield significant improvements to the community's
> overall workflow without massively changing the structure under which the
> everyone has been functioning.
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
-- 
http://andywilliams.me
http://ajwillia.ms
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Git Feature/ Proposal

[Christopher Michael]

On 11/07/2017 01:10 PM, Cedric Bail wrote:

Hi,


 Original Message 
Subject: [E-devel] Git Feature/ Proposal
Local Time: November 7, 2017 8:13 AM
UTC Time: November 7, 2017 4:13 PM
From: michael.blumenkra...@gmail.com
To: Enlightenment developer list 

After some discussions about git organization, it's become clear to me that
we should be trying to enact some changes which facilitate collaboration,
both between existing contributors and keeping in mind future contributors.

The current git branch policy is this:

- master
- $project-$version
- devs/$name/$branchname

No others are allowed. This fits many use cases, but it does not actually
help us work towards collaborating on features/patchsets and instead
promotes developing in isolation.

A simple proposal could improve this without requiring or significantly
changing our workflow: add "feature/" branches. For example, if Cedric and
I decide to work on a "feature" which scrapes the archive of this mailing
list and then crashes the session of anyone who replies to this thread, we
might jointly create a branch named "feature/discussion_helper" and push
commits to it.


Is the session crashing the part you like Cedric ?? ;)



A key point of this proposal would be that the feature/ branches must
trigger mails to the mailing list just like stable branches. This would
increase visibility for feature branches as well as promote further
collaboration even from those who are not directly involved in creating the
feature. The initial feature development could be done in a dev/ branch,
and then it could later move to a feature/ branch once it has progressed to
the point where it is ready for public visibility and increased
collaboration.

Lastly, feature branches would not be required use, just encouraged. This
allows people to continue the current EFL standard of always committing
only to master without any prior testing or branching, the need for which
has defeated other proposals which would prevent such action.

I think this could yield significant improvements to the community's
overall workflow without massively changing the structure under which the
everyone has been functioning.


I like this proposal as it should help team work. Good idea.

Cedric




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Git Feature/ Proposal

[Cedric Bail]

Hi,

>  Original Message 
> Subject: [E-devel] Git Feature/ Proposal
> Local Time: November 7, 2017 8:13 AM
> UTC Time: November 7, 2017 4:13 PM
> From: michael.blumenkra...@gmail.com
> To: Enlightenment developer list 
>
> After some discussions about git organization, it's become clear to me that
> we should be trying to enact some changes which facilitate collaboration,
> both between existing contributors and keeping in mind future contributors.
>
> The current git branch policy is this:
>
> - master
> - $project-$version
> - devs/$name/$branchname
>
> No others are allowed. This fits many use cases, but it does not actually
> help us work towards collaborating on features/patchsets and instead
> promotes developing in isolation.
>
> A simple proposal could improve this without requiring or significantly
> changing our workflow: add "feature/" branches. For example, if Cedric and
> I decide to work on a "feature" which scrapes the archive of this mailing
> list and then crashes the session of anyone who replies to this thread, we
> might jointly create a branch named "feature/discussion_helper" and push
> commits to it.
>
> A key point of this proposal would be that the feature/ branches must
> trigger mails to the mailing list just like stable branches. This would
> increase visibility for feature branches as well as promote further
> collaboration even from those who are not directly involved in creating the
> feature. The initial feature development could be done in a dev/ branch,
> and then it could later move to a feature/ branch once it has progressed to
> the point where it is ready for public visibility and increased
> collaboration.
>
> Lastly, feature branches would not be required use, just encouraged. This
> allows people to continue the current EFL standard of always committing
> only to master without any prior testing or branching, the need for which
> has defeated other proposals which would prevent such action.
>
> I think this could yield significant improvements to the community's
> overall workflow without massively changing the structure under which the
> everyone has been functioning.

I like this proposal as it should help team work. Good idea.

Cedric
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel