http://geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
Interesting article. TL;DR - `rebase` actually messes up history chronology. It separates commits but they're apparently not in the right order. I did not know this. - branches should be (ab)used and favored to working on the same branch to avoid having "Merge" commit messages. On Thu, Apr 4, 2013 at 9:54 AM, Filip Maj <f...@adobe.com> wrote: > +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. > >> > > >> >>>>>>>>> > >> > > >> >>>>>>>> > >> > > >> >>>>>>>> > >> > > >> >>>>>>> > >> > > >> >>>>>> > >> > > >> >>>> > >> > > >> >>>> > >> > > >> >>>> > >> > > >> >>>> > >> > > >> >>>> > >> > > >> >>>> > >> > > >> >>>> > >> > > >> >>>> > >> > > >> >>> > >> > > >> >>> > >> > > >> >> > >> > > >> > >> > > >> > >> > > > > >> > > > >> > > >> > >
