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 "igno
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
--
Che
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?
>
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
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 pres
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
signifi
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 w
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 prob
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#,
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
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 befo
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
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
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 wo
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 doc
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
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
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
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
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 t
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
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 o
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
* d
24 matches
Mail list logo
