Activity Team/Git Activity Maintainer Walkthrough

<bernie> godiard: then, regarding your second question, you'll need some git-fu. let me know when you're ready

<bernie> godiard: I'll guide you through the process

<godiard> bernie: ok

<godiard> bernie: from comandline or from git.slo ?

<bernie> godiard: cmdline

<bernie> godiard: first of all, clone the mainline repo. perhaps you've done this already

<bernie> godiard: if you did use the git:// url for the initial checkout, you may have to update your configuration to use the ssh url

<bernie> godiard: otherwise, you won't be able to push

• timClicks (~tim@219-89-80-120.adsl.xtra.co.nz) has joined #sugar

<godiard> bernie: sorry, where is the ssh url?

<bernie> godiard: you can see it in the repo page

<godiard> bernie: i do git clone git://git.sugarlabs.org/paint/mainline.git

<bernie> godiard: it's the third one

<bernie> godiard: ok, if you did "git clone git://...", you can't push. the git:// protocol is unauthenticated and hence read-only

<godiard> git push gitorious@git.sugarlabs.org:paint/mainline.git ?

<bernie> godiard: the url can be fixed afterwards by editing .git/config or, if you prefer to go by the rules, with the "git remote" command

<bernie> godiard: oh, this is another way to achieve it

<bernie> godiard: it's more inconvenient, though... you'd have to type the url every time you want to push.

<godiard> bernie: trying

<godiard> bernie: but i need to do the clone before the git remote

<godiard> ?

<bernie> godiard: oh, I thought you had done a clone already... I was trying to save you time by changing the url in the existing repo

<godiard> bernie:ok

<bernie> godiard: to answer your question: yes, git remote works from within an existing repo (which may be also a totally empty repo created with "git init")

<godiard> bernie: ok

<bernie> godiard: ok, once you have a repo checked out and the url is the ssh one, we may proceed.

> Quozl:< git is so hard for newbies...

<godiard> bernie: i started again in another directory

<godiard> bernie : i cloned mainline with git clone git://git.sugarlabs.org/paint/mainline.git

<godiard> bernie: in the page i don't found any ssh url

• kushal has quit (Ping timeout: 240 seconds)

<bernie> godiard: odd... do you see your name on the right?

<bernie> godiard: are you logged in?

<godiard> bernie:yes

<bernie> godiard: you only see "Public clone url" and "HTTP clone url" ?

<bernie> godiard: are you looking here? http://git.sugarlabs.org/projects/paint/repos/mainline

<godiard> bernie: yes and push url

<bernie> godiard: aha! that's the ssh url

<godiard> ouch

<bernie> godiard: (sorry, I don't see what you see because I don't have commit access to paint)

<godiard> but when i do "git remote add origin gitorious@git.sugarlabs.org:paint/mainline.git"

<bernie> godiard: so, since you checked out the git:// again, you'll have to edit .git/config and replace the url with this one

<godiard> i have "fatal: Not a git repository (or any of the parent directories): .git"

<bernie> godiard: odd

<godiard> bernie: i must do git init before git remote?

<bernie> godiard: are you into the checkout dir?

<bbellmyers> hey, re: standard cursors

<bernie> godiard: if you did git clone .../mainline.git, your repo is probably in a dir called "mainline"

<godiard> ok

<godiard> cd mainline

<bernie> godiard: i have a feeling that "git remote add ..." will fail again because you already have an origin configured now

<bernie> godiard: for this case, new versions of git offer a command: "git remote set-url origin gitorious@git.sugarlabs.org:paint/mainline.git"

<godiard> try git remote in mainline?

<Quozl> bernie: don't forget the opportunity to have godiard show you his .git/config

• pfroehlich_afk is now known as pfroehlich

<bernie> godiard: git remote is kind of hard to use... this is why I was suggesting editing .git/config instead :-)

<godiard> ok

<Quozl> "git remote" is another interface to the file .git/config

<bernie> godiard: all the command does is change that file

<godiard> ok, i am editing the file

