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 <[email protected]> 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 <[email protected]> wrote: > > > +1 > > > > On 4/4/13 10:35 AM, "Michal Mocny" <[email protected]> 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 <[email protected]> > > >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 <[email protected]> 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 < > [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. > > >> > > >> >>>>>>>>> > > >> > > >> >>>>>>>> > > >> > > >> >>>>>>>> > > >> > > >> >>>>>>> > > >> > > >> >>>>>> > > >> > > >> >>>> > > >> > > >> >>>> > > >> > > >> >>>> > > >> > > >> >>>> > > >> > > >> >>>> > > >> > > >> >>>> > > >> > > >> >>>> > > >> > > >> >>>> > > >> > > >> >>> > > >> > > >> >>> > > >> > > >> >> > > >> > > >> > > >> > > >> > > >> > > > > > >> > > > > >> > > > >> > > > > >
