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