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