{"thread":{"id":"22922","subject":"a few beginner git questions","startedAt":"2010-03-06T06:42:40Z","lastAt":"2010-03-08T18:55:05Z","messageCount":9,"participants":["Thomas Anderson","Allan Wind","Tait","Junio C Hamano","Dmitry Potapov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136228","messageId":"15b345f1003052242r7d812fe4q6ade253283696304@mail.gmail.com","threadId":"22922","inReplyTo":null,"subject":"a few beginner git questions","fromName":"Thomas Anderson","fromEmail":"zelnaga@gmail.com","sentAt":"2010-03-06T06:42:40Z","receivedAt":"2010-03-06T06:42:40Z","isPatch":false,"sender":{"key":"zelnaga@gmail.com","avatar":null},"body":"A few questions.\n\n1. When do you commit changes and when do you stage changes? Or maybe\nmore to the point, what's the difference between doing \"stage, commit,\nstage, commit\" and \"stage, stage, commit\"?\n\n2. What's the difference between merging and pushing? In CVS, you\nmerge code by manually adding changes. ie. the CVS client doesn't do\nthe merging - you do. Yet in Git Gui, there's a Merge menu button, as\nif it's now supposed to be somehow automated?\n\n3. Creating branches in Git Gui is easy enough but it's unclear to me\nhow to switch back to the trunk once you've created a branch.\n\n4. I clone git://github.com/symfony/symfony.git to c:\\git\\test\\root\nand clone that to c:\\git\\test\\clone. I then blank\nc:\\git\\test\\clone\\README, stage it, commit it and push it and the\nchange does not appear in c:\\git\\test\\root\\README. I then reopen Git\nGui and open root and there I see the blanked README as an uncommited\nstate change. I commit it and the change still does not appear in\nc:\\git\\test\\root\\README. Is this what Git should be doing?\n"},{"id":"136229","messageId":"20100306070150.GB14424@lifeintegrity.com","threadId":"22922","inReplyTo":"15b345f1003052242r7d812fe4q6ade253283696304@mail.gmail.com","subject":"Re: a few beginner git questions","fromName":"Allan Wind","fromEmail":"allan_wind@lifeintegrity.com","sentAt":"2010-03-06T07:01:50Z","receivedAt":"2010-03-06T07:01:50Z","isPatch":false,"sender":{"key":"allan_wind@lifeintegrity.com","avatar":null},"body":"On 2010-03-06T00:42:40, Thomas Anderson wrote:\n> 1. When do you commit changes and when do you stage changes? Or maybe\n> more to the point, what's the difference between doing \"stage, commit,\n> stage, commit\" and \"stage, stage, commit\"?\n\nThe former gives you one commit and the latter two comments. \nStaging (git add) is local while commits can shared with others \n(git push).\n\n> 2. What's the difference between merging and pushing? In CVS, you\n> merge code by manually adding changes. ie. the CVS client doesn't do\n> the merging - you do. Yet in Git Gui, there's a Merge menu button, as\n> if it's now supposed to be somehow automated?\n\npushing is how you copy the data to another repository while \nmerging is integrating multiple versions in into a single new \nversion.\n\n> 3. Creating branches in Git Gui is easy enough but it's unclear to me\n> how to switch back to the trunk once you've created a branch.\n\ngit checkout master (which is the default name for \"trunk\")\n\n\n\n> 4. I clone git://github.com/symfony/symfony.git to c:\\git\\test\\root\n> and clone that to c:\\git\\test\\clone. I then blank\n> c:\\git\\test\\clone\\README, stage it, commit it and push it and the\n> change does not appear in c:\\git\\test\\root\\README. I then reopen Git\n> Gui and open root and there I see the blanked README as an uncommited\n> state change. I commit it and the change still does not appear in\n> c:\\git\\test\\root\\README. Is this what Git should be doing?\n\n\n\n\n/allan\n-- \nAllan Wind\nLife Integrity, LLC\n\n"},{"id":"136231","messageId":"20100306070533.GL2480@ece.pdx.edu","threadId":"22922","inReplyTo":"15b345f1003052242r7d812fe4q6ade253283696304@mail.gmail.com","subject":"Re: a few beginner git questions","fromName":"Tait","fromEmail":"git.git@t41t.com","sentAt":"2010-03-06T07:05:33Z","receivedAt":"2010-03-06T07:05:33Z","isPatch":false,"sender":{"key":"git.git@t41t.com","avatar":null},"body":"> 1. When do you commit changes and when do you stage changes? Or maybe\n> more to the point, what's the difference between doing \"stage, commit,\n> stage, commit\" and \"stage, stage, commit\"?\n\nStaging changes is a prerequisite to committing them. With stage, commit,\nstage, commit you will have two commits in history. With stage, stage,\ncommit you will have only one commit in history. What you stage (or\nneglect to stage) is not part of recorded history in the repository. What\nyou commit, is.\n\n> 2. What's the difference between merging and pushing? In CVS, you\n> merge code by manually adding changes. ie. the CVS client doesn't do\n> the merging - you do. Yet in Git Gui, there's a Merge menu button, as\n> if it's now supposed to be somehow automated?\n\nMerging is (sort-of) like merging in CVS. You are taking two separate lines\n(branches) on the history graph and combining them together. Unlike CVS,\ngit keeps a record of the merge.\n\nPush is simply copying changes in your local repository to another\nrepository. What configuration you've set and what arguments you give\nto push control what gets copied.\n\n> 3. Creating branches in Git Gui is easy enough but it's unclear to me\n> how to switch back to the trunk once you've created a branch.\n\nThis depends on what you mean by \"switch back\". You can change the target\nof your commits by using \"git checkout\".\n\t> git checkout master\n\t# Now new commits get added to the tip of master\n\t> git checkout -b newbranch\n\t# Now you created a new branch, \"newbranch\"\n\t# And you switched to it, so new commits are added\n\t# to newbranch instead of master\n\t> git checkout master\n\t# Now you're back on branch master and your commits\n\t# to newbranch aren't visible\n\t> git checkout newbranch\n\t# Back to newbranch again\n\nIf you meant \"switch back\" like \"this branch is done, I'm going to stop\nworking on it\" then you can merge it back into master or some other branch,\nor leave it unmerged. Then you may wish to leave it rot or delete it,\nperhaps depending on whether you think you'll ever revisit that branch\nin the future (to fix a bug, maybe).\n\n> 4. I clone git://github.com/symfony/symfony.git to c:\\git\\test\\root\n> and clone that to c:\\git\\test\\clone.\tI then blank\n> c:\\git\\test\\clone\\README, stage it, commit it and push it and the\n> change does not appear in c:\\git\\test\\root\\README. I then reopen Git\n> Gui and open root and there I see the blanked README as an uncommited\n> state change. I commit it and the change still does not appear in\n> c:\\git\\test\\root\\README. Is this what Git should be doing?\n\nYou shouldn't push into a non-bare repository (unless you know what you're\ndoing and really mean it). This:\n\thttp://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F\nexplains a bit more on the subject.\n\nTait\n"},{"id":"136258","messageId":"15b345f1003061823u2d7edeeo25229f0a32456f45@mail.gmail.com","threadId":"22922","inReplyTo":"20100306070533.GL2480@ece.pdx.edu","subject":"Re: a few beginner git questions","fromName":"Thomas Anderson","fromEmail":"zelnaga@gmail.com","sentAt":"2010-03-07T02:23:18Z","receivedAt":"2010-03-07T02:23:18Z","isPatch":false,"sender":{"key":"zelnaga@gmail.com","avatar":null},"body":"On Sat, Mar 6, 2010 at 1:05 AM, Tait wrote:\n>> 1. When do you commit changes and when do you stage changes?  Or maybe\n>> more to the point, what's the difference between doing \"stage, commit,\n>> stage, commit\" and \"stage, stage, commit\"?\n>\n> Staging changes is a prerequisite to committing them. With stage, commit,\n> stage, commit you will have two commits in history. With stage, stage,\n> commit you will have only one commit in history. What you stage (or\n> neglect to stage) is not part of recorded history in the repository. What\n> you commit, is.\n\nWhat's the difference, then, between doing \"stage, stage, commit\" as\nopposed to \"stage, commit\"? Why not just make all commits stage\nautomatically?\n"},{"id":"136286","messageId":"15b345f1003062102l22ac2d2fn3ed5b73221bf4216@mail.gmail.com","threadId":"22922","inReplyTo":"20100306070533.GL2480@ece.pdx.edu","subject":"Re: a few beginner git questions","fromName":"Thomas Anderson","fromEmail":"zelnaga@gmail.com","sentAt":"2010-03-07T05:02:20Z","receivedAt":"2010-03-07T05:02:20Z","isPatch":false,"sender":{"key":"zelnaga@gmail.com","avatar":null},"body":"On Sat, Mar 6, 2010 at 1:05 AM, Tait wrote:\n>> 4. I clone git://github.com/symfony/symfony.git to c:\\git\\test\\root\n>> and clone that to c:\\git\\test\\clone.  I then blank\n>> c:\\git\\test\\clone\\README, stage it, commit it and push it and the\n>> change does not appear in c:\\git\\test\\root\\README.  I then reopen Git\n>> Gui and open root and there I see the blanked README as an uncommited\n>> state change.  I commit it and the change still does not appear in\n>> c:\\git\\test\\root\\README.  Is this what Git should be doing?\n>\n> You shouldn't push into a non-bare repository (unless you know what you're\n> doing and really mean it). This:\n>        http://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F\n> explains a bit more on the subject.\n\nHow, then, do I update code? ie. I perform my initial clone, make\nsome changes and commit / push them. Someone else then comes along,\nmakes some changes and commits them. The next day, I do Remote ->\nFetch from -> origin to update my code to the latest in Git but\nc:\\git\\test\\clone\\README is exactly the same as it was before. How do\nI update the initial clone such that I can edit the updated files?\n"},{"id":"136297","messageId":"20100307085002.GA31105@dpotapov.dyndns.org","threadId":"22922","inReplyTo":"15b345f1003062102l22ac2d2fn3ed5b73221bf4216@mail.gmail.com","subject":"Re: a few beginner git questions","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-03-07T08:50:02Z","receivedAt":"2010-03-07T08:50:02Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, Mar 06, 2010 at 11:02:20PM -0600, Thomas Anderson wrote:\n> \n> How, then, do I update code? ie. I perform my initial clone, make\n> some changes and commit / push them. Someone else then comes along,\n> makes some changes and commits them. The next day, I do Remote ->\n> Fetch from -> origin to update my code to the latest in Git but\n> c:\\git\\test\\clone\\README is exactly the same as it was before. How do\n> I update the initial clone such that I can edit the updated files?\n\nThere are a few ways to do that. It depends on what you actually wants.\n\nFirst of all, you can merge 'origin/master' (or whatever its name).\nIf you do not have any local commit then merge will just fast-forward\nyour branch to the same point. However, if you do have changes, then\nit will create a new merge commit. If you have many such merge commits,\nit can make the upstream unhappy, because your changes are intervene\nwith merges, so it is more difficult to inspect your actual changes.\n\nAnother option is to rebase your changes on top of the 'origin/master'.\nRebasing your changes on top origin/master is more close to what happens\nwhen you do 'cvs update' does, except that in git you rebase committed\nchanges, so if something goes wrong during this process, you can abort\nand redo it again. So, all your work will not be lost. The advantage of\n'rebase' is that you have a clean and linear history. The disadvantage\nis that you re-write all your commits, so you should not do that on\n\"published\" history. Also, re-writing may introduce a problem even if\nrebased had no conflict. While merge may also produced a non-working\nresult, 'merge' preserves the original history while rebase produces a\nnew one, which is not tested. So, I would not recommend to rebase any\nlong series of patches or anything non-trivial unless it is absolutely\nnecessary.\n\nFinally, a typical workflow with Git is to use feature branches. You\ncreate a new branch to implement some feature, do all your work on it\n(without any \"update\") and then merge it to the upstream (either you\nmerge and push the result or send a pull request to the maintainer).\nAfter your changes have been merged, you just delete this branch. For\neach new work, you start a new branch from the current origin/master.\n\n\nDmitry\n"},{"id":"136306","messageId":"20100307090834.GB31105@dpotapov.dyndns.org","threadId":"22922","inReplyTo":"15b345f1003061823u2d7edeeo25229f0a32456f45@mail.gmail.com","subject":"Re: a few beginner git questions","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-03-07T09:08:34Z","receivedAt":"2010-03-07T09:08:34Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, Mar 06, 2010 at 08:23:18PM -0600, Thomas Anderson wrote:\n> \n> What's the difference, then, between doing \"stage, stage, commit\" as\n> opposed to \"stage, commit\"?\n\nProbably none... If you stage twice the exactly same file, it does not\nchange anything. But if you \"stage, stage\" means to stage two different\nfiles while \"stage\" is to stage just one then the outcome will be\ndifferent.\n\n> Why not just make all commits stage automatically?\n\nThe goal of the stage area is to mark what changes you want to commit.\nSo, one commit will contain only one semantic change and not everything\nwhat you have in your working tree at that moment. CVS also allows to\nnot commit all changes at the same time (you can specify what files to\ncommit in the command line), but with Git you can not only to choose\nwhat files but also what change in each file you want to commit now.\nMore importantly, git allows you to look at the stage area and see what\nyou are going to commit.\n\nIn simple cases, you can just do \"git commit -a\" which means to commit\nall changes for all tracked files or \"git commit somefile\" to commit\nchanges only in \"somefile\".\n\n\nDmitry\n"},{"id":"136242","messageId":"7vd3zgxyfw.fsf@alter.siamese.dyndns.org","threadId":"22922","inReplyTo":"15b345f1003052242r7d812fe4q6ade253283696304@mail.gmail.com","subject":"Re: a few beginner git questions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-07T09:39:47Z","receivedAt":"2010-03-07T09:39:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Anderson writes:\n\n> 1. When do you commit changes and when do you stage changes? Or maybe\n> more to the point, what's the difference between doing \"stage, commit,\n> stage, commit\" and \"stage, stage, commit\"?\n\n\"git add file\" is a way to let you say \"I have examined the changes since\nthe last commit to this file, and I do not want to see them in the output\nfrom my later invocations of 'git diff'\". The intent is to let you focus\non one detail without getting distracted by other changes.\n\nSo typically you repeat the following steps:\n\n - change your files in the working tree;\n - run 'git diff' to check your progress _incrementally_; and\n - run 'git add that-file' to mark that the changes so far is satisfactory.\n\n\"add then commit\" would be just running the above cycle once between\ncommits. \"add, add then commit\" would be running the cycle twice.\n\nThis doesn't help you very much when you are always making small commits.\nYou might never encounter a case where you need to do more than one cycle\nof the above before creating a commit. But in real-life, the extent of\nchanges that need to be contained in a single logically independent unit\nyou would want to record as a commit is sometimes large enough that it\nhelps to be able to work incrementally. Also often people keep small\nchanges that they do not want to commit yet in their working tree (and of\ncourse they never say \"git add\" on them until they are ready). If you are\ninterested, you can read more on this:\n\n http://thread.gmane.org/gmane.comp.version-control.git/15148/focus=15476\n\nOther times, you can always do \"commit -a\".\n\nAlso, all of the above doesn't really matter in projects that tolerate\nincoherent and/or unfocused commits, as they do not care how well you\nchoose commit boundaries.\n"},{"id":"136401","messageId":"20100308185505.GP2480@ece.pdx.edu","threadId":"22922","inReplyTo":"15b345f1003062102l22ac2d2fn3ed5b73221bf4216@mail.gmail.com","subject":"Re: a few beginner git questions","fromName":"Tait","fromEmail":"git.git@t41t.com","sentAt":"2010-03-08T18:55:05Z","receivedAt":"2010-03-08T18:55:05Z","isPatch":false,"sender":{"key":"git.git@t41t.com","avatar":null},"body":"> How, then, do I update code? ie. I perform my initial clone, make\n> some changes and commit / push them. Someone else then comes along,\n> makes some changes and commits them. The next day, I do Remote ->\n> Fetch from -> origin to update my code to the latest in Git but\n> c:\\git\\test\\clone\\README is exactly the same as it was before. How do\n> I update the initial clone such that I can edit the updated files?\n\nAs Dmitry already said, you can either merge in the upstream changes,\nor rebase your own changes on top of the upstream changes. I usually\nrebase.\n\nHere's my typical workflow. It may not be elegant, but it works well\nfor me. Hopefully it's useful for you, because understanding workflow\nwas one of the most intimidating parts of learning git for me.\n\ngit pull # equivalent of git fetch + git merge\n # ... my local master is always clean; this is a fast-forward\ngit checkout -b exp_smoothing \n # create a new branch to work\nvi # start making my intended changes\ngit add # stage my changes\nvi # make some more changes I don't want to commit, like enabling \n # debug, bypassing some uninteresting code, etc.\ngcc # oops, there were syntax errors\nvi\ngit add # to stage just the relevant fixes (or git add -p)\ngit commit # save my progress\nrun # discover some things to fix\n... # repeat the bit from gcc to here many times over\nrun # It works .. maybe it's a few days since I started\n # By now, my history is an ugly mess\ngit rebase -i exp_smoothing^\n # I re-order, combine, and split commits\n # When I'm done, the history is neat and logical\ngit checkout master\n # switch back to master (which is still clean)\ngit pull origin\n # get any updates from the last couple days\n # there will be no conflicts; it's a fast-forward\n\nMy history looks like this:\n\n exp_smoothing branch\n |-- a <-- b <-- c <-- d\n v\nmaster: Z <-- Y <-- X <-- W <-- V\n\nBefore switching back to master and doing pull, I only knew about Z\nand Y, and in my own local repository, I added a, b, c, d, which are\nthe cleaned-up version of my exp_smoothing development. When I did\na git pull, I incorporated X, W, and V.\n\nPicking up with the workflow again...\n\ngit checkout exp_smoothing\n # back to my work-in-progress branch\ngit rebase master\n # replay exp_smoothing on top of the new master (now \n # at V instead of Y)\n # resolve conflicts, if X, W, V conflict with a, b, c, d\n\nHistory is now:\n exp_smoothing branch\n |-- a' <-- b' <-- c' <-- d'\nmaster: v\nZ <-- Y <-- X <-- W <-- V\n\ngit checkout master\ngit merge exp_smoothing\n # because I resolved all the conflicts during the rebase\n # this should merge conflict-free, as a fast-forward.\ngit push origin\n # publish my changes (to master) for the rest of the world\ngit branch -d exp_smoothing\n # exp_smoothing is merged into master; no need to keep it \n # around anymore\n\nThe last four steps occur very quickly. The final history is:\n\nmaster: Z <-- Y <-- X <-- W <-- V <-- a' <-- b' <-- c' <-- d'\n\nGiven my workflow, why branch at all? Sometimes I may be working\non more than one branch at a time, or I may get interrupted on\nexp_smoothing development to make a regression fix to master, or\nmaybe I discover that I don't want to merge exp_smoothing until the\nnext major version release. It's just easier to manage as a separate\nbranch up until the last four or six steps. I can rebase exp_smoothing\non top of master over and over again until I finally merge and publish\nit.\n\nTait\n"}]}