[Mono-dev] [mono/moon] [2 commits] fd3b2520: Add a checkout-mono target that parses the README and checks out the cor

Rolf Bjarne Kvinge rolflists at ya.com
Thu Oct 7 04:32:46 EDT 2010


>Firstly, the 'reset --hard' is an absolute no-no for a checkout.
>Please use 'git checkout'.  'reset' modifies the branch metadata --
>checkout only modifies the working tree.  'reset --hard' is a
>too-convenient bludgeon that smashes your branch metadata and working
>tree with one misleadingly simple command -- use with care.

It's just a convenience target which does what the README says you should do
(which may be wrong/bad of course).

'git checkout sha1' will end up with a detached HEAD, if you make edits,
commits then, and 'git checkout another-sha1' you lose those commits. Which
is the same thing that happens with 'git reset --hard'. The only difference
is if you haven't committed your changes, in which case I think 'git
checkout' will bark on you, while 'git reset --hard' will throw them away
(but it will keep you on your local branch). Note that the README also says
that you should create a local branch in mono for moonlight, and this
makefile target (admittedly somewhat badly named) assumes you're already on
that branch.

>Secondly, I don't think you should be using the README file as a bad
>substitute for a tag.  Just create a tag, say "for-moon", in the mono
>tree, and update the tag whenever necessary.  With this, the rule above,
>and the the instructions in the README can be simplified to:
>  cd mono/ && git checkout for-moon

The problem with this solution is that you won't know which mono revision
corresponds to an older moon revision. So if an old moon revision won't
build with a newer mono revision, you're in for a lot of pain if you want to
bisect for instance. Another issue arises when moon branches, you would have
to create a mono tag for each moon branch or you'd have the same problem.

>(Eventually, when git's submodule support becomes usable, you could go
>in for that.)

Yes, I've been thinking about git submodules too. However I haven't found
that the benefits makes the pain of changing how things work for everybody
worth it.


More information about the Mono-devel-list mailing list