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 <[email protected]> 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 <[email protected]> > 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 <[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. > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>> > >> >>>>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>> > >> >>> > >> >> > >> > >> > > >
