GitHub workflow

[Etienne Samson]

Hi fellow QS developers and dedicated readers of this group !

I've been doing a bunch of major surgeries on some little parts of QS lately, and I'm now itching for something more *major*. And so, there are a few points I want to discuss first with the development-steering committee ;-). I originally wrote a *big* email, but I'm going to split it in a bunch of thread so it's easy to participate in some topics and not others. So here's the first part ;-).

I think we discussed that before, but I think it's worth repeating : I'd prefer if everyone with commit access pushed its PR branches to the main quicksilver repository (that makes it much easier for other devs to participate, e.g. when you have a bunch of those lying around since 1 year and they don't merge cleanly). I'm proposing this "workflow" (obviously, this only applies to those with commit rights to the main repo) :

# create your branch
git checkout -b my-branch
# do your my-branch thing, pushing to your own repo if you need some quick "tell me about …" from the other devs, or just to be on the safe side, but NO PULL REQUEST
# when you're ready for the PR
git branch -m my-branch my-prefix/my-branch
git push -u quicksilver
# the first "namespaces" your branch.
# the second push it to the "quicksilver" remote, which should point to the master repo (I imagine everyone has a different name for it, but its usually known as "origin", except if you cloned your own repo the first time around).
# The -u flag sets up the config file so that `git push` subsequently Do The Right Thing™. I've learned of that one just a few weeks ago, and it's a timesaver ;-).

What do you guys think ?

Regards,
Etienne Samson
--
samson....@gmail.com

[Patrick Robertson]

Sorry, I meant to reply on this sooner.

I like the use of namespaces, cool. :)
Yeah I've started using just 'get push' for my automagical deploying of my web app to AWS EC2. I'm getting fancy ;-)
I'm assuming "-u" equivalent to "get push --set-upstream origin master" (which you see if you type "git push" *without* previously setting a default upstream - it gives a useful log)

I agree on this… I think we've all been doing it more lately, especially for 'collaboration' branches, but it would be good for stuff like merge conflicts etc. It also has the added benefit (for me) that others can delete the branch once it's merged… something I'm hopeless at doing (eh Rob? :D)
The only downside is the potential extra bumpf that people have to download when cloning the repo. We should also probably make it clear in a readme that "master" is the main branch. Other branches are "feature" branches (except "release", which is for releases when we're doing one)

Feel free to add it to the wiki :)

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "Blacktree: Alchemy Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blacktree-alchem...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Patrick Robertson]

On the topic of Git workflow, this is a good read: https://github.com/blog/1640-git-internals-pdf-open-sourced

An interesting command I didn't know about is "git add -i" (interactive)

I'm sure you know about "git rebase -i" (Page 83), which is cool. But interactive add lets you do funky things (from page 62):

> You can also do more complicated things, like going through all of your change patches hunk by hunk, deciding if each hunk should be applied to the next commit or not. This means that if you’ve made a bunch of changes to one file, you can commit part of those changes in one commit, and the rest in a second. Try the patch menu option in the Interactive Adding menu to try this out.

If you don't have time to read the whole thing, other cool things at a glance:

* All about git (chapter 2)

* git log --pretty (page 64)

* git log --since (page 65)

* gitk (and gitk --all) (page 68). Viewing Etienne's latest hectic branching/merging no master is cool ;-)

* git instaweb (page 69) - OS X apache/httpd is funny, so I suggest either "brew install lighted" or using the built in web server (git instaweb --httpd=webrick). See https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/git-instaweb.1.html on making the config file

* git grep (page 71)

* git diff to generate patch files (git diff master..experiment > experiment.patch, Page 75)

…and finally, the most important bit: Keeping tidy ;-) (Page 92 onwards)