On 28/01/11 00:16, Phil Pennock wrote:
> On 2011-01-27 at 17:17 +0000, Tony Finch wrote:
>> On Wed, 26 Jan 2011, Phil Pennock wrote:
>> >
>> > A patch which also works with lookups enabled on the make command-line
>> > is available for review at:
>> >
>> > http://git.exim.org/users/pdp/review.git/commit/44e47ad200b45cf7ff4d136ddc1a0e64e26eb1a0
>>
>> I've done a test build on Solaris which worked OK. Also squashed the PATH
>> to avoid the large african migratory herding mammals in my home directory...
>>
>> :; env - PATH=/usr/bin:/usr/ccs/bin:/opt/SUNWspro/bin make
>
> Thanks.
>
> Committed to master repo as:
> http://git.exim.org/exim.git/commit/0cc9542ab26b35cba3a5523acb8991eb18ce0656
>
> Git etiquette issue: I try to avoid spurious "merge"s in the master repo
> history (not always successfully). So I end up using a git client to
> pull from head, fetch the changes, then cherry-pick them, so they get a
> new SHA1 identity.
>
> Is this acceptable, having different identities for patches being
> tracked for inclusion vs in the master repo, or should I learn to suck
> it up and have merge commits in the master?
Different commit IDs is unavoidable if there's more than one person
picking commits from their own branch, so cherry picking commits is ok
if you want to do it.
If you're merging multiple commits it could be useful to know that they
all came from the same branch, even if it generates a merge commit. The
history of when that other branch forked would also be available,
whereas hand picking them onto HEAD will lose that information.
I can see why you wouldn't want to have merge commits for every single
change... but it's not a problem. If you run gitk you'll see the history
isn't too complicated.
--
Simon Arlott
