Learn how to use git.

[Ciemon Dunville]

Whilst smashing my way around the various space servers I've been
pointed at the fact that git is being used for version control of a
lot of things on the servers, and it's the preferred way of doing
things[0].

There are various resources for teaching yourself about git, and also
help via irc, but there's an opportunity here for the space to make a
little money. I've put a workshop request on the wiki[1] so that
someone with the knowledge can give us mere mortals a steer in the
right direction, and then we can work on the specific requirements of
the space. Once that's all done it can be documented on the wiki which
should help to remove the need for people like me stomping around in
the space servers :)

Ciemon
[0] https://github.com/londonhackspace
[1] http://wiki.hackspace.org.uk/wiki/Workshops#Workshop_Requested

[Chris Mear]

I'd be interested in teaching Git to people (will add my name to the wiki when I get back to my computer). Have been doing it informally one-on-one for a while now.

Would be good to know what level of experience participants already have (i.e. will we need to explain the concept of version control from scratch, or has everyone already used Subversion?).

Chris

[Sam Cook]

I've been using git for a while but a being taught it would be excellent as I'm sure there are things I do wrong

[phil jones]

If someone could help me understand what "rebasing" really means, that
would be awesome.

[Toby Catlin]

It's like freebasing but less fun

[Chris Mear]

I've put up a quick draft of topics we could cover on a new wiki page:

http://wiki.hackspace.org.uk/wiki/Workshops/Git_Workshop

This is from a perspective of 'teach Git from first principles', assuming no prior knowledge. I'm not certain if that's what most people will want, or whether we ought to split it more evenly between structured learning and random tidbits/tricks. However, I've definitely found that Git is one of those things where it really helps to understand the principles of what's going on, as it'll help you deal with problems when you do more sophisticated stuff with it.

If anyone has suggestions for topics they'd like covered, or alternative approaches for the workshop, go ahead and add them!

Cheers,
Chris

[tomtt]

> If someone could help me understand what "rebasing" really means, that would be awesome.

Rebasing: git lets you easily mess around with branches. A branch is
just a set of commits with a branch name pointer to the last one. Now
if work done by another developer and your work share a common commit,
at some point you'll need to bring the two together.

One way is merging which creates an additional merge commit in which
all the changes are incorporated with any conflicts resolved. Note
that if you do this, the branching and merging will still be visible
in the history of the repository.

Another thing you can do is rebasing. My mental model for this is like
a replay of commits: one by one your changes are applied, but instead
of applying them to the original commit that you started from, it
starts from the last commit of the other branch. At the end of that it
is like there never was any branching and all the commits you made
were done *after* the other dev's work.

So one difference between merging and rebasing is that merging gives
you a better overview of how code was produced, whereas rebasing
results in a 'cleaner' history.

Because the parent of a commit determines its SHA1, if you rebase you
also change all to SHA1s of your commits. This is why you should not
rebase any commits that were already pushed to a shared repository.

Why rebase? Sometimes I just like the cleaner history of my work. But
also: it can be a very powerful tool to make a bunch of messy commits
look like you knew what you were doing all along. The git rebase --
interactive command allows you to rearrange, join up or edit commits
to your heart's content.

Tom

-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
 Tom ten Thij
 Unboxed Consulting, http://unboxedconsulting.com
 T: +44 20 3137 2943 F: +44 20 7183 4251
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

[Ciemon Dunville]

Well, that's a bit of a result.

Thanks Chris for offering to run a workshop, and getting the
beginnings of a plan together[0]. I see that there are seven people
interested so far which is great for the few days we've been talking
about it.

Of course, things to think about now should include when you might run
it, over how many days, and of course the cost.

Ciemon
[0] http://wiki.hackspace.org.uk/wiki/Workshops/Git_Workshop
[1] http://wiki.hackspace.org.uk/wiki/Workshops#Workshops_offered
-bottom of the table.

[Jonty Wareing]

