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. >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >> >> >> >
