+1 On 4/4/13 10:35 AM, "Michal Mocny" <mmo...@chromium.org> wrote:
>With all the use of "merge" and "rebase" here I wasn't 100% clear what we >were advising. After some discussion, I think the consensus is that: > >1. Rebase your branch with master (this changes only your branch, so that >you apply work on top of most recent master commits) >1b. Rebase your branch with itself with -i to squash commits (to merge >work >into single atomic commits) >2. merge --ff-only your feature on top of master now >3. push > >Right? > >I think saying "I prefer rebase" isn't helping git noobs figure out what >to >rebase and that you still need a merge at the end, etc. > >As Andrew said, we already advice to do this on the wiki, lets stick with >it. > >-Michal > > >On Thu, Apr 4, 2013 at 9:03 AM, Lorin Beer <lorin.beer....@gmail.com> >wrote: > >> the only way I know of to check is manually diff. What's weird is that I >> received no merge conflict notification when I reverted Max's fix, it >>just >> silently favoured my version of CDVCamera.h. >> >> >> On Wed, Apr 3, 2013 at 8:25 PM, Max Woghiren <m...@google.com> wrote: >> >> > That crossed my mind, but I didn't know of a way offhand to determine >>if >> > anything else was reverted. My commit's reversion was hidden away in >>an >> > unrelated commit that was merged. >> > >> > >> > On Wed, Apr 3, 2013 at 11:17 PM, Andrew Grieve <agri...@chromium.org> >> > wrote: >> > >> > > Hmm, another question - Max / Lorin, have you checked if any other >> > commits >> > > were reverted? (is there a way to check?) >> > > >> > > >> > > On Wed, Apr 3, 2013 at 11:08 PM, Andrew Grieve >><agri...@chromium.org> >> > > wrote: >> > > >> > > > Note that we mandate pull requests to be rebased on our wiki: >> > > > http://wiki.apache.org/cordova/ContributorWorkflow >> > > > And we tell committers to rebase as well here: >> > > > http://wiki.apache.org/cordova/CommitterWorkflow >> > > > >> > > > Rebasing is safe in that if you've done it wrong, you'll get an >>error >> > > when >> > > > you try to push it. >> > > > >> > > > In terms of git emails, rebasing does not cause spam unless you >> rebase >> > a >> > > > remote feature branch and then force push it. To solve this, we >> should >> > > > probably just not use remote feature branches on apache's git >>servers >> > > (just >> > > > use your own github for them). >> > > > >> > > > >> > > > On Wed, Apr 3, 2013 at 4:17 PM, James Jong <wjamesj...@gmail.com> >> > wrote: >> > > > >> > > >> I generally prefer rebasing so that I can see / choose the >> individual >> > > >> commits. >> > > >> >> > > >> -James Jong >> > > >> >> > > >> On Apr 3, 2013, at 2:34 PM, Lorin Beer <lorin.beer....@gmail.com> >> > > wrote: >> > > >> >> > > >> > I'm leaning towards rebasing. I felt that rebasing was the more >> > > >> dangerous >> > > >> > option, due to the potential/power of changing history that is >> > already >> > > >> > upstream, but I find the merge commits annoying as well. It >>sounds >> > > like >> > > >> > whenever this happens, our list is going to get spammed >> regardless. >> > > >> > >> > > >> > >> > > >> > On Wed, Apr 3, 2013 at 11:24 AM, Anis KADRI >><anis.ka...@gmail.com >> > >> > > >> wrote: >> > > >> > >> > > >> >> Things start to suck if everyone does it differently (some do >> > merges, >> > > >> some >> > > >> >> do rebases). I like rebase better because it provides a >>clear/n >> > > >> history. I >> > > >> >> usually do merges because I know that most people do that as >> well. >> > I >> > > >> would >> > > >> >> like to do rebase instead but everyone else has to do that to >> avoid >> > > >> >> problems/conflicts. >> > > >> >> >> > > >> >> >> > > >> >> On Wed, Apr 3, 2013 at 10:50 AM, Filip Maj <f...@adobe.com> >> wrote: >> > > >> >> >> > > >> >>> In terms of the git notification emails, merge or rebase, >> doesn't >> > > >> matter. >> > > >> >>> Each commit that is being merged in in the case of a merge, >>or >> > > >> reapplied >> > > >> >>> in the case of a rebase, will be sent as a notification. So >>we >> > lose >> > > >> >> either >> > > >> >>> way. Woot. >> > > >> >>> >> > > >> >>> In the case of rebase vs merge in terms of workflow, merge >>drops >> > all >> > > >> >>> commits that are coming in from a branch as a single diff and >> > > applies >> > > >> >> them >> > > >> >>> in one go to the top of the branch you are merging into. >> Handling >> > > >> >>> conflicts at this point can be overwhelming if you are >>dealing >> > with >> > > >> >>> conflicts from potentially multiple commits. >> > > >> >>> >> > > >> >>> With rebase, you are essentially "grafting" your branch to >>the >> end >> > > of >> > > >> the >> > > >> >>> branch you are rebasing. Each of your branch's commits are >> > reapplied >> > > >> one >> > > >> >>> at a time to the end of the rebase branch. If a conflict >>happens >> > at >> > > >> any >> > > >> >>> point during application of your branch's commits, one at a >> time, >> > > the >> > > >> >>> rebase stops, and you have to resolve the conflicts. This >>can be >> > > >> easier >> > > >> >> in >> > > >> >>> the sense that you have to just deal with one commit's >>changes >> at >> > a >> > > >> time. >> > > >> >>> The downside is if your branch has diverged drastically, you >> will >> > > >> >> probably >> > > >> >>> be dealing with these conflicts on every commit, which can be >> time >> > > >> >>> consuming and long. >> > > >> >>> >> > > >> >>> My go-to is usually rebase, as I have a better idea of how my >> > > changes >> > > >> >>> modify the codebase. That said, there are times to use merge >>as >> > > well. >> > > >> >>> >> > > >> >>> On 4/3/13 1:40 PM, "Lorin Beer" <lorin.beer....@gmail.com> >> wrote: >> > > >> >>> >> > > >> >>>> hmm, I was under the impression that rebasing was more >> dangerous, >> > > >> I'll >> > > >> >>>> reassess my workflow. >> > > >> >>>> >> > > >> >>>> Sorry for the trouble Max! >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> On Wed, Apr 3, 2013 at 9:03 AM, Filip Maj <f...@adobe.com> >> wrote: >> > > >> >>>> >> > > >> >>>> Merges are dangerous in that sense. Rebase when you can! >> > > >> >>>> >> > > >> >>>> On 4/3/13 11:59 AM, "Max Woghiren" <m...@google.com> wrote: >> > > >> >>>> >> > > >> >>>>> Just wanted to quickly chime in here‹Lorin, your sizeable >> merge >> > > >> >> reverted >> > > >> >>>>> one of my bug fixes (CB-2732). Not a huge deal, and a >>re-fix >> is >> > > on >> > > >> the >> > > >> >>>>> way, but try to be extra careful when doing merges like >>that. >> :) >> > > >> >>>>> >> > > >> >>>>> >> > > >> >>>>> On Tue, Apr 2, 2013 at 8:33 PM, Andrew Grieve < >> > > agri...@chromium.org >> > > >> > >> > > >> >>>>> wrote: >> > > >> >>>>> >> > > >> >>>>>> Sounds good. Cool graph Jesse! >> > > >> >>>>>> >> > > >> >>>>>> >> > > >> >>>>>> >> > > >> >>>>>> On Tue, Apr 2, 2013 at 4:49 PM, Lorin Beer < >> > > >> lorin.beer....@gmail.com >> > > >> >>> >> > > >> >>>>>> wrote: >> > > >> >>>>>> >> > > >> >>>>>>> hmm, likely a merge. A local commit before pulling in >> upstream >> > > >> >>>>>> changes, >> > > >> >>>>>>> then doing a merge seems to be the cause. >> > > >> >>>>>>> >> > > >> >>>>>>> >> > > >> >>>>>>> On Tue, Apr 2, 2013 at 1:07 PM, Jesse < >> > purplecabb...@gmail.com> >> > > >> >>>>>> wrote: >> > > >> >>>>>>> >> > > >> >>>>>>>> merging most likely, set up a filter. >> > > >> >>>>>>>> I commit to master, checkout 2.6.x, pull master, push >>2.6.x >> > > >> >> because >> > > >> >>>>>> I >> > > >> >>>>>>>> want all the work I am doing in 2.6.0 >> > > >> >>>>>>>> >> > > >> >>>>>>>> https://github.com/purplecabbage/cordova-wp8/network >> > > >> >>>>>>>> Looks good to me ... >> > > >> >>>>>>>> >> > > >> >>>>>>>> @purplecabbage >> > > >> >>>>>>>> risingj.com <http://risingj.com> >> > > >> >>>>>>>> >> > > >> >>>>>>>> >> > > >> >>>>>>>> On Tue, Apr 2, 2013 at 12:52 PM, Andrew Grieve < >> > > >> >>> agri...@chromium.org >> > > >> >>>>>>> wrote: >> > > >> >>>>>>>> >> > > >> >>>>>>>>> There's quite a bit of email spam from both of you and >>I >> > > wasn't >> > > >> >>>>>> sure >> > > >> >>>>>>>>> what caused it? Do you know? >> > > >> >>>>>>>>> >> > > >> >>>>>>>>> rebasing? merging? branching? >> > > >> >>>>>>>>> >> > > >> >>>>>>>>> Hard to figure out what actually has changed when these >> > > happen, >> > > >> >> so >> > > >> >>>>>> I'd >> > > >> >>>>>>>>> like to figure out what causes them. I did one recently >> > where >> > > I >> > > >> >>>>>> rebased a >> > > >> >>>>>>>>> remote feature branch. >> > > >> >>>>>>>>> >> > > >> >>>>>>>> >> > > >> >>>>>>>> >> > > >> >>>>>>> >> > > >> >>>>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>> >> > > >> >>> >> > > >> >> >> > > >> >> > > >> >> > > > >> > > >> > >>