On Sat, Feb 19, 2011 at 08:16:43AM +0000, Ciemon Dunville wrote:
> Of course, things to think about now should include when you might run
> it, over how many days, and of course the cost.

We have run git workshops before, a fairly thorough course takes no
longer than a couple of hours in an evening. Honestly, you can learn
most of the basics in under half an hour.

It's also not the kind of thing that we charge for (donations cover it),
but that is up to the person organising the session.

--jonty

[phil jones]

Thanks Tom,

that *is* one of the clearest explanations I've heard so far. I'm
still not sure I see the attraction of rebasing. But maybe that's
because I still *assume* a "merge" model which, however messy, is what
I'm intuitively comfortable with. Still, I'd have to use rebasing a
bit to get a feel for it.

cheers

phil

[tomtt]

On Feb 19, 2:06 pm, phil jones <inters...@gmail.com> wrote:
> I'm still not sure I see the attraction of rebasing.

That is perfectly fine :). You can use git without ever using rebase,
but it is a tool that can be good to have in certain occasions. For
example often when I am working on something and then realize,
actually I also need to make this change, but it really belongs to the
commit *before* my last commit. I can then just commit it for now and
before I push do a git rebase --interactive and put together what
belongs together. But I can be a bit OCD regarding my commits
sometimes :).

So yeah, nothing wrong with just always merging.

Tom.

-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
 Tom ten Thij
 Unboxed Consulting,http://unboxedconsulting.com

[ynohtna]

Yes, that was a great explanation for me, too. Thanks.

I can also see it being quite useful when one has performed lots of experimental branches locally but doesn't want to muddy up the project history for other team members.

Heh, hands up who's had to graph out branch histories on whiteboards before to be confident that they're doing the right thing?

A.

[Chris Mear]

Yup, I was imagining a fairly informal (but organised) session with Hackspace members, no money changing hands. That lets me test out the format in a low-pressure setting, and also means we can look at things that are slightly Hackspace-specific (such as making a Git-on-Babbage cheatsheet that can be put on the wiki, etc.).

(People do pay for Git training, though, and I can certainly imagine a future, public session being run for donations. Let's see how this one goes first.)

My guess (as Jonty confirms) was that we'd be able to get through a guided tour through Git essentials and day-to-day usage in a couple of hours. Then we can have some time for more freestyle exploration of bigger or more advanced concepts (e.g. common workflows, rebasing). So I'm picturing a one-day thing at most.

I'll set up a Doodle poll shortly so we can figure out a date.

Cheers,
Chris

[Chris Mear]

On 19 Feb 2011, at 17:53, Chris Mear wrote:

> I'll set up a Doodle poll shortly so we can figure out a date.

So here is the poll, based on fitting it into a weekday evening or a weekend afternoon:

http://doodle.com/dr62yn99z4tyxdxm

I didn't quite realise this until I actually looked at my calendar, but my availability is a bit silly and random over the next few weeks. Hopefully one of those dates will work out.

Thanks,
Chris

[Chris Mear]

On 19 Feb 2011, at 21:49, Chris Mear wrote:

> So here is the poll, based on fitting it into a weekday evening or a weekend afternoon:
>
> http://doodle.com/dr62yn99z4tyxdxm
>
> I didn't quite realise this until I actually looked at my calendar, but my availability is a bit silly and random over the next few weeks. Hopefully one of those dates will work out.

Thanks to everyone who responded to the poll so swiftly. While the 'best' date appears to 16 Apr, that's almost two months away. There are dates sooner that are still pretty good, and I'd much rather strike while the iron's hot if possible.

So, I propose to run the workshop twice, on these evenings:

Wednesday 23 February
Friday 18 March

I believe everyone who's responded so far can make one of those dates. It also gives me extra opportunity to work out any kinks in my prepared material!

Details on the calendar and wiki shortly.

Cheers,
Chris

[samthetechie]

The Git tutorial / workshop was fantastic. Highly recommended. It is
good if you install Git and signup to github before attending.

[Billy]

Book me in for the one in March, please.