<godiard> i see a url parameter

<bernie> git has plenty of UI sugar commands nowadays. the intent was to make it easier to use, but in my mind they made it more obfuscated.

<godiard> bernie:i must change "git" by "gitorious" ?

<bernie> like the "friendly" error messages with a dozen lines of justification for not doing what you wanted to do :-)

<bernie> godiard: you've got to change the entire url to gitorious@git.sugarlabs.org:paint/mainline.git

<godiard> bernie: ok

<bernie> godiard: note, it's easy to miss that this url has a ":" where the old one had "/".

<bernie> godiard: a few days ago someone wasted a day because of this :-)

<godiard> :)

<Quozl> godiard: here is my .git/config where i commit to a non-mainline paint repo.

[core]
       repositoryformatversion = 0
       filemode = true
       bare = false
       logallrefupdates = true
[remote "origin"]
       fetch = +refs/heads/*:refs/remotes/origin/*
       url = git://git.sugarlabs.org/paint/mainline.git
[remote "quozl"]
       fetch = +refs/heads/*:refs/remotes/origin/*
       url = gitorious@git.sugarlabs.org:paint/quozl.git
[branch "master"]
       remote = origin
       merge = refs/heads/master
[push]
       default = matching

<godiard> can i acomment with # ?

<bernie> godiard: yep

<Quozl> godiard: just so you see how other paint users use it.

<Quozl> godiard: in my case i fetch from mainline and push to quozl.git

<walterbender> bernie: why are we suddenly having this / vs : problem?

<bernie> godiard: now you should be able to do "git pull"... it will tell you that there's nothing new in the remote

<godiard> quozl: thanks

<bernie> walterbender: one is a real url (git://host/path)

<bernie> walterbender: the other is an ssh address in the form user@host:path

<Quozl> bernie: isn't there a URL form of the SSH address?

<godiard> bernie: git pull ok!

<bernie> walterbender: for symmetry, git also supports an ssh://user@host/url syntax similar to svn... but it's rarely used

<bernie> Quozl: yep ^

<bernie> godiard: ok, now I'll let you see around your repo so you gain confidence

<bernie> godiard: first of all, I recommend looking at the history: git log

<godiard> bernie: ok, i see the same

<bernie> godiard: for each commit, it will tell you who did it, when and hopefully also why

<bernie> godiard: to see even the patches, try "git log -p"

<Quozl> godiard: by the way, you can also test the effects of what you are about to do to mainline on git.sugarlabs.org ... by cloning that repository to your system, e.g. /tmp, and then pushing your changes to it and examining the effect.

<bernie> godiard: oh yeah, this is a good way to experiment without breaking anything in the server

<Quozl> (e.g. pushing changes from your local clone that you want to keep, to a local clone that you have only for testing a push).

<bernie> godiard: an important concept to grasp in git is that your repo is only yours and you can mess it as much as you like. all your commits will remain local.

<bernie> godiard: until you do a "git push", or course.

<godiard> bernie: ok

<godiard> bernie : i can do a rollback?

<bernie> godiard: every time you do a clone, it's an entire copy of the other repo and you can use it as the url for another clone and so on

<bernie> godiard: yes, git has very powerful commands for undoing changes in many ways

<bernie> godiard: "git reset", "git commit --amend"... it's almost unconfined because... the repo has only one user: you.

<godiard> bernie:ok

<bernie> godiard: ok, now look at what branches you have: git branch -a

<bernie> godiard: you'll see a * next to the current one

<bernie> godiard: it will probably be "master"

<Quozl> godiard: instead of rollback (as a concept), you can just checkout the hash before your commit, make your changes again, and commit again.

<godiard> ok

<Quozl> git repo is a series of alternate realities.

<Quozl> sometimes those alternate realities merge back together, but they don't have to unless you want them to.

<bernie> godiard: now it's time for some rock & roll. add another remote: git remote add quozl git://git.sugarlabs.org/paint/quozl.git

<godiard> ok

<bernie> godiard: now you can fetch the stuff that quozl did in his repo

<bernie> godiard: are you planning to merge everything?

<godiard> quozl: i think so, any problem?

<Quozl> i suggest you consider rewriting some of the commit messages before you push.

<Quozl> some of the commit messages are unduly brief and don't include what we learned in mail threads.

<bernie> Quozl: good idea... we'll use it as an excuse to show godiard how to do these advanced things too

<bernie> godiard: ok, now the easiest and most non-destructive thing you could do is "fetch" from quozl repo

<bernie> godiard: like so: git fetch quozl

<Quozl> i'll do what godiard is doing too, so that i can learn.

<bernie> godiard: "fetch" is a bit like clone, but you use it in an existing repo and it downloads only the objects that you don't already have.

<godiard> bernie: ok, now i have the quozl remotes when i do "git branch -a"

<Quozl> works for me.

<bernie> godiard: hehe, you anticipated me this time!

<bernie> godiard: ok, now you could look at what quozl has done in his repository: git log quozl/master

<bernie> godiard: I'm assuming that quozl also had a branch called "master", like you do

<bernie> godiard: because "master" is the name for the main branch in git, many repositories have it. but it's not obligatory

<godiard> bernie: yes, i see my changes

<Quozl> godiard: here ... shows me cloning mainline, adding my repo, fetching from my repo, and checking remote.

$ cd /tmp
$ git clone git://git.sugarlabs.org/paint/mainline.git paint.git
Initialized empty Git repository in /tmp/paint.git/.git/
remote: Counting objects: 1480, done.
remote: Compressing objects: 100% (599/599), done.
remote: Total 1480 (delta 832), reused 1409 (delta 789)
Receiving objects: 100% (1480/1480), 503.23 KiB | 108 KiB/s, done.
Resolving deltas: 100% (832/832), done.
$ cd paint.git
$ git remote add quozl git://git.sugarlabs.org/paint/quozl.git
$ git fetch quozl
remote: Counting objects: 66, done.
remote: Compressing objects: 100% (48/48), done.
remote: Total 48 (delta 26), reused 0 (delta 0)
Unpacking objects: 100% (48/48), done.
From git://git.sugarlabs.org/paint/quozl
 * [new branch]      master     -> quozl/master
 * [new branch]      trial-3    -> quozl/trial-3
$ git remote -v
origin  git://git.sugarlabs.org/paint/mainline.git (fetch)
origin  git://git.sugarlabs.org/paint/mainline.git (push)
quozl   git://git.sugarlabs.org/paint/quozl.git (fetch)
quozl   git://git.sugarlabs.org/paint/quozl.git (push)
$ 

<bernie> godiard: aren't the first commits different from the ones in mainline?

<Quozl> godiard: e430f2742f910d16a59318060bd39fc80e37822b for example has wrong author.

<bernie> Quozl: hehe, we can fix that :)

<Quozl> bernie: there are two lines of descent ... there were a few patches that Gonzalo sent before e-mail address was correct, such as 125a5dc57ab03bb8ac22cbcf259ede6b6857a338.

<godiard> yes

<bernie> Quozl: ah I see

<bernie> godiard: ok, let me know when you feel ready for the next wave of distributed version control theory :)

<godiard> tell me

<godiard> my wife is calling me to dinner :)

<Quozl> godiard: after cloning mainline.git and fetching quozl.git, the result is a repo that contains the patches but is currently showing files representing mainline.git's status. fetch doesn't change the files, it only grabs patches.

<Quozl> ah, bad time.

<bernie> godiard: ok, now normally one would do (don't do it!): git merge quozl/master

<Quozl> always pre-empt git with wife. long learning.

<bernie> godiard: this would do a so-called merge between your history and his history

<bernie> godiard: it would look like this:

                      A---B---C topic
                     /         \
                D---E---F---G---H master

<bernie> godiard: (the line between C and H is what the merge does)

<godiard> ok

<bernie> godiard: this is very stupid and even cvs and svn could do it

<bernie> godiard: but we want to do more

<bernie> godiard: we want to do something called a "rebase"

<Quozl> the problem with doing "git merge quozl/master" at this point is that all of my mistakes in history are simply copied into mainline.

<bernie> Quozl: exactly!

<godiard> quozl: aha

<Quozl> copying my bad history into mainline makes mainline history harder to read.

> walterbender:< are you enjoying the git class too? :-)

<bernie> godiard: the rebase would take the old history that looked like this:

                      A---B---C topic
                     /
                D---E---F---G master

<Quozl> godiard: the history of change to code is almost as valuable as the code itself, sometimes.

<bernie> godiard: and change it to a new history that looks like this:

                              A´--B´--C´ topic
                             /
                D---E---F---G master

<Quozl> (quozl.git is topic?)

<bernie> godiard: take your time to see what is happening :)

<bernie> Quozl: yep

<godiard> bernie: ok

<bernie> Quozl: and yep, the history is important... maybe not in a small activity, but it's very important in a project the size of sugar

<godiard> bernie: i will to print this and read many times :)

<Quozl> godiard: you must go to dinner now?

<bernie> godiard: ok, git can do this almost automatically. sometimes it will need your help because A, B, C changed the same lines of E, F, G...

<bernie> godiard: I can suggest some cool git tutorials and docs

<godiard> bernie: this time is easy, mainline didn change

<bernie> godiard: anyway, after all the theory, all you need to do is: git rebase quozl/master

<bernie> godiard: WHAM! you have rebased

<godiard> bernie: yes, i need read more

<godiard> bernie: i can do it now?

<bernie> godiard: you could, but you would make a small mistake. I did it... so you can do it too and I'll show you how to remedy

<godiard> First, rewinding head to replay your work on top of it...

<godiard> Fast-forwarded master to quozl/master.

<Quozl> works for me too, but it looks the same in gitk. what is the difference?

<bernie> godiard: ok, now look at the history... you have all the changes that quozl had done!

<godiard> yes

• tinker-f595 has quit (Quit: tinker-f595)

<Quozl> (including that double line of descent around #931 #1902 and #1015)

<bernie> Quozl: now all of your changes are also on the local master branch

<godiard> then i must do push?

<bernie> godiard: ok, here's the mistake: we forgot to change all the commits to adjust the author and logs!

<godiard> aha

<godiard> i can do it in the local repo?

<bernie> Quozl: oh yeah, I see it. fixing it would require a little more work

• chrowe has quit (Quit: chrowe)

<bernie> godiard: yes, first we need to undo the rebase

<bernie> godiard: I promised git can undo anything, but how can this be done?

<godiard> bernie and quozl: sorry can we continue in 1 hour?

<bernie> godiard: if you remember what the first commit was before the rebase, you can return to it with "git reset --hard <commit-ish> "

<bernie> godiard: sure

<bernie> godiard: see you later

<bernie> godiard: ok, so... where were we?

<godiard> bernie: we need to correct old commits

<bernie> godiard: oh yes. first, we'd better undo the mistake of rebasing with no change

<bernie> godiard: I mean, the mistake of rebasing without editing the interim commits

<godiard> bernie: ok git reset ?

<bernie> godiard: in order to do this, meet the multiple-undo log of git: git reflog

<bernie> godiard: this will show you the last operations that changed the repo

<godiard> bernie: ok

<godiard> bernie: i have one checkout and one clone

<Quozl> i have a clone of mainline.git to which i did a fetch of quozl.git then a rebase quozl/master.

<Quozl> i see, yes, reflog shows one checkout (most recent) and one clone (least recent).

<bernie> Quozl: reflog sometimes does not show the exact operation you did. in this case, the checkout is the rebase

<Quozl> here is the reflog output.

e4e1d7a HEAD@{0}: checkout: moving from master to e4e1d7a25550594f6c8d745203f1c110da400c26^0
3fb9bd6 HEAD@{1}: clone: from git://git.sugarlabs.org/paint/mainline.git