and the wiki.
I was just about to find the pages in need of updated, but it seems
the wiki is down :(
--Hardy
On Thu, 07 Oct 2010 11:30:11 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
Hibernate Core now uses Git as the version control system.
You can access it at
http://github.com/hibernate/hibernate-core
Core on Git
We have imported the SVN history (at least what GIT could extract) and
pushed the SVN trunk, branch 3.5 and branch 3.3. If you need more of the
legacy branches or tags, let me know, that can be arranged.
If you want to contribute a fix or new feature, either use the pure Git
approach, or use the GitHub fork capability (see
http://help.github.com/forking/ and
http://help.github.com/pull-requests/ ) The benefit of the GitHub
approach is that we can comment on the pull request and code though I am
far from an expert so far and their flow could easily be improved
(slightly confusing).
If you still want to do it the old way a provide a patch file, that's ok
too.
Tips on Git
Here are some tips on Git:
o read Pro Git
http://progit.org/book/ awesome book and very practical.
It has a free html and epub version (buying the tree version is
recommended to repay the author).
o prefer the git protocol when cloning over http (so say the experts).
At the very least that will be much faster. cloning the repo from GitHub
took me less than 3 minutes
#for people with read/write access
git clone git@github.com:hibernate/hibernate-core.git
#for people with read-only access
git clone
git://github.com/hibernate/hibernate-core.git
It will create a "remote" link named origin. I usually tend to rename it
to reflect what it is really.
git remote rename origin core-on-github
o always work on a topic branch and merge your work when you are done
git checkout master
git checkout -b HHH-XXX
hack commit hack commit
Likewise if you want to share a work with somebody from the Hibernate
team, push or define the pull request of your topic branch (though make
sure your topic branch is above master).
o prefer small commits, they will be more readable and will very
unlikely fail on merge
o write good comments (short one line including the issue at stack
followed by a blank line and a more detailed explanation if needed)
`HHH-XXX Fix NPE on persist
Fix stupid bug by Gavin that lead to a NPE when persisting objects with
components`
o prefer rebase over merge
Rebase put changes from the branch you forked below the new commits you
have done and thus keep the history linear.
got checkout HHH-XXX
git rebase master
DO NOT rebase a branch that you have shared publicly (unless you know
people won't use it or you wish them harm).
o while you are at rebasing, you can rewrite your commit history to
clean comments or merge some commits together (named squashing)
git rebase -i HEAD~6 (go back 6 commits in time)
o once you're fed up with typing longish command lines, use aliases (see
below)
o I've put a copy of my ~/.gitconfig file in case people want to copy
some things including aliases (see below)
o if you use Mac OS X, GitX is a fantastic tool, in particular to do
interactive staging and commit only some parts of a file
o you can read this blog entry that was some more info
http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-sinc...
o feel free to add your tips to this email thread, I'll likely compile
them in a blog entry.
~/.gitconfig
[user]
name = Redacted
email = redacted(a)redacted.com
signingkey = id_key.pub
[core]
editor = open -nW -a Smultron
[merge]
tool = opendiff
[color]
ui = auto
[color "branch"]
current = yellow reverse
local = yellow
remote = green
[color "diff"]
meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
[color "status"]
added = yellow
changed = green
untracked = cyan
[github]
user = redacted
token = redacted
[alias]
co = checkout
undo = reset --hard
cb = checkout -b
br = branch
cp = cherry-pick
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev