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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> wrote: > >>>> > >>>> Merges are dangerous in that sense. Rebase when you can! > >>>> > >>>> On 4/3/13 11:59 AM, "Max Woghiren" <[email protected]> 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 <[email protected]> > >>>>> wrote: > >>>>> > >>>>>> Sounds good. Cool graph Jesse! > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, Apr 2, 2013 at 4:49 PM, Lorin Beer < > [email protected] > >>> > >>>>>> 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 <[email protected]> > >>>>>> 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 < > >>> [email protected] > >>>>>>> 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. > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >
