[PULL] fixes and clean ups for alpha

[Peter Hutterer]

On Tue, Oct 13, 2009 at 10:22:09PM -0700, Jeremy Huddleston wrote:
>
> On Oct 13, 2009, at 20:22, Keith Packard wrote:
>
>> Excerpts from Matt Turner's message of Tue Oct 13 18:48:10 -0700 2009:
>>
>>> Actually before I sent the pull request I did `git pull origin  
>>> master`
>>> to verify that there were no conflicts, and when there weren't I did 
>>> a
>>> `git reset --hard HEAD^`.
>>
>> Ok, cool.
>>
>>> Is this OK? I'm not quite sure that a better way to do it is.
>>
>> There are a couple of options, but I'm not sure whether either is
>> better. The first is to merge from origin/master, and the second is to
>> rebase atop origin/master. Any one have strong feelings as to which of
>> these three methods is 'best'?
>
> (IANAGE -- I Am Not A Git Expert)
>
> Well, as long as it's not actually pushed somewhere public, I think  
> rebasing onto origin/master will be more similar to the actual order in 
> which the changes would get applied when they're pulled into master.
>
> Of course this is all based on what I've been told and my shallow  
> understanding of git (man pages are easier to read with beer, btw...),  
> rebasing atop origin/master would be the wrong thing to do since this is 
> a published tree.  Rebasing would rewrite history... and while rewriting 
> history would certainly be a good thing for my bank account, it would be 
> a bad thing for git.
>
> On a slightly more confusing point now... what do we do when a patch  
> gets denied.  Say I have a patch that is in my published jeremyhu/master 
> and Keith decides that he doesn't like the way my code smells.  What do I 
> do now?  My branch is already published ... The only way I can have it 
> eventually merge back into master is by rewriting history... so does that 
> mean that we should rewrite history on our ~user/xserver trees, or is 
> there a better way to get around that?  Yes, I know about git-revert, but 
> then that would be more ugliness in the history.

A git revert has one advantage over a "make it disappear" rebase: it keeps
the history. If I bump into this commit way down the track I know a) what
you tried to solve and b) why you ended up doing it differently.
(That is assuming you added an explanation for the revert).

If you simply made the patch disappear then that information isn't
available down the track. So this clean history is a short-term benefit but
long term drawback.

Cheers,
  Peter