Fwiw I agree with D, I just don't have enough experience to state it so eloquently.
Pat is really in favor, I've got a bad feeling about it- you expressed my 'bad feeling' perfectly. Even though you aren't contributing as much (code) these days, you're still a very valued member of the community- and I think I speak for most when I say, your guidance and involvement on the mailing lists is still very appreciated. Please always feel encouraged to chime in. my .02 #communityovercode On Thu, Jul 20, 2017 at 6:46 PM, Dmitriy Lyubimov <dlie...@gmail.com> wrote: > Guys, > > as you know, my ability to contribute is very limited lately, so i don't > feel like my opinion is worth as much as that of a regular committer or > contributor. In the end people who contribute things should decide what > works for them. > > I just put forward a warning that while normally this workflow would not be > a problem IF people are aware of the flow and start their work off the dev > branch, based on my git/github experience, a newbie WILL fork from master > to a private PR branch of her/his own to commence contribution work. > > Which, according to proposed scheme, WILL be quite behind the dev branch > that she will then be asked to merge to. > > Which WILL catch the unsuspecting contributor unawares. They will find > they'd have a significant divergence to overcome in order to attain the > mergeability of their work. > > On Thu, Jul 20, 2017 at 9:06 AM, Dmitriy Lyubimov <dlie...@gmail.com> > wrote: > > > > > > > On Fri, Jun 23, 2017 at 8:23 AM, Pat Ferrel <p...@occamsmachete.com> > wrote: > > > >> I don’t know where to start here. Git flow does not address the merge > >> conflict problems you talk about. They have nothing to do with the > process > >> and are made no easier or harder by following it. > >> > > > > I thought i did demonstrate that it does make conflicts much more > probable > > per below. The point where you start your work and point where you merge > it > > do matter. This process does increase the gap between those (which > implies > > higher chance of conflicts and deeper divergence from the start). This is > > is the same reason why people try to merge most recent commit stack back > as > > often as possible. > > > > > >> > >> >> For example: > >> >> Master is at A > >> >> Dev branch is at A - B -C ... F. > >> >> > >> >> if I start working at master (A) then i wil generate conflicts if i > >> have > >> >> changed same files (lines) as in B, C, .. or F. > >> >> > >> >> If I start working at dev (F) then i will not have a chance to > generate > >> >> conflicts with B,C,..F but only with commits that happened after i > had > >> >> started. > >> >> > >> >> Also, if I start working at master (A) then github flow will suggest > me > >> >> to merge into master during PR. I guarantee 100% of first time PRs > >> will > >> >> trip on that in github. even if you put "start your work off dev not > >> >> master" 20 times into project readme. > >> >> > >> >> And then you will face the dilemma whether to ask people to resolve > >> merge > >> >> issues w.r.t. master and resubmit, which will result to high > >> contribtors' > >> >> attrition, or resolve them yourself without deep knowledge of the > >> author's > >> >> intent, which will result in delays and plain errors. > >> >> > >> >> -d > >> >> > >> > > >> > > >> > >> > > >
