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

Reply via email to