[15:30:28] --------- git session begins ---------- [15:30:30] --> vivek (n=vivek@117.201.98.228) has joined #dgplug [15:30:43] roll call! please tell your name [15:30:55] Kishan Goyal [15:30:55] vivek [15:30:55] Ratnadeep Debnath [15:30:59] --> sunny_slls (n=sunny@125.20.11.34) has joined #dgplug [15:31:14] koyel banerjee [15:31:21] partha chowdhury [15:31:24] Abhishek Sharma [15:31:28] Meejanur Rahaman [15:31:35] Sunny Sharma [15:31:49] Abhishek Gupta [15:32:05] ok, thanks! here after if you need to talk you need to type '!'; [15:32:07] cd .. [15:32:13] magesh [15:32:36] Stéphane Péchard [15:32:43] If you haven't downloaded the .pdf yet, please download the presentation from http://shakthimaan.com/downloads/glv/presentations/di-git-ally-managing-love-letters.pdf [15:33:16] hi spechard [15:33:29] sunny_slls: don't interpret! [15:33:49] mbuf, sorry [15:33:50] today session is an introduction on using git -- a decentralized source control management tool; [15:34:07] --> zer0c00l_ (n=zer0c00l@117.199.137.176) has joined #dgplug [15:34:15] this tool is very important for all, because, it helps in your workflows, or the way you are going to work; [15:34:37] I am going to address some basics concepts of the tool, so understanding these are important; once you understand the flow, it becomes really useful [15:35:22] this is not just for source code, but, can be used for your HOWTOs, documentation, assignments, research papers, thesis, and anything text-based that you need to keep track of the history of changes; [15:35:43] <-- debayan (n=debayan@61.95.198.26) has quit (Read error: 110 (Connection timed out)) [15:35:59] roll call time [15:36:21] for your projects or documentation you can use http://git.fedoraproject.org/git/ or gitorious.org [15:36:28] no_mind: its been done! [15:36:48] to host your git repos; but, git is very useful to work without Internet connection; [15:37:10] you work with a local copy of the repo in your system itself! [15:37:38] the source of this presentation has also been put in a git repo, which you can get from: http://gitorious.org/di-git-ally-managing-love-letters/mainline/blobs/master/di-git-ally-managing-love-letters.tex ; it has been done in LaTeX and LaTeX-Beamer [15:37:59] --> #n, means slide number 'n' [15:38:06] mbuf: is it a local repository at localhost [15:38:10] --> kushal (n=kdas@fedora/kushal) has joined #dgplug [15:38:19] abhishekg: if you want to talk, type '!' [15:38:29] abhishekg: don't type your message straight away! [15:38:31] mbuf:! [15:38:52] abhishekg: yes, it is a local repository at localhost [15:39:09] abhishekg: when you are done talking use 'eof'; these were addressed in the previous chat IRC logs; [15:39:24] --> #1 [15:39:58] This is version 1.3 of the presentation; you are welcome to freely re-distribute the presentation or present it to your friends; [15:40:02] <-- sumitc (n=chatzill@unaffiliated/sumitc) has quit (Read error: 110 (Connection timed out)) [15:40:04] --> #2 [15:40:14] Please read the 'Warning' [15:40:30] --> #3 [15:40:53] You have to initially define your user.name and e-mail address which will be used in git commits; [15:40:59] --> #4 [15:41:31] these commands update your /home//.gitconfig file [15:41:37] --> #5 [15:41:40] --> #6 [15:41:43] --> #7 [15:41:46] --> #8 [15:41:54] or you can manually update your .gitconfig file; [15:42:19] I have setup a gl alias that I can invoke with git, "git gl" to show the commit logs in the slides; [15:42:29] we will use it in this presentation; [15:42:37] --> #9 [15:42:57] I am only going to show how to manage love-letters, not write love letters :) [15:43:36] working tree defines our local directory structure, / [15:43:45] I am simply creating a directory love-letters [15:43:47] --> #10 [15:43:59] --> #11 [15:44:22] in this top-level love-letters directory, I am initializing a git repo; [15:44:36] it basically creates a .git directory in this top-level love-letters directory [15:45:01] --> #12 [15:45:13] The command and the outputs are shown in different font style formats; [15:45:18] --> #13 [15:45:20] --> karthick (n=karthick@59.96.30.64) has joined #dgplug [15:45:27] I am creating a new file called "to-my-dearest.txt" [15:45:42] so the working tree represents what you see in your directory [15:45:49] --> #14 [15:46:14] I am making some changes to to-my-dearest.txt file, by editing it with any editor of my choice; [15:46:18] --> #15 [15:46:48] The index is also known as the staging area; before you commit your love letter you want to stage it (for rehearsal, perhaps) before you commit to your local repo; [15:47:08] ! [15:47:10] so any change you make in the files are pushed to index, before committing to the repo; [15:47:13] hermes: shoot! [15:47:47] hermes: yes, what is your question? [15:47:55] please elaborate the above 2 lines that u just typed , [15:48:02] I dint quite understand [15:48:04] eof [15:48:33] hermes: let me finish one iteration, and if you still don't understand, type '!' again; [15:48:52] mbuf : alright [15:49:05] so, I have made some changes to to-my-dearest.txt since I created it touch [15:49:15] <-- zer0c00l (n=zer0c00l@117.199.137.176) has quit (Read error: 113 (No route to host)) [15:49:21] and before I commit it to my local repo, I am staging it with 'git add' [15:49:32] <-- no_mind (i=7aa38309@gateway/web/freenode/x-2cf763c7f1d80887) has quit ("Page closed") [15:49:41] git basically creates object references for the change; everything is stored in .git/ directory [15:49:48] --> #16 [15:50:00] --> sa111 (i=3b601e40@gateway/web/freenode/x-872bd38ae2dc4a09) has joined #dgplug [15:50:03] --> no_mind (i=7aa38309@gateway/web/freenode/x-6f36f204128fe3fa) has joined #dgplug [15:50:05] that is how you commit the message; as you can see the change is in the repository [15:50:18] --> #17 [15:50:25] --> #18 [15:50:30] --> #19 [15:50:44] ! [15:50:45] You can always check the status of the git repo using 'git status' [15:50:54] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [15:51:07] if it doesn't mention any warning, or error messages, your repo status is clean; [15:51:29] so, the basic idea is that one needs to make changes to your local files, add it to the index and then commit it to the repository; [15:51:30] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [15:51:41] the use of index, is that if you don't want to commit things to the repo, you can backtrack; [15:52:00] one of the biggest mistakes that newbies do, that I have observed, is that they hack on the same code, again and again and again [15:52:15] so after two days, you ask them to revert their changes to what was two days back, they will not be able to do it; [15:52:21] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [15:52:44] but, committing code locally, often and repeatedly, will help one to revert back the commit, or see what changes have been made, and what can be undone; [15:53:18] what are the commands that are used for this workflow between working tree, index and repo is what we will see here today; you may or may not use everything in real-life, but, it is good to know; [15:53:20] parthachowdhury: shoot! [15:53:35] what is 958d5ac ? [15:53:51] parthachowdhury: that is a SHA1 commit number; [15:53:57] ! [15:54:01] parthachowdhury: for every commit you make a unique number is generated [15:54:06] parthachowdhury: wait, let me finish; [15:54:14] ok [15:54:17] parthachowdhury: this is used to identify your unique commit; [15:54:32] is it the object reference ? [15:54:42] parthachowdhury: I said wait! [15:55:10] parthachowdhury: so if someone else copies your repository, which includes the .git repo, and your history of changes, they will see your commit messages; [15:55:27] parthachowdhury: we will not go into git internals, as that is left as an exercise, and not in the scope of this session; [15:55:44] parthachowdhury: git doesn't track files, unlike what cvs and svn do; it tracks content changes [15:55:51] --> vivek_ (n=vivek@117.201.101.73) has joined #dgplug [15:55:55] parthachowdhury: so each commit is only info on the change that you have done; [15:56:06] --> #20 [15:56:06] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [15:56:12] --> #21 [15:56:27] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [15:56:31] so git gl shows use the first commit that we made, with the commit message "FIrst commit" [15:56:34] ! [15:56:43] just a brief message to fit in the slide; [15:56:44] hermes: shoot! [15:57:07] mbuf : you said that it is a SHA1 commit number which is unique [15:57:16] mbuf :what is SHA1 ? [15:57:17] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [15:57:19] mbuf :eof [15:57:27] <-- karthick (n=karthick@59.96.30.64) has quit ("Leaving") [15:57:30] hermes: you can google that? [15:57:36] ! [15:57:41] mbuf : alright [15:57:45] sunny_slls: shoot! [15:57:47] <-- vivek (n=vivek@117.201.98.228) has quit (Read error: 104 (Connection reset by peer)) [15:57:49] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [15:58:03] hermes: http://en.wikipedia.org/wiki/SHA_hash_functions read later! [15:58:16] mbuf, suppose i wan't to make some changes in the .txt file [15:58:40] but the changes are not done properly so will it backtrack [15:58:51] or in other words revert [15:58:51] sunny_slls: we will see those use cases next; [15:59:11] sunny_slls: there is a lot of workflows of what you mean by 'revert' -- everything will be addressed next; [15:59:13] ! [15:59:18] abhishekg: shoot! [15:59:30] also you said about the errors that newbies make [15:59:30] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [15:59:39] about editing [15:59:44] I have installed git on opeensuse 11 [15:59:47] but it doees [15:59:50] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [15:59:53] not have gl [15:59:56] eof [16:00:12] ! [16:00:59] abhishekg: this is not the time to answer installation and configuration problems; [16:01:16] abhishekg: you should have put your gl alias in .gitconfig in your home directory [16:01:25] abhishekg: or you could have sent an e-mail to the mailing list group [16:01:25] ! [16:01:29] zer0c00l_: shoot! [16:01:46] abhishekg: before coming to the session; [16:01:47] mbuf, same as abhishekg will correct it [16:01:55] sunny_slls: shoot! [16:02:01] also you said about the errors that newbies make in editing files [16:02:33] sunny_slls: yes; they cannot revert back after changing code; for larger code bases; [16:02:36] if suppose we have got make several changes in a file then how can we do it [16:02:52] sunny_slls: all these will be addressed next; [16:02:58] ok [16:03:07] eof [16:03:09] sunny_slls: first understand the workflow, you can try to use git practically, at the end of the session; [16:03:26] please understand how things work, you can play with git after the session [16:03:44] ask only questions pertaining to the workflow; I shall not take any other questions; [16:04:00] --> #22 [16:04:03] --> #23 [16:04:34] git show gives a more detailed log output, where you can see your username, e-mail given as Author, Date, commit message, SHA-1 number and diff change [16:04:34] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 54 (Connection reset by peer)) [16:04:39] --> #24 [16:04:42] --> #25 [16:04:50] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:04:52] always good to check status [16:05:02] --> #26 [16:05:14] Now we try to write a love letter to raaani-mukerji.txt, so I create a new file [16:05:23] --> #27 [16:05:50] 'git diff' shows the difference between working tree and index; [16:05:59] --> #28 [16:06:30] 'git diff --cached' shows the difference between index and HEAD; in other words, it tells whatever will be committed, on the changes that you added to index using 'git add' [16:06:38] --> #29 [16:07:17] 'git diff HEAD' shows the difference between working tree and HEAD; [16:07:22] --> #30 [16:07:28] --> #31 [16:07:49] Since we add a file to working tree, git status is showing that there is an untracked file; tracked files are in the index; [16:07:56] --> #32 [16:08:07] so we add the raaani-mukerji.txt love letter to the index; [16:08:18] --> #33 [16:08:18] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:08:48] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:08:52] because nothing was there in index with respect to raaani-mukerji.txt, there s no diff output [16:08:55] --> #34 [16:09:01] --> #35 [16:09:22] because 'git diff --cached' shows what will be committed next, if you commit, it shows the change; [16:09:26] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:09:28] --> #36 [16:09:34] --> #37 [16:09:45] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:10:17] since we have already added the file to index, 'git diff HEAD' will show the difference because, it also shows what will be committed if you did 'git commit -a -m 'message' [16:10:24] --> #38 [16:10:37] again check git status, to see what git says [16:10:57] now our file is in index, so we can commit as we did with our first commit or we can revert; [16:11:06] --> #39 [16:11:11] --> #40 [16:11:23] raani-mukerji doesn't want to date me; [16:11:24] --> #41 [16:11:38] so we simply try to remove the love letter [16:11:44] --> #42 [16:12:02] because we have staged it to the index, git gives us the error [16:12:04] --> #43 [16:12:14] so we force remove it; [16:12:15] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:12:17] --> #44 [16:12:27] --> #45 [16:12:34] --> #46 [16:12:41] --> djthequest (i=daf85072@gateway/web/freenode/x-1c9fc357ba035987) has joined #dgplug [16:12:44] --> sumitc (n=chatzill@unaffiliated/sumitc) has joined #dgplug [16:12:45] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:12:48] so we see the file has been removed from index and the working tree; [16:12:55] --> #47 [16:12:58] --> #48 [16:13:02] our working tree is clean; [16:13:23] this was a workflow to show a file that you staged and then removed, because you didn't want to keep the file; [16:13:33] --> #49 [16:13:43] Now we try our luck with nayantaara [16:13:49] --> #50 [16:13:53] ! [16:13:54] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:13:58] hermes: shoot! [16:14:25] force deleting essentially deletes the entry from index for 'rani' [16:14:32] ? [16:14:34] eof [16:14:45] hermes: yes [16:14:56] hermes: and also the file from your folder [16:15:11] ya sure [16:15:26] index is only a collection of object references on the changes; [16:15:31] --> #51 [16:16:02] If we just want to remove from the caching staged (index) area, but, still want to retain it in the folder, we can use 'git rm --cached filename' [16:16:14] --> #52 [16:16:16] --> #53 [16:16:19] --> #54 [16:16:25] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:16:39] so we now don't have the object references in the index for nayantaaara.txt, but the file exists in the directory; [16:16:52] --> #55 [16:17:00] --> #56 [16:17:09] no difference, and hence no output [16:17:24] --> #57 [16:17:27] same as above; [16:17:31] --> #58 [16:17:38] --> #59 [16:17:39] <-- mavu_ (n=mavu@59.178.189.159) has quit (Read error: 110 (Connection timed out)) [16:17:52] --> mavu_ (n=mavu@59.178.161.154) has joined #dgplug [16:18:03] since we have added the file to the directory, but is not tracked (to index), git says you need to add it to the index; [16:18:10] --> #60 [16:18:19] make love doesn't work with Nayantaaara [16:18:25] --> #61 [16:18:49] since the object reference has already been removed from the index, we can simply remove the file; [16:18:50] --> #62 [16:19:01] --> #63 [16:19:02] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:19:04] --> #64 [16:19:13] checking git status, just to check if our repo is clean; [16:19:23] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:19:46] so this was a case where we added a file to the index, but, temporarily removed it from the index, because, we could make more changes; but, since we didn't want to make any change, we simply removed it; [16:19:52] --> #65 [16:20:07] we try a new letter for raaani-mukerji [16:20:10] --> #66 [16:20:19] we add it to the index; [16:20:25] --> #67 [16:20:46] But, she already rejected me. I forgot! So, we just rename the love letter so we can write a love letter to aishvarya-ray [16:20:52] you use 'git mv' for it; [16:21:01] yes, it works when you have added the file already to the index! [16:21:10] --> #68 [16:21:42] instead of git rm, you can use 'git reset HEAD file', in case, you feel that you might mistakenly use rm to remove a file [16:21:57] in this case, 'git reset HEAD file' does the same as 'git rm --cached file' [16:22:10] --> #69 [16:22:22] --> #70 [16:22:25] --> #71 [16:22:33] no differences, so no output; [16:22:36] --> #72 [16:22:41] --> #73 [16:22:42] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 54 (Connection reset by peer)) [16:23:05] since we add a file aishvarya-ray.txt, but, it has not been staged to the index and is thus untracked, git is saying there is an untracked file; [16:23:11] --> #74 [16:23:22] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:23:30] Aishvarya Ray is married! I didn't know that until now :( [16:23:32] --> #75 [16:23:48] --> #76 [16:23:50] so I just remove the file; [16:23:56] --> #77 [16:24:03] --> #78 [16:24:05] --> #79 [16:24:13] our local repo is clean; [16:24:19] --> #80 [16:24:31] now, let us try to write a letter to pretty-zinta; [16:24:36] --> #81 [16:24:50] ! [16:24:50] I feel the letter is satisfactory, and I want to add it to the index; [16:25:00] --> #82 [16:25:17] I feel I can give this letter a shot at, and so I commit it to the local repo; [16:25:23] --> #83 [16:25:29] sunny_slls: shoot! [16:26:13] please explain the git reset head file since the file raani mukerjee was removed from the folder which it is rejected when created later? [16:26:15] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:26:19] [16:26:45] sunny_slls: rejected is just a joke that I made; [16:26:58] sunny_slls: that is a use case scenario, where you have added a file to the index, and realized you mistakenly named it something else [16:27:08] sunny_slls: so if you want to rename it, you use 'git mv' [16:27:25] sunny_slls: git reset HEAD file, is like resetting the HEAD (part of git) [16:27:36] sunny_slls: which is the same pattern as 'git rm --cached' [16:27:52] sunny_slls: git has two pointers, HEAD and master; [16:28:00] sunny_slls: HEAD and master always point to the latest commit; [16:28:05] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:28:16] sunny_slls: there are scenarios where they can point to different things; [16:28:19] sunny_slls: we'll come to that; [16:28:23] sunny_slls: [16:28:31] <-- samar (n=samar-ad@115.108.6.29) has quit ("Ex-Chat") [16:28:35] --> #84 [16:28:40] --> #85 [16:29:00] so, now you see that we have made a second commit, and that is shown first (on the top) [16:29:15] so every time you feel you are satisfied with your work, you make a commit; [16:29:24] --> #86 [16:30:19] HEAD is the current pointer or reference; HEAD^ points to the previous HEAD [16:30:54] so what 'reset --soft' does is rever the changes such that it keeps the changes in the index; [16:31:16] and because we used HEAD^, HEAD is shifted to the previous value that it had; [16:31:21] --> #87 [16:31:25] --> #88 [16:31:43] as you can see HEAD is now in the first commit; [16:32:04] --> #89 [16:32:04] --> 90 [16:32:13] 'reset --soft' keeps the changes in the index, and the files are retained in the working directory; [16:32:19] --> #91 [16:32:27] ! [16:32:29] now, it is interesting to see the diff outputs; [16:32:30] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:32:31] <-- kishan (n=kishan@117.99.63.16) has quit (Remote closed the connection) [16:32:33] hermes: shoot! [16:32:49] why did we shift the head back to the first commit [16:33:01] --> SkyRocknRoll (n=chatzill@122.164.52.232) has joined #dgplug [16:33:03] I mean what are we trying to achieve by doing that [16:33:04] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:33:05] eof [16:33:10] hermes: because we are undoing our last commit or the most recent one! [16:33:26] hermes: let's say you made a commit in a hurry, and you want to undo or redo it! [16:33:38] alright, i get it [16:33:40] eof [16:33:48] hermes: you rever the repository HEAD to the previous one, while the last changes you made are still in the working tree; [16:33:49] hermes: :) [16:33:55] *revert [16:34:05] --> #92 [16:34:08] --> #93 [16:34:25] --> kishan (n=kishan@117.99.59.7) has joined #dgplug [16:34:28] 'diff --cached' shows the difference clearly; [16:34:31] --> #94 [16:34:37] --> #95 [16:34:50] shows what will be committed if you did 'git commit -a -m message' [16:34:50] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:34:58] --> #96 [16:35:05] --> #97 [16:35:24] good to check status, if you are not sure what the git repo state is in; [16:35:58] it says you have some changes in the index, to undo you can reset HEAD -- which will remove from index, but, still keep the files in the working directory; [16:36:03] --> #98 [16:36:14] --> #99 [16:36:21] --> #100 [16:36:28] or make some changes to satisfy pretty zinta [16:36:36] --> #101 [16:36:43] --> #102 [16:36:49] and we commit the message; [16:36:50] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:36:59] note now the commit SHA1 message will be a new number; [16:37:19] earlier it was 661bc09... [16:37:29] --> #103 [16:37:32] --> #104 [16:37:40] now it is c66e7f1... [16:37:45] --> Samsung (i=Samsung@115.108.6.29) has joined #dgplug [16:37:49] --> #105 [16:38:07] now let's say I made a mistake in the commit message; I want to fix it [16:38:13] --> #106 [16:38:18] --> #107 [16:38:25] you use 'git commit --amend' [16:38:32] --> #108 [16:38:34] --> #109 [16:38:47] again note the new SHA-1 value; [16:38:52] --> #110 [16:38:55] --> #111 [16:38:58] just checking for status; [16:39:07] --> #112 [16:39:15] now I am making some more changes in pretty-zinta.txt [16:39:19] --> #113 [16:39:58] because, there were some changes in pretty-zinta.txt in the index before and now in the working directory, git diff shows the changes; [16:40:04] --> #114 [16:40:04] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:40:13] nothing is added to index, so no change in the output; [16:40:18] --> #115 [16:40:23] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:40:26] --> #116 [16:40:50] because, we have added some changes to the working directory, and pretty-zinta.txt is already tracked in the repo, 'diff HEAD' shows the changes; [16:40:56] --> #117 [16:41:10] But, I couldn't find Pretty Zinta to give the love letter; how sad! [16:41:13] --> #118 [16:41:22] --> #119 [16:41:45] now we totally remove the committed entry in the repo _and_ in the working tree using 'reset --hard' [16:41:49] --> #120 [16:41:56] --> #121 [16:41:59] --> #122 [16:42:04] --> #123 [16:42:07] --> #124 [16:42:30] so, this was a use case, where you completely undo a previous commit from the local repo, and also the changes from your working directory; [16:42:44] this is something that you will probably use often, if you don't want to keep whatever changes you have made; [16:42:56] --> #125 [16:43:00] --> #126 [16:43:03] --> #127 [16:43:10] --> #128 [16:43:13] --> #129 [16:43:18] --> #130 [16:43:28] these are examples of using 'grep' command with git; [16:43:44] these will search source files as well as git objects (called as blobs) [16:43:51] for any search pattern that you specify; [16:43:57] --> #131 [16:44:07] --> #132 [16:44:09] --> #133 [16:44:14] --> #134 [16:44:19] --> #135 [16:44:22] --> #136 [16:44:23] --> #137 [16:44:35] there are different ways to see previous commit and log messages; [16:44:45] these are few examples; [16:45:07] --> #138 [16:45:09] --> #139 [16:45:12] --> #140 [16:45:15] --> #141 [16:45:19] --> #142 [16:45:32] git show also produces nice output; I can't show everything on a slide though; [16:45:40] when you practice after the session, you can play with these :) [16:45:41] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:45:46] --> #143 [16:46:15] sometimes you are working on a change, and you suddenly have something more important to try; but, you don't want to discard the changes you have made; [16:46:23] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:46:24] so you simply 'stash' it, or leave it aside; [16:46:30] to do that you use 'git stash' [16:46:35] <-- Shrink (n=sgupta@redhat/shrink) has quit (Read error: 113 (No route to host)) [16:46:37] --> #144 [16:46:45] even this has an identifier; [16:46:50] --> #145 [16:46:53] --> #146 [16:47:03] --> 147 [16:47:13] whatever changes you make are local and not affected by your stashed changes; [16:47:43] once you are done and you want to reapply the work that you left aside, you can just apply it back using 'git stash apply' [16:47:45] --> #148 [16:47:56] --> #149 [16:47:57] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:47:59] --> #150 [16:48:28] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:48:29] It says I have modified the file, to-my-dearest.txt, so I need to add it before committing; I just use 'commit -a -m' to do it in one shot; [16:48:35] --> #151 [16:48:53] tagging is important if you want a label for a particular commit; [16:48:57] --> #152 [16:49:10] --> #153 [16:49:14] --> #154 [16:49:26] just 'git tag' will list the tags [16:49:36] --> #155 [16:49:39] --> #156 [16:49:45] --> #157 [16:49:57] Remove the tag using 'tag -d' [16:49:58] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [16:50:01] --> #158 [16:50:05] --> #159 [16:50:22] --> yevlempy (n=yevlempy@124.124.157.94) has joined #dgplug [16:50:24] if you want your friend to use a particular tag release of your code, you can refer the same [16:50:35] and hence, one can use it for references; [16:50:44] --> #160 [16:50:51] !\ [16:50:53] sometimes, when you are working with huge projects, and you are new developer [16:51:21] they might only accept patches, so you can use the git-format-patch command to get the change you made and send it via e-mail [16:51:23] hermes: shoot! [16:51:37] --> #161 [16:51:39] --> #162 [16:51:43] --> #163 [16:51:46] --> #164 [16:51:55] these show how a git patch looks like; [16:51:58] what if i want to add a tag to some other identifier [16:52:00] --> akuscifi007 (n=akuscifi@122.162.82.58) has joined #dgplug [16:52:13] not to what head is currently pointing [16:52:14] eof [16:53:09] hermes: git has lot of command options; and each command has lot of options which are described in detail with examples in their manual page; [16:53:22] hermes: sure you can; check this (later) http://www.kernel.org/pub/software/scm/git/docs/git-tag.html [16:53:29] hermes: eof [16:53:35] --> #165 [16:53:36] mbuf :ok, thankful [16:53:40] eof [16:54:08] reflog contains list of all your previous commits; [16:54:18] --> #166 [16:54:34] so you can actually go back to some commit that you made; [16:54:41] *made directly; [16:54:45] --> #167 [16:55:08] here we resetting it to 1, i.e., where HEAD was at {1] [16:55:26] remember again, that reset --hard, will revert and also remove the changes in the working directory; [16:55:43] --> #168 [16:55:49] --> #169 [16:55:52] --> #170 [16:56:26] so we have undone all our previous changes, except our first commit; [16:56:32] --> #171 [16:56:47] git basically doesn't track files, it only tracks content; [16:57:11] so ideally, we shouldn't be creating a separate love letter for each of our dear ones; [16:57:39] what if we had one love-letter, and the change control tracker, keeps track of the changes w.r.t. each dear one; [16:58:07] so in index, and repo, only objects, or the changes are stored, and not another copy of the file; [16:58:21] so far we have been working in the default branch, called the 'master' branch [16:58:31] --> #172 [16:58:38] ? [16:58:41] I only have to-my-dearest.txt file in the working directory; [16:58:43] sunny_slls: shoot! [16:58:54] sorry typing mistake [16:59:07] sunny_slls: no problem; [16:59:12] --> #173 [16:59:20] so, I am going to try my luck with Priyaaanka-chopra [16:59:26] I create a new branch for it; [16:59:29] --> #174 [16:59:38] --> #175 [16:59:55] so you now see two branches; the asterisk (*) shows which branch I am currently working in; [16:59:59] --> #176 [17:00:06] --> #177 [17:00:16] 'branch -d' is what I use to delete a branch; [17:00:49] branching is completely handled by git, you will only see one file in the working directory; [17:01:18] but, as you switch branch, the respective changes in the file for that particular branch will prevail, when you open the file; [17:01:22] we'll see this next; [17:01:24] --> #178 [17:01:42] 'checkout -b' is used to create a new branch and to enter into it; [17:01:45] --> #179 [17:01:57] --> #180 [17:01:59] --> #181 [17:02:09] it now shows we are in the priyaaanka-chopra branch; [17:02:16] --> #182 [17:02:18] --> #183 [17:02:26] to go back, we again use 'checkout' [17:02:32] --> #184 [17:02:34] --> #185 [17:02:47] so, 'git branch' shows us we are now in the 'master' branch; [17:02:53] --> #186 [17:02:53] <-- akuscifi007 (n=akuscifi@122.162.82.58) has quit (Read error: 104 (Connection reset by peer)) [17:03:09] I am now in the priyaaanka-chopra branch; [17:03:15] --> #187 [17:03:19] --> #188 [17:03:32] I am making some changes to to-my-dearest.txt and I am committing it; [17:03:38] --> #189 [17:03:45] --> #190 [17:03:48] --> #191 [17:04:00] so, now you see that we have HEAD and priyaaanka-chopra ; [17:04:08] our commit (latest) is a63ae26... [17:04:17] there is only one file in the working directory; [17:04:36] if I switch to the master branch, there will be HEAD and master for the master branch with only 958d5ac... [17:04:41] --> #192 [17:04:49] --> #193 [17:04:58] --> #194 [17:05:17] Now, I feel that priyaaanka-chopra changes are very good, and I can use it in 'master' copy [17:05:32] so I simply merge the changes from the priyaaanka-chopra branch to the master copy; [17:05:37] --> #195 [17:05:43] --> #196 [17:05:47] --> #197 [17:06:01] so now we have the latest commit message on the master branch; [17:06:19] this use case is to show that if you decide to work on a bug or a new feature in your code, you always make a copy of it in the branch [17:06:35] you work in the branch, test it, and if satisfactory you merge it back to the master copy [17:06:36] ! [17:06:43] if you are not satisfied with the branch, you can always delete it! [17:07:07] this is very important, unlike, newbies hacking on the same code, again, and again, and again, without being able to revert changes quickly and correctly; [17:07:09] hermes: shoot! [17:07:54] mbuf : Added very sweet is the name given to the commit operation right? It had nothing to do with the changes that we actually make to out txt file [17:07:56] right [17:08:01] ? [17:08:02] eof [17:08:30] Sorry our text file [17:08:33] ef [17:08:33] hermes: that is correct! it is the commit message like, 'git commit -a -m 'Added very sweet'' [17:08:35] eof [17:09:01] --> kopecks89 (n=koyel@117.201.96.138) has joined #dgplug [17:09:09] hermes: as I told earlier, this is not about what you write in the love letter; it is only about managing love letters :) [17:09:19] hermes: eof [17:09:28] ! [17:09:36] sunny_slls: shoot! [17:10:09] suppose there are many other branches and we wan't to merge some of them then how can we do that [17:10:13] there has been no conflict here; but, git tries to do its best to merge things; if there is a conflict, you need to resolve it manually, add the file again to index and commit it to the repo; [17:10:19] in the master? [17:10:25] sunny_slls: merge one by one; [17:10:50] sunny_slls: git merge foo; git merge bar; git merge alpha; git merge beta; [17:11:04] thanks [17:11:06] eof [17:11:21] sunny_slls: I am only describing the basic work mechanism of git; it doesn't define how your project workflow should be; that is something that your team must decide; [17:11:26] --> #198 [17:11:49] usually, you will get the source code from upstream (like from sourceforge.net, or freshmeat.net) and you will work on your local copy; [17:12:20] so, here, I am simply simulating an upstream update, by manually doing a commit in the master branch -- as if it came from the upstream project; [17:12:25] --> #199 [17:12:29] --> #200 [17:12:46] note the commits in the master, the latest one being 19e0205... [17:12:48] --> #201 [17:12:58] --> #202 [17:13:02] --> #203 [17:13:08] --> #204 [17:13:14] --> #205 [17:13:20] Now, I am checking out priyaaanka-chopra branch; [17:13:22] --> #206 [17:13:29] --> #207 [17:13:33] --> #208 [17:13:38] --> #209 [17:13:40] --> #210 [17:13:56] you see the different commit history between the master and the priyaaanka-chopra branch; [17:14:11] the master branch has had one commit more than the priyaaanka-chopra branch; [17:14:14] --> #211 [17:14:25] Now I am making some changes to priyaaanka-chopra branch; [17:14:32] --> #212 [17:14:38] --> #213 [17:15:15] Note the new commit is 1d1fd9f... which is different from the master (19e0205...) [17:15:23] --> #214 [17:15:42] Now I could merge the changes (upstream) on the master with the priyaaanka-chopra branch changes; [17:16:16] but, we have what is called as 'rebase' which basically overwrites our previous changes and merges the changes in the priyaaanka-chopra branch, as we do it next; [17:16:16] --> #215 [17:16:41] because of conflict, 'rebase' failed; [17:16:44] --> #216 [17:17:37] so that is the conflict in the to-my-dearest.txt between the master and the priyaaanka-chopra branch; we edit it to choose either one above or below the ====== [17:17:44] Remove the <<<<, >>>> lines; [17:17:49] --> #217 [17:17:58] --> #218 [17:18:08] --> #219 [17:18:13] --> #220 [17:18:27] Just checking git gl and since the file has been modified, we need to add it to index before committing; [17:18:30] --> #221 [17:18:53] since we have fixed the conflict, we can ask 'git rebase' to skip the conflict and proceed to merge; [17:18:55] --> #222 [17:19:01] --> #223 [17:19:05] --> #224 [17:19:21] master changes have been merged to priyaaanka-chopra branch [17:19:25] --> #225 [17:19:39] But, most importantly note that it has overwritten our previous commit log; [17:19:58] Sometimes when we are working in our branch copy, we will make many commits; [17:20:17] When we want to synchronize our code base with an upstream project, we fetch the code from the upstream project repository; [17:20:26] and we need to merge it with our local copy; [17:20:50] so, we may not want to keep a history of our local changes; simply merge it with our changes, as long as our changes are there in code; [17:20:58] so rebase basically rewrites history! [17:21:05] --> #226 [17:21:12] --> #227 [17:21:43] so we have covered most use cases; to get a copy of a project repository in a server, you basically 'clone' a copy of the repository; [17:21:48] so you get the complete history; [17:21:54] --> #228 [17:21:59] --> #229 [17:22:21] If you already have cloned a repo, and you only want to get the upstream changes, just use fetch [17:22:27] --> #230 [17:22:42] fetch will only download the upstream changes to the local system; it will not merge it with the master code; [17:22:47] pull will fetch+merge [17:22:51] --> #231 [17:23:05] git provides different ways to download code from remote repos; [17:23:07] --> #232 [17:23:18] --> #233 [17:23:22] --> #234 [17:23:25] --> #235 [17:23:36] git remote shows that the remote repo also has a 'origin' [17:23:40] is a reference link [17:23:43] --> #236 [17:23:53] --> #237 [17:23:56] --> #238 [17:23:57] <-- kopecks (n=koyel@117.201.100.101) has quit (Read error: 110 (Connection timed out)) [17:24:11] branch only shows local branches; git branch -r shows remote branches [17:24:15] --> #239 [17:24:29] so in the remote repo also, we have a origin/HEAD and origin/master [17:24:33] --> #240 [17:24:54] you can add remote repository instance to your local .git/ to get updates; [17:25:07] you will learn these as you work between local and remote repos; [17:25:14] this ends the presentation; [17:25:30] I know I haven't covered many use cases, but, I feel these are basic ones that should help you get started with using git; [17:25:48] gitorious.org provides nice git commands on doing fetches, updates, and merges, which I like;