cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: [1 of 15] commits
Date Tue, 30 Apr 2013 22:44:39 GMT
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 <anis.kadri@gmail.com> 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 <braden@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.kadri@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 <fil@adobe.com> wrote:
> > >
> > > > +1
> > > >
> > > > On 4/4/13 10:35 AM, "Michal Mocny" <mmocny@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.dev@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 <maxw@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 <
> > > agrieve@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
> > > > >><agrieve@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 <
> > > wjamesjong@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.dev@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.kadri@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 <
> fil@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.dev@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 <
> > fil@adobe.com>
> > > > >> wrote:
> > > > >> > > >> >>>>
> > > > >> > > >> >>>> Merges are dangerous in that
sense. Rebase when you
> can!
> > > > >> > > >> >>>>
> > > > >> > > >> >>>> On 4/3/13 11:59 AM, "Max
Woghiren" <maxw@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 <
> > > > >> > > agrieve@chromium.org
> > > > >> > > >> >
> > > > >> > > >> >>>>> wrote:
> > > > >> > > >> >>>>>
> > > > >> > > >> >>>>>> Sounds good. Cool
graph Jesse!
> > > > >> > > >> >>>>>>
> > > > >> > > >> >>>>>>
> > > > >> > > >> >>>>>>
> > > > >> > > >> >>>>>> On Tue, Apr 2, 2013
at 4:49 PM, Lorin Beer <
> > > > >> > > >> lorin.beer.dev@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 <
> > > > >> > purplecabbage@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 <
> > > > >> > > >> >>> agrieve@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.
> > > > >> > > >> >>>>>>>>>
> > > > >> > > >> >>>>>>>>
> > > > >> > > >> >>>>>>>>
> > > > >> > > >> >>>>>>>
> > > > >> > > >> >>>>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>
> > > > >> > > >> >>>
> > > > >> > > >> >>
> > > > >> > > >>
> > > > >> > > >>
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message