git practices

[Jeremy Huddleston]

On Oct 13, 2009, at 19:11, Peter Hutterer wrote:

> Note that while I'm writing this email there's a discussion on IRC  
> about
> this 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  
>> pull
>> is essentially a fetch/merge.
>
> You do get them, yes. How much of a problem they're going to be in the
> futurue I don't know. They can be nasty when bisecting and confusing  
> in the
> history.

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/master
>>
>> reorder, 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 our
>> common ancestor into one commit, so we don't actually have origin/ 
>> master
>> in 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  
> known
> refs in the history. e.g. in the current origin/master tree I can see
> daniels/master, alanc/master and mattst88/master (and of course my  
> own one).

Ah... interesting.  git is certainly clever if not confusing...

Thanks again,
Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3333 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091013/0fe5704b/attachment.bin