As a humble e tester many thanks for the info. Tarball ->cvs ->svn -> git.
still enjoying the ride and the result!

Cheers

M


On 11 February 2013 17:07, Daniel Willmann <d.willm...@samsung.com> wrote:

> 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
>



-- 
Mark Dickie

Tel (+34) 654 583 648
Google Voice (+1) 253 470-6603
Email blaeberr...@gmail.com
Skype blaeberries
------------------------------------------------------------------------------
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

Reply via email to