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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
