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