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

[Matt Lee]

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

signature.asc
Description: OpenPGP digital signature