21:00:26 <dapal> #startmeeting
21:00:26 <MeetBot> Meeting started Thu Nov 25 21:00:26 2010 UTC.  The chair is dapal. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:26 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:00:29 <dapal> #topic Using git
21:00:47 <dapal> Hello everybody
21:00:55 <magellanino> hello dapal
21:01:00 <dapal> today, I'll be talking about how to use git
21:01:07 <magellanino> wow
21:01:16 <dapal> magellanino: please.
21:01:35 <dapal> If you have any questions, please direct them to #dw-question , and prefix them with "QUESTION: "
21:01:47 <dapal> aghisla will take care of posting them here, when it's more appropriate
21:02:18 <dapal> feel free to make any kind of question, even if it might seem silly -- the answer could help other people
21:02:48 <dapal> In the first part of this session, I'll talk a bit about the theoric part of using git
21:03:13 <dapal> In the second part, I'll show some practical usage, with an online git repository.
21:03:26 <dapal> So, first of all. What is "git"?
21:03:36 <dapal> Git is a Distributed Version Control System
21:04:12 <dapal> the important part here is "Version Control System" -- it means that it's a software that lets you track changes in files
21:04:35 <dapal> ...and compare different "versions", and do other nice things, like going back to a previous versions of a certain file
21:04:58 <dapal> Git is used by many modern software projects, so it's good to know how it works a bit
21:05:12 <dapal> I won't go into much detail, I'll just explain the basic things to understand how it works
21:05:24 <dapal> and to make a basic usage of it.
21:05:41 <dapal> so, first of all, the theory
21:05:52 <dapal> I'm sorry, this part will be boring, but I promise I'll strip it down to the necessary things
21:06:28 <dapal> First, let's talk about git's "storage model", i.e. how it stores data inside a repository
21:07:06 <dapal> Every "object" inside a git repository is identified by a unique string
21:07:16 <buzzz> сделал
21:07:29 <dapal> this is called the "hash". It usually is a SHA1sum of some properties which we'll talk about later
21:07:56 <dapal> A git "object" can be one of blob, tree, commit or tag. Let's see these one at a time
21:08:38 <dapal> A "blob" is a git-object that stores file data. This is generally a file on disk.
21:09:04 <dapal> A "tree" is like a directory: it references other trees and/or blobs. Imagine it like a directory with files and subdirectories inside it
21:09:45 <dapal> A "commit" is a reference to a single tree, and also contains other meta-information, like a timestamp, the author (name and email) of who made the changes, and a pointer to the previous commit
21:09:58 <dapal> generally, when using git, we only refer to the commits.
21:10:38 <dapal> The last object type is a "tag" -- it is just a way to mark a commit as special in some way. Generally, tags are used to mark a commit with version numbers, releases and so on.
21:10:41 <dapal> Questions?
21:11:15 <dapal> (if I go too fast, please tell me. I'll be happy to slow down)
21:11:43 <dapal> Ok, I suppose there are no questions :)
21:11:53 <dapal> Either I'm very good, or I'm very boring O:)
21:12:06 <dapal> Ok, let's continue.
21:12:09 <aghisla> no questions so far, and speed is reported as ok
21:12:26 <dapal> So, we analyzed git as a Version Control System.
21:12:40 <dapal> At the beginning of the session, I said it was a "Distributed" VCS.
21:12:56 <dapal> "Distributed" is an architectural detail of git, which has some pros and some cons.
21:13:10 <dapal> Many of you might know "famous" VCS'es, like CVS and SVN
21:13:22 <dapal> these are called "Centralized" VCS.
21:13:57 <dapal> The difference is that with Centralized VCS, you need to have a connection to the central server, where all the data is kept, to do many operations
21:14:13 <dapal> think of the "log" operation: SVN needs to connect to the server to retrieve it
21:14:44 <dapal> with Distributed VCS (and git is only one of them), this doesn't happen: every copy of the repository is a *full* copy
21:15:14 <dapal> this means that operations are generally faster and, moreover, that you can just use git on your local computer, without having a server
21:15:49 <dapal> All clear?
21:15:51 <dapal> MadameZou: welcome :)
21:16:06 <aghisla> there is a question
21:16:13 <dapal> Ok, go :)
21:16:20 <MadameZou> dapal thank you sorry for the delay
21:16:30 <aghisla> "pimeja: does the commit's tree object contains the whole project's tree or only changed files?"
21:17:10 <dapal> A commit's tree object represents how the whole repository looked like at a certain point in time; so yes, it contains references to the whole projec tree
21:17:49 <dapal> Other questions?
21:17:55 <pimeja> thanks
21:18:32 <aghisla> "(10:18:05 PM) lilith: a maybe early QUESTION: when cloning with --depth 1 what parts are omitted and how incomplete is the local repo ?"
21:19:07 <dapal> lilith: it is early indeed, would you please keep it for when I'll talk about the "Distributed workflow"? :)
21:19:56 <dapal> Ok, I suppose we can continue
21:20:37 <dapal> obviously, a Distributed VCS also has its cons. The most important problem I see with it is the higher number of "conflicts" happening
21:21:09 <dapal> this is because with Centralized VCS's, a commit is usually refused if it conflicts with server's copy
21:21:38 <dapal> with Distributed VCS's instead, anyone can commit anything in her local repo, and conflicts only show up at "push" time
21:21:45 <dapal> (remember "push", I'll talk about it later)
21:22:35 <dapal> We talked about git "objects". Now we should talk about git's storage model
21:22:50 <dapal> in git we distinguish a working area, an index and a repository
21:23:25 <dapal> The "working area" is made by the files currently present in our git-tracked directory
21:24:01 <dapal> The "index" and "repository", instead, are contained inside ./.git/ -- this is where all the git repository lives, and it is sufficient to recreate the contents of the directory
21:24:30 <dapal> Going further, we can say that the "index" is like a temporary staging area, where you can add files before committing them
21:24:57 <dapal> once they're committed, they go into the repository, and this action is kept in the repository's history
21:25:20 <dapal> while, if you don't commit them, you can still remove files from the index without leaving any trace in the repository history
21:25:26 <dapal> Any questions so far?
21:26:10 <MadameZou> QUESTION: files go to index by doing: git  commit
21:26:27 <dapal> No, "git commit" creates a commit and puts it in the repository
21:26:52 <dapal> I would've talked of it later, but this image explains it well, I think: http://osteele.com/images/2008/git-transport.png
21:27:44 <dapal> Any other question?
21:27:55 <aghisla> QUESTION: if I copy all files without the .git directory I lose all commit history?
21:28:16 <dapal> Yes, the .git directory is the one keeping all the history, the commits, everything.
21:28:27 <dapal> And one just needs a .git directory to recreate a repository
21:29:44 <dapal> I believe this ends the "theory" part. Since this is a *training* session about *using* git, I guess everyone wants to play a bit
21:29:54 <MadameZou> dapal: another question
21:30:00 <dapal> ok, go
21:30:05 <MadameZou> QUESTION: is the index in the .git directory?
21:30:33 <dapal> Yes, it's kept there
21:30:49 <aghisla> another question
21:32:30 <dapal> aghisla: /me waiting :)
21:32:43 <aghisla> QUESTION: push will fail if there are some conflicts? if so then this cons can be prons, because shared repository (if it used) will always at working status
21:33:44 <dapal> Yes, the push will fail. I said earlier that the higher number of conflicts was a con of distributed VCS's, but git will let you solve the conflict and re-push
21:34:37 <MadameZou> dapal: give me the ok for the next
21:34:37 <dapal> About the "shared repository will always work" bit: also centralized VCS's solved conflicts, but they did so automatically
21:34:41 <MadameZou> (ops)
21:35:04 <dapal> this could lead to wrong fixes -- git, instead, is a "stupid" content tracker, so asks for your help any time it needs it.
21:35:42 <dapal> So, while SVN would automatically fix the conflict for you (but you don't really know for sure what will end up in the repository), in git the push fails, and you deal with the conflict locally (and then re-push)
21:36:05 <dapal> MadameZou: please go :)
21:36:13 <MadameZou> yessir
21:36:18 <MadameZou> <dapal> And one just needs a .git directory to recreate repository << (silly) QUESTION: whats the command invoked to recreate it?
21:36:28 <MadameZou> (from lilith)
21:36:39 <dapal> It's not silly :)
21:37:15 <dapal> You just "git clone" from that directory. Let's say, you have a .git/ of some project -- just rename it to "project.git", and then "git clone project.git" -- you'll end up with a project/ directory with everything in
21:37:41 <dapal> the rename is made to make everything easier, you could just do "git clone .git myotherdir"
21:37:49 <dapal> (and everything will end up in myotherdir/)
21:38:30 <dapal> Other questions?
21:39:06 <dapal> Ok, let's go to the practice
21:39:29 <dapal> (it's really a mixed theory+practice, but anyways..)
21:40:01 <dapal> For the practice part, I wanted to use a real-world project, instead of making up some repository by myself
21:40:20 <dapal> I chose to use GNU Hello, please download the tarball from http://ftp.gnu.org/gnu/hello/hello-2.6.tar.gz
21:41:11 <dapal> We will create a repository from this source code.
21:41:26 <dapal> So, let's get the tarball:
21:41:31 <dapal> $ wget http://ftp.gnu.org/gnu/hello/hello-2.6.tar.gz
21:42:06 <dapal> Once it's finished, unpack it: $ tar zxvf hello-2.6.tar.gz
21:42:12 <dapal> This will create a hello-2.6/ directory
21:42:31 <dapal> Now, enter this directory, and we'll start playing with git.
21:42:45 <MadameZou> :)
21:43:02 <dapal> First of all, we need to configure our username and our e-mail. These info will be used in our commits, and will be visible in the repository history
21:43:23 <dapal> To do so, we use "git config"
21:43:38 <dapal> in particular, since we're complete beginners, we want to set a global user name / email
21:43:49 <dapal> to do so, let's do:
21:44:07 <dapal> $ git config --global user.name "Debian Woman Attendant"
21:44:22 <dapal> $ git config --global user.email "attendant@debian.org"
21:44:29 <dapal> (obviously use your data :))
21:45:04 <dapal> The --global switch will make these changes global, i.e. for any git repository on your computer
21:45:17 <dapal> it will write data to ~/.gitconfig
21:45:31 <dapal> check that file, after you've given those two commands. You'll see the data you entered.
21:46:18 <dapal> The user name and email can be also set on a per-repository basis: in this case, you'll need to do it _after_ creating the repository, and without the --global switch
21:46:39 <dapal> Without --global, it will write data into ./.git/config , i.e. locally
21:46:42 <dapal> Any questions?
21:47:21 <aghisla> Processing...
21:47:27 <dapal> ok, waiting then :)
21:48:04 <aghisla> QUESTION: how can I get current setting of global username and email? (I just want to know setting before I change it :) )
21:48:29 <spion> ~/.gitconfig ?
21:49:00 <dapal> To get a specific value, you can use "git config --get"
21:49:06 <dapal> so, "git config --global --get user.name"
21:49:21 <dapal> you can also list all values, as said on #dw-question, with "git config -l"
21:50:20 <dapal> ..and you can edit them with "git config", or opening an editor on ~/.gitconfig or ./.git/config (whether you want to edit the global or local configuration)
21:50:24 <dapal> Other questions?
21:51:42 <MadameZou> QUESTION: Can I patch the value of user.name etc into the files managed by git?
21:52:20 <dapal> This question has already been answered to in #dw-question, by POX, who said "yes, you can have separate config per repo, just skip the --global"
21:52:35 <dapal> however, the question opens up for other replies too
21:52:38 <pimeja> i think the question is about git filter-branch
21:52:56 <dapal> the git committer is embedded in the Commit object (remember, I said it had metadata too)
21:53:13 <dapal> so, when you change committer, you can't keep the same object hash, and it must change
21:53:36 <dapal> so, advanced things like filter-branch (who let you rewrite the history of a git repository), shouldn't *EVER* be made on a public repository
21:53:51 <dapal> because that will mean tons of conflicts, and headaches.
21:54:16 <dapal> However, it's interesting to see how one can temporarily override the configured user-name and user-email
21:54:45 <dapal> git commit can read some environment variables: GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL
21:54:55 <dapal> these, if set, will override what's in the git config
21:55:10 <dapal> in general, for any configuration variable, git will check, in order:
21:55:29 <dapal> ~/.gitconfig → ./.git/config → an environment variable, if it exists
21:55:46 <dapal> so, if you set something in ./.git/config , it will override the global one
21:55:57 <dapal> if you set a GIT_* environment variable, it will override anything else
21:56:10 <dapal> also, POX suggests me to point out that ./.git/config extends ~/.gitconfig
21:56:30 <dapal> that means that one doesn't have to copy over all the content from the global configuration
21:57:35 <dapal> Any more questions?
21:57:35 <dapal> (I just lost myself, need to scroll back to see where we got so far)
21:57:56 <MadameZou> lost in irc session
21:58:04 <dapal> I'm getting an ACK from #dw-question, so let's go on
21:58:20 <dapal> We've set our username and our e-mail. Now, we need to create the git repository
21:58:35 <dapal> So, we have a hello-2.6/ directory: enter it, and issue "git init"
21:58:50 <dapal> You'll see something like:
21:58:55 <dapal> Initialized empty Git repository in /tmp/dw/hello-2.6/.git/
21:59:22 <dapal> "git init" simply creates a .git/ directory, with some default values in it
21:59:41 <dapal> To see the status of a repository, launch "git status"
21:59:52 <dapal> It will show you tracked/untracked files, and the status of the index
22:00:07 <dapal> Also, it will show you on what "branch" you are (I'll cover branches later)
22:00:30 <dapal> We still don't have anything in the repository, though. So, let's add the source code:
22:00:34 <dapal> $ git add .
22:00:48 <dapal> The "." is common Unix-syntax -- it means "current directory"
22:00:57 <dapal> So, we're effectively adding everything
22:01:25 <dapal> Now, check "git status" again. You'll see that something changed
22:01:44 <dapal> What you see now is the status of the *index*
22:02:00 <dapal> we could still remove things from the index, without leaving traces in the repository history
22:02:21 <dapal> Let's do it! Let's remove AUTHORS from the index, and put it back to the untracked status:
22:02:34 <dapal> $ git rm --cached AUTHORS
22:03:03 <dapal> Now, check "git status" again. You'll see "Changes to be committed" (the index) and "Untracked files"
22:04:09 <dapal> We want to commit the files in the index: this will create a commit, with a hash, and will be kept in the repository history
22:04:13 <dapal> Let's do it:
22:04:18 <dapal> $ git commit
22:04:45 <dapal> This command will open your $EDITOR (mine is nano, the default on Debian is vim AFAICT, check yours), where you should write a commit message.
22:04:59 <dapal> If you don't write one, the commit will abort (yes, you *need* a commit message)
22:05:04 <dapal> Let's say it's "Initial commit"
22:05:48 <dapal> Now, "git status" again. The files from index are gone!
22:06:04 <dapal> They've been committed to the repository, and a log has been kept.
22:06:30 <dapal> You can see the log with "git log" -- it will show you the committer (with the data you set before), the timestamp, and the commit has
22:06:47 <dapal> *hash, sorry
22:07:09 <dapal> You can also see the last commit with "git show"
22:07:36 <dapal> It will automatically open $PAGER (more, less, ...), and show you the contents of your last commit
22:07:45 <dapal> "git show" also accepts a hash as argument
22:08:07 <dapal> My commit hash is: 11aab8486d20490b16b1b7d847e1cb1e4f7aa2fe . This will be different for each of you.
22:08:22 <dapal> It isn't necessary to write the full hash -- usually the first 7-8 characters are enough
22:08:46 <dapal> So, we can also use "git show 11aab848"
22:09:32 <dapal> git also supports a number of symbolic names, but I won't go into this, since I believe it's more than "basic"
22:09:41 <dapal> (I'm talking about HEAD, HEAD^, HEAD~2, and so on)
22:10:44 <dapal> POX suggests to create a GIT.txt file somewhere, so you can keep track of nice git commands you find over time
22:10:59 <dapal> also, there's a nice cheat sheet at: http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg -- that explains much of it
22:11:38 <dapal> So, we left AUTHORS out of our repository... poor people! No credit for their work!
22:11:45 <dapal> Let's fix this.
22:11:48 <dapal> $ git add AUTHORS
22:12:05 <dapal> $ git commit -m 'Also add AUTHORS'
22:12:18 <dapal> "-m" is a shortcut for "message" -- it avoids opening up $EDITOR
22:13:23 <dapal> Any question?
22:13:47 <aghisla> QUESTION: how can I get list of files that have been changed. git log just shows author, timestamp, comment and I don't need content of files (I need just list of them)
22:14:13 <dapal> The list of files changed within each commit can be seen with "git log --raw"
22:14:26 <dapal> every git command has lots of options, and manpages are usually our friends
22:15:07 <dapal> for example, it would be possible to combine git log with --raw and --pretty, to get some nicer output than just --raw
22:15:43 <dapal> The same for "git show": we can just pass a formatstring to --pretty
22:16:11 <dapal> This isn't "basic usage", however. I have a couple of git aliases which I can post after the talk
22:16:30 <dapal> (or yes, use a GUI, thanks to tixy on #dw-question -- I use gitg too sometimes)
22:16:34 <dapal> Other questions?
22:16:41 <hmw> QUESTION: Does git preserve file modes of the managed files or do we need work arounds?
22:17:02 <dapal> hmw: it preserves file modes, and it also notices when you change them
22:17:15 <dapal> i.e. a commit could also only consists of a filemode change
22:17:42 <dapal> Other questions?
22:18:15 <aghisla> QUESTION: git show shows a huge file. Any comment about it?
22:18:34 <dapal> This is because it's the first commit, where we imported everything
22:18:49 <dapal> Usually, it's better to do "atomic" commits (I'd say this is generally good practice)
22:19:08 <dapal> so usually you won't see that *huge* output
22:19:34 <dapal> and, anyways, it's using less by default, so you shouldn't have much problems with it :)
22:19:45 <dapal> Other questions?
22:19:46 <aghisla> QUESTION: can i just copy that folder to my webserver and let other people clone it with git clone http://myserver/hello-2.6 ?
22:20:39 <dapal> yes, you can. If you don't need the actual files in that directory, it's usually better to just share the ".git" directory, usually called like "project.git". This is called a "bare repository".
22:21:24 * dapal ready for other questions
22:21:32 <aghisla> QUESTION: Is there some way to simplify: git add + git commit -m  ?  or it just works one by one?
22:21:55 <dapal> Yes, there is. If you just want to commit all files, just use the "-a" switch of git commit
22:22:22 <dapal> so, git commit -a -m "Message" will just commit everything currently tracked
22:23:28 <dapal> Other questions?
22:23:54 <aghisla> none atm
22:23:59 <aghisla> empty stack
22:24:08 <dapal> Ok, let's go on
22:24:51 <aghisla> wait, one right now
22:24:56 <dapal> okay
22:25:17 <aghisla> QUESTION: One thing that seems alway strange to me is to have the repository as a part of the workspace. Is it easy to have the repo in a different directory tree? Or do I need additional repos for that?
22:26:08 <dapal> You can, but this is a bit advanced, I'd say. Read the git-config manpage about "core.worktree"
22:27:04 <dapal> aghisla: can you take note of that for the intermediate/advanced talk about git? (if we'll ever make one?)
22:27:15 <dapal> Other questions?
22:27:58 <aghisla> just one before going ahead: QUESTION: e.g I have web application under git and I want deploy it but w/o .git directory. What's better way to do it?
22:28:29 <dapal> the same answer to the one before: explicitely setting core.worktree in ./.git/config to a different path
22:29:07 <dapal> Can we go on?
22:29:43 <aghisla> yes
22:29:48 <dapal> Ok, great
22:30:08 <dapal> Now, we'll edit some files, see the differences, and commit them
22:30:24 <dapal> First, let's pretend we wrote bits of the current source. Let's add our name to AUTHORS :)
22:31:09 <dapal> Let's also add something to ChangeLog
22:31:16 <dapal> whatever you want, it's just an example
22:31:36 <dapal> Now, "git status"
22:31:48 <dapal> You'll see two lines starting with "modified"
22:32:07 <dapal> You can see the differences you introduced: git diff
22:32:25 <dapal> (optionally, "git diff filename" will show you only the differences in that file)
22:32:36 <dapal> if you're happy with the diff, let's commit it
22:32:49 <dapal> you can either git add them one by one, and then git commit
22:32:51 <dapal> or just use:
22:33:00 <dapal> $ git commit -a -m "Some message"
22:33:29 <dapal> The "-a" switch, as said somewhere before, will add everything to the index (from the tracked files, it won't touch untracked ones)
22:33:42 <dapal> You'll see:
22:33:43 <dapal> [master 3295347] Some message
22:33:43 <dapal> 2 files changed, 5 insertions(+), 0 deletions(-)
22:33:52 <dapal> "master" is the branch we're currently in
22:34:17 <dapal> the string after it is the commit hash -- you can use it in most commands (git show <commit>, git log <commit>, and so on)
22:34:34 <dapal> then, it comes the log message
22:34:39 <dapal> and the diffstat output.
22:34:46 <dapal> Now, what is a "branch"?
22:35:09 <dapal> Think of your git repository as a river. At a certain point, development can diverge from the "main flow"
22:35:20 <dapal> and it can stay on its own, or merge back to the main river
22:35:27 <dapal> Now, our "master" is the "main river"
22:35:44 <dapal> Let's make a branch, let's call it "debian"
22:35:50 <dapal> $ git branch debian
22:36:05 <dapal> To change to this new branch, use "git checkout"
22:36:08 <dapal> $ git checkout debian
22:36:35 <dapal> A shortcut for the above two commands is: git checkout -b debian
22:37:28 <dapal> Questions?
22:37:39 <dapal> Ah, oops, sorry, we said at the end :)
22:37:54 * Monotoko thinks he may be *slightly* late
22:38:28 <dapal> Ok, so, we checked out the "debian" branch
22:38:39 <dapal> to confirm it, execute "git branch", without arguments
22:38:55 <dapal> it will show you the current local branches, and a "*" will be prepended to the branch you're currently in
22:39:07 <dapal> to go back to the master branch, just: git checkout master
22:39:16 <dapal> For the moment, we'll stay in the debian/ branch
22:39:21 <dapal> ehm, *debian
22:39:34 <Monotoko> is the chat transcript anywhere? I had to work late and forgot to switch my IRC client on
22:39:37 <dapal> Inside this branch, let's pretend we are going to do the packaging work
22:39:51 <dapal> Monotoko: will be at the end of the session -- questions to #dw-question please :)
22:40:26 <dapal> So, let's create a debian/ directory
22:40:36 <dapal> if the directory is empty, "git status" won't show it
22:40:53 <dapal> this is expected behaviour: git doesn't track empty directories
22:41:08 <dapal> to trick it into doing so, you can add an empty file to that directory
22:41:21 <dapal> I usually add a ".gitignore" (it's a special file used by git), to let it track empty directories
22:41:26 <dapal> so, let's do all this:
22:41:29 <dapal> $ mkdir debian
22:41:33 <dapal> $ touch debian/.gitignore
22:41:48 <dapal> Now "git status" will show an untracked debian/. Add it and commit it.
22:42:55 <dapal> Now, let's go back to the "master" branch
22:42:58 <dapal> $ git checkout master
22:43:43 <dapal> Now, we want to make these two branches diverge, to simulate a real-world branching
22:44:20 <dapal> change any file you want, anything, and commit it
22:45:15 <dapal> Now, you can use a GUI (gitg, gitk), or something from the console (git show-branch) to see how the branches diverge
22:45:26 <dapal> since the GUIs are easy, we'll use the console one :o)
22:45:29 <dapal> $ git show-branch
22:45:49 <dapal> You'll see that the two branches have the initial commit in common, but then they have different commits
22:45:58 <dapal> Let's merge the changes in debian into master:
22:46:03 <dapal> $ git merge debian
22:46:17 <dapal> You'll see something like
22:46:18 <dapal> Merge made by recursive.
22:46:19 <dapal> 0 files changed, 0 insertions(+), 0 deletions(-)
22:46:19 <dapal> create mode 100644 debian/.gitignore
22:46:28 <dapal> it is *now* that conflicts will happen, if any
22:47:21 <dapal> if in the "debian" branch we changed one of the files we changed just before the merge, there could've been a conflict
22:48:20 <dapal> suggestion by POX: it could be useful to run "git mergetool" after a merge, to solve conflicts
22:48:44 <dapal> It will use one of several possible programs to handle the conflict
22:49:03 <dapal> I won't go into detail here -- for basic usage, I'd say that manual resolution of the merge is enough
22:49:04 <buzzz> buzz@dwc:/mnt/storage/project/git-test/hello-2.6$ git merge debian
22:49:04 <buzzz> Already up-to-date.
22:49:16 <dapal> buzzz: have you switched back to the "master" branch?
22:49:26 <buzzz> sorry
22:49:32 <dapal> np, you're welcome
22:49:37 <buzzz> wrong window :)
22:49:59 <dapal> now, we merged the debian branch into master
22:50:02 <dapal> let's see the log
22:50:27 <dapal> you should see something like http://paste.debian.net/100779/
22:51:12 <spion> that which command?
22:51:12 <dapal> The last bit I wanted to show for the "local" workflow is "git revert"
22:51:17 <dapal> that is "git log"
22:51:39 <dapal> After "git revert", I'll explain the distributed workflow
22:51:46 <dapal> i.e. git clone, git pull, git push, git remote
22:52:29 <dapal> So, let's suppose I see something I don't like in my "git log".
22:52:53 <dapal> For the sake of example, let's say it's (my) commit 2ba81dfaeb919e6a0c634be54fe363b11487d65a , i.e. the one where we added the debian/ directory
22:53:12 <dapal> Please remember that your commit hash will be different, so *please* check your log to get the correct hash
22:53:32 <dapal> So, I don't like it. What should I do now?
22:53:45 <dapal> I can use the "git revert" command
22:54:13 <dapal> This command basically takes the diff from a commit, applies it in reverse, and leaves conflicts, if any
22:54:16 <dapal> so, let's do it:
22:54:19 <dapal> $ git revert 2ba81dfaeb919e6a0c634be54fe363b11487d65a
22:54:44 <dapal> $EDITOR (nano/vim/...) opens up again. There is a default commit message; you can leave it as-is, or (better) explain why you're reverting the change
22:54:53 <dapal> For the sake of simplicity, let's leave the default
22:55:02 <dapal> Save the message, and quit the editor
22:55:11 <dapal> You'll see:
22:55:12 <dapal> Finished one revert.
22:55:12 <dapal> [master 37ce99f] Revert "add debian/"
22:55:13 <dapal> 0 files changed, 0 insertions(+), 0 deletions(-)
22:55:14 <dapal> delete mode 100644 debian/.gitignore
22:55:42 <dapal> This means: a revert is a commit too.
22:55:59 <dapal> With a Committer, an Author, a Timestamp, and a Hash
22:56:06 <dapal> Ideally, you can revert a revert.
22:56:35 <dapal> (you shouldn't do it :))
22:56:50 <dapal> This ends the "local usage" part.
22:57:09 <dapal> Any questions specific to this part? If not, I'll continue to the Distributed Workflow part.
22:57:19 <dapal> If there are questions on general git topics, I'll answer them latr
22:57:21 <dapal> *later.
22:58:00 <dapal> Nice, maybe everyone's sleeping :)
22:58:27 <dapal> Now, let's go to the distributed workflow.
22:58:28 * MadameZou is not sleeping!
22:58:37 * aghisla is half-awake
22:58:39 <dapal> Git is a distributed VCS, so this is a fundamental part
22:58:56 <dapal> this lets you share your work, and your development, with other people
22:59:33 <dapal> So, let's put this repository apart
22:59:50 <dapal> Before the session started, I prepared an online repository of the GNU Hello source we're using
23:00:07 <dapal> This is usually what you'll find for existing projects: an online repository
23:00:20 <dapal> You can copy its contents, i.e. "clone" it, with the command "git clone"
23:00:27 <dapal> So, let's clone the repository:
23:00:38 <dapal> (ah, before that, get out of hello-2.6/)
23:00:43 <dapal> $ git clone git://gitorious.org/debian-women/hello.git
23:01:12 <dapal> You'll see something like http://paste.debian.net/100782/
23:01:40 <dapal> Now, enter hello/, and poke around a bit. git log, git show.
23:01:53 <dapal> It's a clean repository, but you got it from the web
23:02:28 <dapal> If it were a real repository, it wouldn't probably show just one commit, nor just one branch
23:03:00 <dapal> Now, let's see where we got this repository from
23:03:21 <dapal> You can get/set info for the place where you got this repository with "git remote"
23:03:49 <dapal> There is a default "remote", it is called "origin". It is also the default one where pushes will go. Let's see it:
23:03:52 <dapal> $ git remote show origin
23:04:05 <dapal> Currently, we only care about these two lines:
23:04:06 <dapal> Fetch URL: git://gitorious.org/debian-women/hello.git
23:04:06 <dapal> Push  URL: git://gitorious.org/debian-women/hello.git
23:04:23 <dapal> It means that we're syncing from the Fetch URL, and are pushing back to the Push URL.
23:04:38 <dapal> These don't need to coincide, they can be different.
23:05:11 <dapal> Like, say, if you're keeping a patched version of some software somewhere: you'd fetch from your upstream, and push to your own location
23:05:50 <dapal> We can also add a remote without removing our previous work
23:06:09 <dapal> for that, we will use "git remote add"
23:06:22 <dapal> The syntax is like: "git remote add <remote_name> <remote_url>"
23:06:43 <dapal> usually, if you want to be able to push back to the repository, you'll need to use a git+ssh:// or ssh:// url
23:06:56 <dapal> a git://git.[..] usually doesn't permit pushes
23:07:21 <dapal> (TBH, I've never seen one that permits them, but better say "usually don't" than "never do")
23:07:54 <dapal> "git remote add" is especially useful when you're creating a brand new repository
23:08:03 <dapal> i.e. you're not cloning from anywhere
23:08:32 <dapal> I'll stop a bit, since I see there are some related questions
23:08:39 <dapal> aghisla, MadameZou, I'm ready :)
23:08:43 <aghisla> ok
23:09:02 <aghisla> QUESTION: I've created empty directory (test1) but "git status" show nothing, than I did "echo test > test1/testfile" and output of "git status" shows me # test1/ but there is no testfile. Is it expected behavior?
23:09:58 <dapal> not really related, however. Yes, it's expected behaviour, as said before, we touched an empty .gitignore inside the empty directory to make git track it
23:10:16 <dapal> Questions?
23:10:36 <MadameZou> QUESTION: What happens if you revert a change in a branch that isn't the one that you currently have checked out?
23:11:35 <dapal> It won't happen anything
23:11:42 <dapal> i.e. the revert won't happen
23:12:12 <aghisla> QUESTION: if i got a branch, and i merge it, but want to revert, how do i find out the hash?
23:12:24 <dapal> "git log" is the solution
23:13:50 <dapal> ah, before I forget
23:14:01 <dapal> reverting a merge is not that easy. You should also specify the mainline parent
23:14:08 <dapal> Read about the -m switch of "git revert"
23:14:19 <dapal> it also has some nasty (IMHO) side-effects
23:14:28 <dapal> so don't merge if you're not absolutely sure
23:14:35 <dapal> Next question?
23:14:40 <MadameZou> QUESTION: clone option, just clone master branch... or maybe others?
23:15:09 <dapal> "git clone" will only clone the master branch
23:15:48 <dapal> I mean, the other branches will be *fecthed*
23:15:55 <dapal> but no local branch will be created for them
23:16:08 <dapal> To fix this, I usually do the following for each branch I'm interested in:
23:16:16 <dapal> $ git checkout -b mybranch -t origin/mybranch
23:16:27 <dapal> (-t origin/mybranch means "track mybranch from origin")
23:17:44 <dapal> MadameZou, aghisla: other questions?
23:17:51 <aghisla> QUESTION: is there differences between git+ssh:// and git:// ?
23:18:32 <dapal> Yes, there are. "git://" is a "dumb protocol", which doesn't support (AFAIK) authentication
23:18:53 <dapal> So, in the first case, this protocol will be encapsulated in SSH -- much like svn+ssh:// or cvs+ssh:// or others
23:19:07 <dapal> in the second case, you're using the git protocol directly, i.e. without auth support
23:19:14 <dapal> Question?
23:19:17 <MadameZou> QUESTION: how limited is the local git repo cloned with --depth 1 , will i still be able to switch between branches and will it age to a less limited repo with time and git pull's ?
23:19:35 <dapal> "--depth" will specify how much history to get from a repository
23:20:20 <dapal> ehm, sorry, I was a bit adk
23:20:21 <dapal> *afk
23:20:35 <dapal> back now. I was saying, it specifies how much history to get from a repository
23:20:51 <dapal> this means that, for example, you're interested in only the recent history of a large project
23:21:13 <dapal> and, it also has limitations: for example, you can't clone it, nor push from/into it
23:21:48 <dapal> I must be honest, I haven't ever used --depth
23:22:03 <dapal> I only read about it at the beginning, when I started "studying" git
23:22:16 <aghisla> dapal there is a correction in git+ssh question, it was opposed to ssh:
23:22:49 <dapal> ah, ok
23:22:56 <dapal> yes, there's difference also there
23:23:19 <dapal> let's see the same repo with the two different protocols
23:23:29 <dapal> git+ssh://git.debian.org/git/collab-maint/wicd.git
23:23:55 <dapal> ahem, ehm, no, wrong example :D
23:24:04 <dapal> ok, I don't have a usecase handy, sorry
23:24:49 <dapal> Apart from technicalities about the protocol used
23:24:54 <dapal> and what the server supports
23:25:05 <dapal> I can't think of any difference from a "user" point of view
23:25:20 <dapal> aghisla: other questions?
23:25:43 <aghisla> no, stack is empty!
23:25:54 <dapal> Seems like that's all then :)
23:25:57 <dapal> #endmeeting