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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
