Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen.
For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name "Jane Doe" $ git config --global user.email "jane...@example.com" Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/<reponame> -> (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase -> (svn update) To commit all local changes $ git commit -a $ git push -> (svn ci) OR (better) if you just want to commit specific files $ git add <files> $ git commit $ git push -> (svn ci <files>) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories ----------------------------- Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot "uncommit" something - only revert. * "master" is what trunk used to be. All official development happens there. * For a stabilization branch we will have "<packagename>-<version>" branching off of master. This is analog to the way SVN branches were used in the past. An example would be "elementary-1.7" * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme v<version>, so for example "v1.7.5". Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/<name>/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. Local branches: * Go nuts. Branches are cheap and merging/rebasing them is easy as well. It's a good way to try out some small things while keeping other development separate. Commits best practices: I will probably be laughed at (at best) or thrown out of the project for bringing this up, but here goes. Because of the way git integrates with email it is encouraged to write a commit message with a one-line summary, a blank line and then a body describing the commit in greater detail. Most of you will ask "More than one line? Why would I need more than one line to write 'Fix, fix, spankies!'". You have a point, but I would actually want to push for commit messages that are a little longer than that. I know some will refuse to adopt that, but I would still like to see everyone else setting a good example. If you want a good example of how to write and structure your commits and messages I recommend taking a look at QT. I would be really happy (almost ecstatic with joy) if we could have more commit messages that include the problem and what was done. Example: """ Fix memory leak in function xyz If the allocation of foo fails the error path doesn't clean up correctly which leads to variable bla being leaked. Clean up correctly and exit. """ Similarly, the individual commits shouldn't be too large. I don't want you to commit every line change separately, but git allows you to commit a bunch of stuff locally before pushing it upstream. What was one large commit in SVN can be broken up into several smaller ones in Git. This makes commits much easier to review (as does a proper commit message, hint, hint). If you do have a larger feature that requires tens of commits please don't just dump them into upstream Git at once, but develop them publicly in a topic branch (see topic branches) and merge them when they are ready. That's it for now, specific news will follow shortly. Regards, The SVN->Git migration team ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
