Re: [Social] Fwd: Saying hi :) and about git workflow

[will kahn-greene]

Scott Chacon did a set of git screencasts that are dense, but good:

http://www.gitcasts.com/

They're not in free formats, but they're free-as-in-beer-ly available.

There's also the Pro Git book:

http://progit.org/book/

The first few chapters of this book are very handy.

Also, Chris Webber did a talk at ChiPy in January that covers Git
internals and Git-Python.  The Git-Python stuff isn't relevant, but the
Git internals is useful.

http://python.mirocommunity.org/video/1227/gitpython-and-git-internals

/will


On 06/13/2010 07:42 PM, Matt Lee wrote:
> 
> -------- Original Message --------
> Subject: Saying hi :) and about git workflow
> Date: Sun, 13 Jun 2010 10:22:09 -0400
> From: Shashi <address@hidden>
> To: Ian <address@hidden>
> CC: Matt Lee <address@hidden>, Craig Andrews <address@hidden>
> 
> Hi Ian and others,
> 
> I'm Shashi, I hack on StatusNet as a GSoC student and an enthusiast. I
> am working on the base classes for Video, Photo & Event plugins for
> GNU-Social. My branch is at
> http://gitorious.org/+socialites/statusnet/gnu-social/commits/base_plugins
> there's quite a bit of code in there, (see SocialObject and
> SocialLayout plugins) The code is theoretical and has no practical use
> right now. What these plugins do is they abstract out a lot of
> functionality for Video, photo plugins etc. the social object plugin
> generates streams for public, user and group timelines (and even
> caches them). It is easy to add other timelines like tag, popular etc.
> but i decided to start small and the actual SocialObjects (i.e video,
> photos, events etc) don't have to do anything to be on these timelines
> :). SocialLayout plugin creates menus  etc and means to supply some
> common JavaScript and css. I'll need some time to fine tune it, and I
> will talk to @candrews about it and see what he thinks.
> 
> Meanwhile I noticed that we need to follow a proper git workflow to
> not get confused. :D mattl (cc'd) said that he has little experience
> with git. Branches are ultra light-weight (<100 bytes ;) srsly) in
> git, using them pays well. Branches are just labels we give to
> commits, so when someone clones a repository, they get all the commits
> and thus all the branches (I don't know anything about SVN, but it
> feels like a "cathedral"-like system to me :) But I'm really familiar
> with git and use it a lot even for stuff other than version control
> :P). So, I think this is a good workflow to follow:
> 
> 1. clone the main repo locally (which you already have)
> 
> 2. clone the main repo _on gitorious_, even if you have commit access.
> Doing this gives a more "social" feel to the project. this is true
> bazaar model. you too get more freedom for free. :) even Evan has his
> own clone of StatusNet --
> http://gitorious.org/~evan/statusnet/evans-mainline (Linus Torvalds
> has his own unofficial public clone of Linux ;)
> 
> 3. add your gitorious clone as a "remote" to your local clone (using
> the SSH uri that gitorious provided for your repo):
>    $ git remote add myclone address@hidden:~me/pathtomy-clone.git
>    $ git fetch myclone # this will fetch the names of the branches,
> since all commit objects are already there with you
> 
> 4. you can setup a local branch to track your own clone's master, and
> checkout to it with the following command
>    $ git checkout -b my_master myclone/master
> 
> 5. create a branch for each feature, starting at my_master
>    $ git checkout -b my_new_feature
> 
> 6. make reasonably small commits for each part of the code you are
> trying to implement, and commit them, even if the code at that commit
> is broken. this will aid in reviewing code and in pointing out exactly
> from where a bug comes from (git blame) and also helps in reverting a
> bad commit easily.
> 
> 7. commit more. after every 5-10 commits push it to *your* gitorious
> repository
>   $ git push myclone HEAD
>   -- this will create a new branch called "my_new_feature" in your
> gitorious clone.
> 
> 8. keep pushing keep pushing. when you're feeling good about the
> feature, test it. test it again.
> 
> 9. now, if you wish the code to be reviewed by other committers you
> can create a merge request for the main repo on gitorious. Yes, core
> developers do this
> http://gitorious.org/statusnet/mainline/merge_requests/1569
> 
> 10. or if you feel review is not necessary, just push it to the main
> repo's master.
>      $ git push origin HEAD:master # woohoo!
> 
> Also, I think it is a bad idea to use main repo's master branch to
> dump everything. we should create different branches for different
> features and different versions on the main repo and push there
> instead. eg. if 0.1-dev is the development branch
>     $ git push origin my_new_feature:0.1-dev
> when 0.1-dev is ready for release, we merge it with master. then, we
> start 0.2-dev :) and push security updates and bug fixes to 1.0-dev
> and master after testing them, when 0.2-dev is ready we merge with
> master after 6 months or so of supporting 0.1-dev we delete it. and
> the cycle continues.
> 
> This way we wont be supporting some-random-commit, instead we'll be
> supporting one single branch, master. So it makes perfect sense to
> commit unfinished work as often as you feel like to your own clone or
> the dev branch.
> 
> I don't think statusnet's master branch is what we should be hacking
> on, the 1.0.x branch (although unstable), is a *lot* ahead in terms of
> development than master, that's where new features like privacy are
> going.
> It is also very wise not to make changes to the core statusnet
> code/documentation this will break continuity and cause merge
> conflicts. Instead, do this:
> 
>   $ git remote add statusnet git://gitorious.org/statusnet/mainline.git
>   $ git fetch statusnet
>   $ git checkout -b statusnet_master statusnet/master
>   <make changes here>
>   $ git push myclone HEAD
> 
> Now go to gitorious, and create a merge request asking statusnet to
> merge from "myclone". If it gets accepted, pull from there when you're
> merging. If you come up with hacks that don't get accepted, and
> *really* need them, keep them in a branch, say upstream_hacks on our
> repo.
> 
> I can set these things up and maintain the coordination etc for you if
> you want me to.
> 
> This is largely how StatusNet functions, and It feels good to
> contribute to it :)
> 
> Please suggest any changes to this and we will make a wiki page for
> everyone to look at and follow.
> 
> PS: Yours were the only email addresses I could amass, please forward
> this to whoever is involved in the development correctly :)
> 
> Thanks a billion
> --
> Shashi
> 
>