{"thread":{"id":"9678","subject":"new to git","startedAt":"2007-08-27T19:43:47Z","lastAt":"2007-09-05T06:54:31Z","messageCount":8,"participants":["Kyle Rose","J. Bruce Fields","Andreas Ericsson","Junio C Hamano","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51744","messageId":"46D32973.8030104@krose.org","threadId":"9678","inReplyTo":null,"subject":"new to git","fromName":"Kyle Rose","fromEmail":"krose@krose.org","sentAt":"2007-08-27T19:43:47Z","receivedAt":"2007-08-27T19:43:47Z","isPatch":false,"sender":{"key":"krose@krose.org","avatar":"https://gravatar.com/avatar/4e79b8d8d1ed762bf6d7c6bb575aa8a8b270948788d0d572f62ab2e90149026c?d=mp&s=160"},"body":"After many years of dissatisfaction with the limitations of CVS, and\nafter getting fed up with the complexity of configuring and maintaining\na SVN setup, I just started using git for my own personal projects.  I\nhave to say it's quite nice and fits the UNIX philosophy well: fast,\nsimple, powerful.\n\nI've been playing with it for a few weeks and generally understand what\nis going on, but I do have a few usage questions that I couldn't find\nanswered in the docs:\n\n(1) Let's say I:\n\ngit clone something\ngit branch foo\ngit checkout foo\n<make some changes>\ngit commit -a\ngit checkout master\ngit pull . foo\ngit push\ngit pull\n\nwhat is actually happening?  The pull appears to do something (i.e., I get:\n\n* refs/remotes/origin/master: fast forward to branch 'master' of\n/home/krose/git-repository/baz/\n  old..new: 7cf088c..d344f98\n\n), but makes no changes locally since I have the latest revision. \nAnother subsequent git pull does, in fact, say everything is up to date.\n\n(2) Any way to disable this warning:\n\nWarning: No merge candidate found because value of config option\n         \"branch.local.merge\" does not match any remote branch fetched.\n\n(3) I notice I can't reset --hard a single file.  So, if I want to\nrevert a single file to some revision, blowing away my changes, what is\nthe accepted way of doing this?  Is there a way to do the equivalent of\na p4 print foo@some_revision?\n\n(4) I'm still not clear on when a dst should and should not be used in a\nrefspec.  It appears that one can only do non-fast forward updates to\nthe branch that is checked out (which makes sense, since you may need to\nresolve), but other than that, what is the difference between\n\ngit checkout foo\ngit pull . master\n\nand\n\ngit checkout master\ngit push . master:foo\n\n?\n\n(5) Are there any tools for managing some of the metadata (e.g., the\norigin URL) or is it expected that one edit it directly?\n\nThanks for all your work on this: git fills a need I didn't know I had\nuntil I actually found myself using it: a completely decentralized patch\nmanagement system.\n\nKyle\n"},{"id":"51746","messageId":"20070827201131.GK3118@fieldses.org","threadId":"9678","inReplyTo":"46D32973.8030104@krose.org","subject":"Re: new to git","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-08-27T20:11:31Z","receivedAt":"2007-08-27T20:11:31Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Aug 27, 2007 at 03:43:47PM -0400, Kyle Rose wrote:\n> I've been playing with it for a few weeks and generally understand what\n> is going on, but I do have a few usage questions that I couldn't find\n> answered in the docs:\n\nI think I tried to cover most of this in the user-manual\n(http://www.kernel.org/pub/software/scm/git/docs/user-manual.html has\nthe latest version, or it's in Documentation/) but some of it may be\nharder to find than it should be.\n\n> (1) Let's say I:\n> \n> git clone something\n> git branch foo\n> git checkout foo\n> <make some changes>\n> git commit -a\n> git checkout master\n> git pull . foo\n> git push\n> git pull\n> \n> what is actually happening?  The pull appears to do something (i.e., I get:\n> \n> * refs/remotes/origin/master: fast forward to branch 'master' of\n> /home/krose/git-repository/baz/\n>   old..new: 7cf088c..d344f98\n\nGit caches the value of the remote's \"master\" in\nrefs/remotes/origin/master.  That's the thing that's getting updated;\nyou can actually\n\n\tcat .git/refs/remotes/origin/master\n\nbefore and after you'll see that it got updated from 7cf088c to d344498.\n\nI think newer versions of git actually update that \"remote-tracking\nbranch head\" on the push as well, which would prevent you from getting\nthe message since by the time of the pull that thing will already have\nbeen updated.\n\n> (3) I notice I can't reset --hard a single file.  So, if I want to\n> revert a single file to some revision, blowing away my changes, what is\n> the accepted way of doing this?\n\n\tgit checkout some_revision path/to/filename\n\n> Is there a way to do the equivalent of\n> a p4 print foo@some_revision?\n\nI don't know p4, but maybe you're looking for\n\n\tgit show some_revision:foo\n\n> (4) I'm still not clear on when a dst should and should not be used in a\n> refspec.  It appears that one can only do non-fast forward updates to\n> the branch that is checked out (which makes sense, since you may need to\n> resolve), but other than that, what is the difference between\n> \n> git checkout foo\n> git pull . master\n> \n> and\n> \n> git checkout master\n> git push . master:foo\n\nThe latter should forcibly reset the branch head \"foo\" to point at the\nsame commit as \"master\".  The former tries to do a merge between the\ntwo.\n\nIn the case where master is a descendant of foo (so there's no commits\nin foo that isn't already in master), the two should do the same thing.\n\n> (5) Are there any tools for managing some of the metadata (e.g., the\n> origin URL) or is it expected that one edit it directly?\n\nMaybe you want \"man git-remote\"?  Or see \"git-config\" for more general\nconfiguration.\n\nBut editing .git/config file directly is often simplest, and won't cause\nany problem.\n\n--b.\n"},{"id":"51747","messageId":"46D33290.20405@op5.se","threadId":"9678","inReplyTo":"46D32973.8030104@krose.org","subject":"Re: new to git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-08-27T20:22:40Z","receivedAt":"2007-08-27T20:22:40Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"First of all, welcome to git :)\n\nHaving been away from the mailing list for too long, I can't answer all\nyour questions. I'll take a stab at the ones I've got a clue about though.\n\nI also recommend that you upgrade your git installation to at least 1.5.3,\nas most of the people figuring on this list will most likely give advice\nthat matches that version.\n\nFor reference, the git documentation can be found at\nhttp://www.kernel.org/pub/software/scm/git/docs/\n\nJ. Bruce Fields et al have written some really excellent introductory\ndocuments which are a must to anyone who wishes to flatten the initial\nlearning curve a bit.\n\nKyle Rose wrote:\n> After many years of dissatisfaction with the limitations of CVS, and\n> after getting fed up with the complexity of configuring and maintaining\n> a SVN setup, I just started using git for my own personal projects.  I\n> have to say it's quite nice and fits the UNIX philosophy well: fast,\n> simple, powerful.\n> \n> I've been playing with it for a few weeks and generally understand what\n> is going on, but I do have a few usage questions that I couldn't find\n> answered in the docs:\n> \n> (1) Let's say I:\n> \n> git clone something\n> git branch foo\n> git checkout foo\n> <make some changes>\n> git commit -a\n> git checkout master\n> git pull . foo\n> git push\n> git pull\n> \n> what is actually happening?  The pull appears to do something (i.e., I get:\n> \n\ngit pull = git fetch + git merge. The notation you use above is obsoleted\nand no longer works in git 1.5.3. Instead you'd have to replace\n\n\tgit pull . foo\n\nwith\n\n\tgit merge foo\n\nwhich will most likely clear up some confusion.\n\n> * refs/remotes/origin/master: fast forward to branch 'master' of\n> /home/krose/git-repository/baz/\n>   old..new: 7cf088c..d344f98\n> \n> ), but makes no changes locally since I have the latest revision. \n> Another subsequent git pull does, in fact, say everything is up to date.\n> \n\nIt should have made changes to your local tree, namely the ones you added\nto branch foo that weren't in master before you merged.\n\nThe fact that it turned out to be a fast forward only means that you had\nno additional commits on top of master, so the history in foo could be\napplied on top of master without any file-level merging taking place.\n\n> (2) Any way to disable this warning:\n> \n> Warning: No merge candidate found because value of config option\n>          \"branch.local.merge\" does not match any remote branch fetched.\n> \n\nYes. Edit your .git/config file to add a merge candidate for your local\nbranch.\n\n> (3) I notice I can't reset --hard a single file.  So, if I want to\n> revert a single file to some revision, blowing away my changes, what is\n> the accepted way of doing this?  Is there a way to do the equivalent of\n> a p4 print foo@some_revision?\n> \n\n\tgit checkout treeish path/to/file\n\naccording to the man-page at least. \"treeish\" here can be substituted\nfor a revision, which in git is represented by a 40 byte SHA1 hash, but\nalso has a lot of short-hand options. See \"git help rev-list\" for more\ninfo on that.\n\n> (4) I'm still not clear on when a dst should and should not be used in a\n> refspec.  It appears that one can only do non-fast forward updates to\n> the branch that is checked out (which makes sense, since you may need to\n> resolve), but other than that, what is the difference between\n> \n> git checkout foo\n> git pull . master\n> \n> and\n> \n> git checkout master\n> git push . master:foo\n> \n> ?\n> \n\nHere I'm clueless, except that this matches old syntax which is no longer\nvalid. I'd recommend you to upgrade to 1.5.3 so that you get to use\ngit-merge for local merges. The \"use push/pull for merging\" has caused\nenough confusion, I think.\n\n> (5) Are there any tools for managing some of the metadata (e.g., the\n> origin URL) or is it expected that one edit it directly?\n> \n\nSee the git-remote man page. It's available online if you don't have it.\n\n> Thanks for all your work on this: git fills a need I didn't know I had\n> until I actually found myself using it: a completely decentralized patch\n> management system.\n> \n\nIt's more than that, but many of us share your feeling about it filling\na need we didn't know we had.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"51751","messageId":"46D335D2.2050408@krose.org","threadId":"9678","inReplyTo":"46D33290.20405@op5.se","subject":"Re: new to git","fromName":"Kyle Rose","fromEmail":"krose@krose.org","sentAt":"2007-08-27T20:36:34Z","receivedAt":"2007-08-27T20:36:34Z","isPatch":false,"sender":{"key":"krose@krose.org","avatar":"https://gravatar.com/avatar/4e79b8d8d1ed762bf6d7c6bb575aa8a8b270948788d0d572f62ab2e90149026c?d=mp&s=160"},"body":"Thanks for your help: your responses clear up a lot of things, and\ngetting to 1.5.3 will be a priority, though I will probably wait until\nit appears in the Ubuntu pool, which unfortunately it has not yet. \nDifferentiating merge and push as asymmetric operations (which pull and\npush do not imply, sounding symmetric) is a very good idea.\n\nFWIW, I cannot believe I hadn't found Mr. Fields' doc before this: it\nseems pretty thorough, so I will read it before posting any further\nquestions.\n\nThanks,\nKyle\n"},{"id":"51752","messageId":"7vabsczp94.fsf@gitster.siamese.dyndns.org","threadId":"9678","inReplyTo":"46D33290.20405@op5.se","subject":"Re: new to git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-27T20:39:03Z","receivedAt":"2007-08-27T20:39:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> git pull = git fetch + git merge. The notation you use above is obsoleted\n> and no longer works in git 1.5.3. Instead you'd have to replace\n>\n> \tgit pull . foo\n>\n> with\n>\n> \tgit merge foo\n>\n> which will most likely clear up some confusion.\n\nHuh?  \"git pull . foo\" has always been the same as \"git merge\nfoo\", I thought...  Have we broken anything?\n\n>> (2) Any way to disable this warning:\n>>\n>> Warning: No merge candidate found because value of config option\n>>          \"branch.local.merge\" does not match any remote branch fetched.\n>>\n>\n> Yes. Edit your .git/config file to add a merge candidate for your local\n> branch.\n\nOr, say what branch you get from the remote you want to merge\nexplicitly.  You may not always merge the same branch from the\nremote.  E.g.\n\n\t$ git pull origin experimental\n\t$ git pull origin master\n\n>> (4) I'm still not clear on when a dst should and should not be used in a\n>> refspec.  It appears that one can only do non-fast forward updates to\n>> the branch that is checked out (which makes sense, since you may need to\n>> resolve), but other than that, what is the difference between\n>>\n>> git checkout foo\n>> git pull . master\n>>\n>> and\n>>\n>> git checkout master\n>> git push . master:foo\n>>\n>> ?\n>>\n>\n> Here I'm clueless, except that this matches old syntax which is no longer\n> valid.\n\nHuh again about \"no longer valid\" part.\n\nIn any case, the former says \"I am on foo branch, and I want to\nmerge 'master' from _MY_ local repository\".  The latter says \"I\nwant to update the local branch 'foo' with what is in my\n'master' branch, both local\".  They are totally different.\n\nPlease do _not_ spread backward incompatibility FUD.\n"},{"id":"51758","messageId":"46D33E9C.8000000@op5.se","threadId":"9678","inReplyTo":"7vabsczp94.fsf@gitster.siamese.dyndns.org","subject":"Re: new to git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-08-27T21:14:04Z","receivedAt":"2007-08-27T21:14:04Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson <ae@op5.se> writes:\n> \n>> git pull = git fetch + git merge. The notation you use above is obsoleted\n>> and no longer works in git 1.5.3. Instead you'd have to replace\n>>\n>> \tgit pull . foo\n>>\n>> with\n>>\n>> \tgit merge foo\n>>\n>> which will most likely clear up some confusion.\n> \n> Huh?  \"git pull . foo\" has always been the same as \"git merge\n> foo\", I thought...  Have we broken anything?\n> \n\nPossibly. I noticed some weeks ago that \"pull . branch\" no longer\nworked and used merge instead. I shrugged it off as being of no\nmoment, and can't recall if there were any real reasons for\nthe merge to fail.\n\n>>>\n>> Here I'm clueless, except that this matches old syntax which is no longer\n>> valid.\n> \n> Huh again about \"no longer valid\" part.\n> \n> In any case, the former says \"I am on foo branch, and I want to\n> merge 'master' from _MY_ local repository\".  The latter says \"I\n> want to update the local branch 'foo' with what is in my\n> 'master' branch, both local\".  They are totally different.\n> \n> Please do _not_ spread backward incompatibility FUD.\n\nMy apologies. I'll have to see if I can find what caused my own\nconfusion in the first place.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"52539","messageId":"20070905055659.GF3786@efreet.light.src","threadId":"9678","inReplyTo":"46D32973.8030104@krose.org","subject":"Re: new to git","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-05T05:56:59Z","receivedAt":"2007-09-05T05:56:59Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Aug 27, 2007 at 15:43:47 -0400, Kyle Rose wrote:\n> After many years of dissatisfaction with the limitations of CVS, and\n> after getting fed up with the complexity of configuring and maintaining\n> a SVN setup, I just started using git for my own personal projects.  I\n> have to say it's quite nice and fits the UNIX philosophy well: fast,\n> simple, powerful.\n> \n> I've been playing with it for a few weeks and generally understand what\n> is going on, but I do have a few usage questions that I couldn't find\n> answered in the docs:\n> \n> (1) Let's say I:\n> \n> git clone something\n> git branch foo\n> git checkout foo\n> <make some changes>\n> git commit -a\n> git checkout master\n> git pull . foo\n\ngit merge foo\n\nwould be probably both clearer about the intent and more efficient here.\nAfter all, pull is just a simple wrapper for fetch + merge and you don't need\nthe fetch from the repository to itself.\n\n> git push\n> git pull\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"52541","messageId":"7v7in5lhzs.fsf@gitster.siamese.dyndns.org","threadId":"9678","inReplyTo":"46D32973.8030104@krose.org","subject":"Re: new to git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-05T06:54:31Z","receivedAt":"2007-09-05T06:54:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"[jc: I think this is really worth saving somewhere.  Could some\nkind soul make this into a patch to have under Documentation/\nsomewhere?]\n\nKyle Rose <krose@krose.org> writes:\n\n> (1) Let's say I:\n>\n> git clone something\n\n  Origin repository's history is copied and you get their master\n  in remotes/origin/master (aka remotes/origin/HEAD aka\n  remotes/origin), and you can call that 'origin' for brevity.\n  At the same time, you get your own 'master' branch that points\n  at the same commit as the 'origin'.  Your current branch\n  pointed at by your HEAD is 'master'.\n\n     ['origin' repository]\n     ---A---B---C\n                ^master\n\n ==>\n\n     [your cloned repository]\n     ---A---B---C\n                ^master = HEAD\n                ^remotes/origin\n\n> git branch foo\n\n  You create a new branch of your own 'foo' in your repository,\n  initially pointing at the same commit as your current commit\n  (i.e. C as you are on 'master' after the clone).\n\n ==>\n\n     [your cloned repository]\n     ---A---B---C\n                ^master = HEAD\n                ^remotes/origin\n                ^foo\n\n> git checkout foo\n\n  You switch from your current branch (i.e. 'master') to the\n  named branch (i.e. 'foo'), making the latter the current\n  branch.  Your work tree will largely match the commit at the\n  tip of the branch you are switching to, except that if you had\n  any local changes (i.e. uncommitted) in your work tree, you\n  take it along (but in this example you do not have any).\n\n ==>\n\n     [your cloned repository]\n     ---A---B---C\n                ^master\n                ^remotes/origin\n                ^foo = HEAD\n\n> <make some changes>\n> git commit -a\n\n  You build a commit whose parent is the commit your HEAD used\n  to point at; the tip of your current branch advances.\n\n ==>\n\n     [your cloned repository]\n\n     ---A---B---C---D\n                    ^foo = HEAD\n                ^master\n                ^remotes/origin\n\n> git checkout master\n\n  You switch from your current branch (i.e. 'foo') to the\n  named branch (i.e. 'master'), making the latter the current\n  branch.  Your work tree will largely match the commit at the\n  tip of the branch you are switching to, except that if you had\n  any local changes (i.e. uncommitted) in your work tree, you\n  take it along (but in this example you do not have any).\n\n ==>\n\n     [your cloned repository]\n\n     ---A---B---C---D\n                    ^foo\n                ^master = HEAD\n                ^remotes/origin\n\n> git pull . foo\n\n  This \"git pull\" command instructs git to \"from the repository\n  '.', grab the commit the repository calls 'foo', and update my\n  current branch by merging that commit\".  Because '.' is \"the\n  current directory\", which in turn means \"my repository\", you\n  do not have to really \"grab the commit\" --- you already have\n  it locally.\n\n  \"git merge foo\" is more natural way to write this since 1.5.0\n  days.  The latter command instructs git \"update my current\n  branch by merging commit I call 'foo'\".\n\n  Now, looking at the above history graph, your current\n  branch'es tip is at C (you are on 'master', remember?), and\n  'foo' is at D, which is an descendant of C.  By definition, a\n  merge between such commit pair is the descendant D, so your\n  current branch is updated to D (this is called \"fast\n  forward\").\n\n ==>\n\n     [your cloned repository]\n\n     ---A---B---C---D\n                    ^foo\n                    ^master = HEAD\n                ^remotes/origin\n\n> git push\n\n  This is kind of \"lazy\" and \"very not-git-like\" command I\n  literally *hate*.  What \"git push\" does, whey you do not say\n  anything about \"where to\" nor \"what\", is to \"push all\n  corresponding branches and tags to the repository you call\n  'origin'\".\n\n  If you recall the very initial picture, the 'origin'\n  repository has 'master' branch but not 'foo'.  The only\n  matching branch is 'master', and that is pointing at C over\n  there, which is replaced by your 'master' which now points at\n  'D'.\n\n     ['origin' repository]\n     ---A---B---C\n                ^master\n\n ==>\n\n     ['origin' repository]\n     ---A---B---C---D\n                    ^master\n\n  Note that this update *MUST* be fast-forward by default.  IOW,\n  if somebody worked elsewhere and updated the 'master' branch\n  at the 'origin' repository before your push, your 'push' will\n  be prevented with an error message that tells you that remote\n  'master' is not a strict subset of what you are pushing.\n\n> git pull\n\n  Instruct git to \"grab the history from the 'origin' repository\n  and update remotes/origin/* with its branch, and then update my\n  current branch by merging its tip\".\n\n  The first step of updating the remotes/origin again *MUST* be\n  fast-forward by default.\n\n ==>\n\n     [your cloned repository]\n\n     ---A---B---C---D\n                    ^foo\n                    ^master = HEAD\n                    ^remotes/origin\n\n  If you recall, you are on 'master' branch whose tip is at D.\n  Now you are telling git to update it by merging what you\n  fetched, which also is D.  So nothing happens.\n\n> (2) Any way to disable this warning:\n>\n> Warning: No merge candidate found because value of config option\n>          \"branch.local.merge\" does not match any remote branch fetched.\n\nDo as the warning says; I do not think the message can be any\nclearer (see Documentation/config.txt, or even better \"The\nUser's Manual\").  Set branch.local.merge configuration variable\nif you want to always merge specific branch you obtain from the\nremote.\n\nE.g.\n\n     [branch \"local\"]\n\tremote = origin\n        merge = refs/heads/master\n\nif you want \"git pull\", without saying what to pull from where,\nto fetch from 'origin' and merge its 'master' branch, when you\nare on your 'local' branch.\n\n> (3) I notice I can't reset --hard a single file.  So, if I want to\n> revert a single file to some revision, blowing away my changes, what is\n> the accepted way of doing this?  Is there a way to do the equivalent of\n> a p4 print foo@some_revision?\n\nI have no idea what p4 does, but:\n\n\tgit checkout -- path\n\nupdates the work tree file with the last version of paths you\ndid \"git add path\",\n\n\tgit checkout HEAD -- path\n\nupdates the work tree file with the version of paths in the HEAD\ncommit, and\n\n\tgit checkout some_version -- path\n\nupdates the work tree file with the version of paths in the\nnamed commit.  For various ways to name commits, see\ngit-rev-parse(1).\n\n> (4) I'm still not clear on when a dst should and should not be used in a\n> refspec.  It appears that one can only do non-fast forward updates to\n> the branch that is checked out (which makes sense, since you may need to\n> resolve), but other than that, what is the difference between\n>\n> git checkout foo\n> git pull . master\n>\n> and\n>\n> git checkout master\n> git push . master:foo\n\nThe obvious difference is which branch you end up with.\n\n> (5) Are there any tools for managing some of the metadata (e.g., the\n> origin URL) or is it expected that one edit it directly?\n\ngit-remote(1).\n"}]}