Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Sender: Brett Porter <brett@porterclan.net>
Subject: Re: [1/2] git commit: f92a685 -
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=iso-8859-1
From: Brett Porter <brett@apache.org>
In-Reply-To: <31A3B1BB-1C82-41E6-B66D-0B01F58FD846@apache.org>
Date: Wed, 6 Jun 2012 12:14:40 +1000
Cc: Greg Stein <gstein@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CFBEB5F3-2A8C-4E59-864E-BD56B4725F22@apache.org>
References: <20120605175350.20B8DFFC3@tyr.zones.apache.org>
 <CABD8fLWJtumTw+0qvFOpenYg_xHaSTQuHUwDdEDphqrxQ3bF3g@mail.gmail.com>
 <1338922313.17426.YahooMailNeo@web160904.mail.bf1.yahoo.com>
 <31A3B1BB-1C82-41E6-B66D-0B01F58FD846@apache.org>
To: infrastructure-dev@apache.org

I went ahead and added this here: =
https://git-wip-us.apache.org/docs/committer-practices.html

I'm not sure if everyone agrees with this practice, so I'm happy to =
revise/remove it - but thought it might be a good place to start with =
documenting typical practices used by committers here.

- Brett

On 06/06/2012, at 10:08 AM, Brett Porter wrote:

>=20
> On 06/06/2012, at 4:51 AM, Joe Schaefer wrote:
>=20
>> Merge commits do peculiar things- part of what happened
>> is that I committed my change locally first, then pulled
>> to sync up with the central repo, then pushed back.  Somehow
>> history gets reordered and that is supposed to be reflected
>> in these merge commit notices.
>=20
> Nothing peculiar here, though it can be a bit hard to grok from the =
mails at first look. I actually prefer these notifications to github's =
approach of showing you the diffs of the merge commits all over again, =
though.=20
>=20
> The common ancestor of the changes was 33cc902, the rev Joe had as =
HEAD when he made his changes. What is shown here are the files changed =
by 4 commits on origin that were merged in to Joe's copy when he pulled =
the changes. History wasn't reordered, it just runs in parallel to each =
other :)
>=20
> Joe, you probably want this if you use git pull:
>=20
>  git config branch.master.rebase true
>=20
> That makes it the equivalent of "git fetch origin; git rebase =
origin/master" instead of fetch and merge, so your changes will be =
rewritten against the latest commit and the merge commit omitted.
>=20
> To ensure that is set up on any new repositories cloned:
>=20
>  git config --global branch.autosetuprebase always
>=20
> Cheers,
> Brett
>=20
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>=20
>=20
>=20
>=20
>=20

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter