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