Yeah, I wasn't trying to advocate his approach but I did learn new things
such as that git log didn't show commits in chronological order after
rebase. I wrongly assumed it did and that it placed the commits by commit
date (and not push date). The question is: How do you know specifically
which commit caused a bug or if it was even a bunch of commits ? I've never
used git bisect and will look into it, maybe that is the answer.
At any rate, rebasing should obviously be done regularly and not 2 years
later.
On Tue, Apr 30, 2013 at 3:20 PM, Braden Shepherdson <bra...@chromium.org>wrote:
> tl;dr: Author didn't read the docs for git log and git rebase carefully
> enough. They don't work like he suggests, and his example of wanting to
> bisect based on history works just fine if he knew to ignore the timestamps
> and trust the --{since,before,after,until} options; they do the right
> thing. Rebasing is fine and we should carry on using it.
>
>
>
> He's right that working in feature branches rather than on master or some
> other long-lived branch is the right way to do things in git. That's true
> whether your workflow uses rebase or not, and I think most of us do that
> already. Certainly our contributor guide recommends it.
>
> I disagree with his criticism of rebase, however. Most of the article is
> about the alternatives, not about rebase. His fundmental problem with
> rebasing is how it handles timestamps.
>
> It's more complex than simply "the timestamp". Git separates the authorship
> of a commit from its committing. We see this all the time with attribution,
> where a Cordova committer commits an external contributor's change. The
> external contributor is the author, and the Cordova committer is the
> committer. Likewise there is an authorship timestamp and a commit
> timestamp. Rebasing updates only the latter, as you would expect. When
> squashing commits with an interactive rebase, it uses the author and
> authorship timestamp of the first commit being squashed.
>
> git log by default orders commits based on their "topological" order, that
> is, following the ancestor chain. That means that a two-year-old commit
> freshly rebased on top of master appears at the top of git log (because it
> was replayed on top of HEAD), but with its (authorship) timestamp intact as
> years before.
>
> So my main exception to his article and argument is that he supposes git
> log is /chronological/ order, which it is not and never claimed to be.
>
> git bisect uses the same order as git log, because it's important that
> child commits come after their parent(s). Timestamps are irrelevant here.
> If you get a bug report about a bug first noticed on Tuesday afternoon, the
> correct approach is not to swear off rebasing for the horrible damage it
> did to your repository, but to retrieve the actual state of the repo at
> that time. That has nothing to do with authorship timestamps but instead
> with commit timestamps -- when things were really put into the repo.
>
> Getting git log to actually show you the commit timestamp is impossible(?)
> but it doesn't matter: the --since, --after, --before and --until limiting
> flags show you commits based on when they entered the repository, not on
> their authorship time. So the solution to his "bug introduced last Tuesday"
> problem using git bisest is to use git log --before=<Tuesday morning> and
> pick a commit that worked, and git log --before<Tuesday evening> to pick a
> commit that is broken, and then feed them to git bisect.
>
>
> Braden
>
>
> On Tue, Apr 30, 2013 at 2:38 PM, Anis KADRI <anis.ka...@gmail.com> wrote:
>
> >
> >
> 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.
> > > >> > > >> >>>>>>>>>
> > > >> > > >> >>>>>>>>
> > > >> > > >> >>>>>>>>
> > > >> > > >> >>>>>>>
> > > >> > > >> >>>>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>
> > > >> > > >> >>>
> > > >> > > >> >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> > >
> >
>
