It actually doesn't change anything to rebase a branch repeatedly. The original timestamp of the commit will remain unchanged throughout.
git bisect is essentially a binary search between two revisions. It's usually used to determine when a bug was introduced, by giving it a known good and known bad commit. it will load a commit in between, you test, run either git bisect good or git bisect bad, rinse and repeat. eventually it will narrow down to a single commit, or a few, that introduce a bug. It's often faster to just git log <some file> or git blame <some file> to see the more localized changes. But that only works when you can localize the bug to a file or directory. Braden On Tue, Apr 30, 2013 at 3:37 PM, Anis KADRI <[email protected]> wrote: > 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 <[email protected] > >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 <[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. > > > > >> > > >> >>>>>>>>> > > > > >> > > >> >>>>>>>> > > > > >> > > >> >>>>>>>> > > > > >> > > >> >>>>>>> > > > > >> > > >> >>>>>> > > > > >> > > >> >>>> > > > > >> > > >> >>>> > > > > >> > > >> >>>> > > > > >> > > >> >>>> > > > > >> > > >> >>>> > > > > >> > > >> >>>> > > > > >> > > >> >>>> > > > > >> > > >> >>>> > > > > >> > > >> >>> > > > > >> > > >> >>> > > > > >> > > >> >> > > > > >> > > >> > > > > >> > > >> > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > >
