Version mismatch when building trunk
    Thiago Macieira 
    thiago at kde.org
       
    Mon Oct 19 19:04:24 BST 2009
    
    
  
Em Segunda-feira 19. Outubro 2009, às 19.14.22, Michael Jansen escreveu:
> > [Except that --strategy=theirs does not exist; it has to be something
> > like 
> >     $ git merge --strategy=ours --no-commit 4.7-patched
> >     $ rm .git/index
> >     $ git read-tree 4.7-patched
> >     $ git commit
> >     $ git status
> >     $ git reset --hard && git clean -fd
> > 
> > but only for the maintainer of the branch, of course.]
> > 
> >
> > > who's going to maintain such a branch, though?
> 
> Do you know why i'm pretty confident i never ever have to work with git in
>  my  daytime job? Every time someone suggests that, i just present these
>  lines with the question: "Please explain to everyone in this room what
>  happened there"
> 
> :)) . And i won't except a line like here a wonder happens -> *desired 
> 
> result* .
You don't have to know what those commands do to use Git. You have to 
understand only the part between the brackets above: merge strategy "theirs" 
doesn't exist. It would be the opposite of strategy "ours" if it did.
What Johannes suggested involved knowing Git internals (the .git/index file and 
the plumbing command read-tree). You don't have to know that in order to use 
Git.
Instead, you just have to understand what "theirs" would mean. Since it's the 
opposite of "ours", all you need to do is invert the merge order.
Instead of:
	git checkout branch
	git merge -s theirs otherbranch
You should do:
	git checkout -b tmp otherbranch
	git merge -s ours branch
	git checkout branch
	git merge tmp
	git branch -d tmp
This is using only checkout, merge and branch, so you should be able to 
understand it. Johannes's commands are doing technically the same thing, but 
are more efficient (they avoid an extra branch switch, which could mean checking 
out thousands of files and trashing your disk cache).
> Do you know why i'm scared? Because what you suggested seems to make sense
>  and  thiago understood it. And i thought i finally would make sense of
>  git. 
I hadn't even tried to understand the commands until you suggested that I had. 
They looked unnecessarily complex for what I wanted to do. But now that the 
game is on, I could do it even more efficiently, by running:
	sha1=`echo "Updating kde-qt" | \
		git commit-tree otherbranch^{tree} -p otherbranch -p branch`
	git update-ref refs/heads/branch $sha1
Or, also using the amazing git-fast-import:
	git fast-import --date-format=now <<EOF
commit refs/heads/branch
committer Thiago Macieira <thiago at kde.org>
from refs/heads/otherbranch^0
merge refs/heads/branch^0
EOF
But this is just being showoff. Point being: all of Git's internals are 
exposed, if you want to do things very efficiently for your own scripts. But you 
don't have to know the internals to use Git.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14     San Francisco, California: Nov 2 - 4
      http://qt.nokia.com/qtdevdays2009
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091019/363c71d1/attachment.sig>
    
    
More information about the kde-core-devel
mailing list