You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Braden Shepherdson <br...@chromium.org> on 2013/05/01 00:20:44 UTC
Re: [1 of 15] commits
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 <an...@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 <fi...@adobe.com> wrote:
>
> > +1
> >
> > On 4/4/13 10:35 AM, "Michal Mocny" <mm...@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 <lo...@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 <ma...@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
> > >><ag...@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 <fi...@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" <lo...@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 <fi...@adobe.com>
> > >> wrote:
> > >> > > >> >>>>
> > >> > > >> >>>> Merges are dangerous in that sense. Rebase when you can!
> > >> > > >> >>>>
> > >> > > >> >>>> On 4/3/13 11:59 AM, "Max Woghiren" <ma...@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.
> > >> > > >> >>>>>>>>>
> > >> > > >> >>>>>>>>
> > >> > > >> >>>>>>>>
> > >> > > >> >>>>>>>
> > >> > > >> >>>>>>
> > >> > > >> >>>>
> > >> > > >> >>>>
> > >> > > >> >>>>
> > >> > > >> >>>>
> > >> > > >> >>>>
> > >> > > >> >>>>
> > >> > > >> >>>>
> > >> > > >> >>>>
> > >> > > >> >>>
> > >> > > >> >>>
> > >> > > >> >>
> > >> > > >>
> > >> > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> >
>
Re: [1 of 15] commits
Posted by Braden Shepherdson <br...@chromium.org>.
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 <an...@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 <an...@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 <fi...@adobe.com> wrote:
> > >
> > > > +1
> > > >
> > > > On 4/4/13 10:35 AM, "Michal Mocny" <mm...@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 <ma...@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
> > > > >><ag...@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" <ma...@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.
> > > > >> > > >> >>>>>>>>>
> > > > >> > > >> >>>>>>>>
> > > > >> > > >> >>>>>>>>
> > > > >> > > >> >>>>>>>
> > > > >> > > >> >>>>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>>
> > > > >> > > >> >>>
> > > > >> > > >> >>>
> > > > >> > > >> >>
> > > > >> > > >>
> > > > >> > > >>
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: [1 of 15] commits
Posted by Anis KADRI <an...@gmail.com>.
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 <br...@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 <an...@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 <fi...@adobe.com> wrote:
> >
> > > +1
> > >
> > > On 4/4/13 10:35 AM, "Michal Mocny" <mm...@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 <lo...@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 <ma...@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
> > > >><ag...@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" <ma...@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.
> > > >> > > >> >>>>>>>>>
> > > >> > > >> >>>>>>>>
> > > >> > > >> >>>>>>>>
> > > >> > > >> >>>>>>>
> > > >> > > >> >>>>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>>
> > > >> > > >> >>>
> > > >> > > >> >>>
> > > >> > > >> >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> > >
> >
>