On Tue, 12 Feb 2013 13:46:47 +0900 Daniel Juyung Seo <seojuyu...@gmail.com> said:
> Great! Thanks a lot for your effort. > Btw, non-committers can clone git in the same way? > How they clone git? obviously they can't clone the same way... ssh transport will not work for them. :) they probably can git clone as normal tho via git proto. > Daniel Juyung Seo (SeoZ) > > On Tue, Feb 12, 2013 at 1:12 AM, Daniel Willmann > <d.willm...@samsung.com>wrote: > > > Apologies for the double send, but someone forgot to set the subject > > correctly (at all)... > > > > 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 > > > ------------------------------------------------------------------------------ > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
