On Oct 13, 2009, at 19:11, Peter Hutterer wrote:
Note that while I'm writing this email there's a discussion on IRC aboutthis anyway, so I don't know what the final verdict will be on that.
Well, I'll need to read through my IRC logs when I get into the office tomorrow then.
yes, but no. git isn't linear on a single line, you're missing the
merge
here. so origin/master is more like
A B C D E F G H-M
\1 2 3 4/
Ok... so I think my mental model is restructuring itself, thanks.
I thought this was the huge "badness" which shows a bunch of "branch____ merged with branch ____" messages that get super messy because pullis essentially a fetch/merge.You do get them, yes. How much of a problem they're going to be in thefuturue I don't know. They can be nasty when bisecting and confusing in thehistory.
Yeah, bisecting and clean history is mainly what I'm concerned about. Check out how xorg-server-1.6-apple paralleled server-1.6-branch:
git log --graph --pretty=oneline 7c16b68ab879f5b4b1aedfc6b2aadbe56193dd19...origin/xorg-server-1.6-apple
(7c16b68ab879f5b4b1aedfc6b2aadbe56193dd19 was the server-1.6 branch from master ... I'm sure there's some clever way to say that in git syntas, but meh... I'm just no that cool.)
For this branch, I just committed cherry-picks and merged origin/ server-1.6-branch ... there are a lot of long parallel tracks which would make bisecting problematic. I'm not even sure how bisection in git works without a linear model. My guess is that it just bisects along the main branch and sees the merge commit as a single
$> git rebase -i origin/masterreorder, cleanup, etc all changes since origin/master ... but we aren't actually tied to origin/master any more... this is what confuses me...the "pull" resulted in merging all changes in origin/master since ourcommon ancestor into one commit, so we don't actually have origin/ masterin our history.I think this should be the merge commit instead of origin/master.
Yeah, that makes sense based on how I now understand things. origin/ master is not any more special than bond007/master in this scenario. Both are published and can't be altered. The merge commit just after each of those is essentially the union of the two and thus the most recent commit that needs to be unaltered.
Need to test this again and fix the documentation. Note that due to the merge commit, both bond007/master and origin/master are in the history.Have a look at the master branch with tig, by default it shows all knownrefs in the history. e.g. in the current origin/master tree I can seedaniels/master, alanc/master and mattst88/master (and of course my own one).
Ah... interesting. git is certainly clever if not confusing... Thanks again, Jeremy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
