You need to add them to "ignore branches" on phab. Stefan? :P On Wed, Nov 29, 2017 at 4:30 AM, Jean-Philippe André <j...@videolan.org> 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 <sfl...@suse.de> 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é <j...@videolan.org> >> 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 <t...@stosb.com>: >> >> >> >>> 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 >> >>> <michael.blumenkra...@gmail.com> 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 <t...@stosb.com> 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 >> >>>>> <michael.blumenkra...@gmail.com> 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 <t...@stosb.com>: >> >>>>>>> >> >>>>>>>> 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 >> >>>>>>>> <michael.blumenkra...@gmail.com> 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 <t...@stosb.com> >> >>> 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 +0000 Mike Blumenkrantz >> >>>>>>>>>>> <michael.blumenkra...@gmail.com> 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 <t...@stosb.com> >> >>>>> 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 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 >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> -- >> >>>>>>>>>>> ------------- Codito, ergo sum - "I code, therefore I am" >> >>>>>>>> -------------- >> >>>>>>>>>>> Carsten Haitzler - ras...@rasterman.com >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> ------------------------------------------------------------ >> >>>>>>>> ------------------ >> >>>>>>>>>>> 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 >> >>>>>>>> >> >>>>>>>> ------------------------------------------------------------ >> >>>>>>>> ------------------ >> >>>>>>>> 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 >> >>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Jean-Philippe André >> >>>>>>> >> >>>>>>> >> >>>>> ------------------------------------------------------------ >> >>> ------------------ >> >>>>>>> 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 >> >>>>> >> >>>> ------------------------------------------------------------ >> >>> ------------------ >> >>>> 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 >> >>> >> >> >> >> >> >> >> >> -- >> >> Jean-Philippe André >> >> >> >> ------------------------------------------------------------ >> ------------------ >> >> 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 >> >> >> >> -- >> >> Simon Lees (Simotek) http://simotek.net >> >> Emergency Update Team keybase.io/simotek >> SUSE Linux Adelaide Australia, UTC+10:30 >> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B >> >> >> ------------------------------------------------------------ >> ------------------ >> 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 >> >> > > > -- > Jean-Philippe André > ------------------------------------------------------------------------------ > 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
