{"thread":{"id":"27417","subject":"RE: git -- how to revert build to as-originally-cloned?","startedAt":"2011-05-20T16:25:02Z","lastAt":"2011-05-20T20:26:27Z","messageCount":5,"participants":["George Spelvin","John Lumby","Paul Ebermann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"168320","messageId":"20110520162502.7854.qmail@science.horizon.com","threadId":"27417","inReplyTo":null,"subject":"RE: git -- how to revert build to as-originally-cloned?","fromName":"George Spelvin","fromEmail":"linux@horizon.com","sentAt":"2011-05-20T16:25:02Z","receivedAt":"2011-05-20T16:25:02Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"Ah - I should have said that I selected only merges in my git log \ncommand  -\ngit log --merges\n(With no qualifier, git log returns about 3.8 million lines /  150 MBytes,\nhard to work with)\n\n> And,  based on what the command now returns,  it seems that the first two\n> that I listed before (which are no longer present) were as a result of my\n> (single) merge command,  i.e. my merge resulted in merging :\n>     .  two merges that were done by someone else in the master that I \n> cloned into my /b filesystem,\n>      .  maybe some other non-merge commits that I did not query before \n> and now don't know\n\nEr, no.  One \"git merge\" command produces (at most) one commit.\nIt may be that the head of the branch you merged in was already\na merge commit, but tha\n\nYou may find \"gitk\" useful for for visualizing all of this.\n\n\n> You've lost me here.  If a merge can consist of many commits,\n> including other merges (see above), then how can one commit be a merge?\n> Note that in my original git log --merges output that I posted in my\n> earlier post, i.e. the one before I reset, there was *no* record of *my*\n> merge command itself, only of the sub-merges that my merge dragged along.\n> I think this is the crucial (to me) point - git did not record what I did,\n> only the effects of what I did.  Not saying this is wrong or right,\n> but significant.\n\nOkay, here's the basic confusion.  Commits have pointers to other commits,\nand are organized into a linked list.  (Actually, a directed acyclic graph,\nsince a commit can have more than one ancestor pointer.)\nThus, a commit identifies *both* a single snapshot *and* a complete\ndevelopment history.  We tend to talk about a \"commit\" when describing\nthe former, and \"branch\" when talking about the latter, but they're\nactually the same object.\n\nA merge *is* exactly one commit.  A \"merge commit\" is just a commit with\nmore than one ancestor.  Now, that merge can *point to* lots of other\ncommits, but it doesn't exactly \"consist of\" them.\n\nThe other thing is that the ancestors of a merge are symmetrical.\nThey are numbered for reference, but the practical results of \"merge\nA with B\" and \"merge B with A\" are identical.  Every commit points\nto the full development history that produced it.\n\n\nNow, what might have happened to you was a \"fast forward\" merge.\nIf you have a history like this:\n\no--o--o--a--b--c--d\n\nAnd you ask git to merge a and d together, the result will be simply d.\nGit, by default, avoids creating useless merges in such a case.  So if\nyou merge in someone else's work, and you haven't done anything locally\nsince their branch split off from your HEAD, the result will not include\na merge commit at all.  (A NEW merge commit; they branch might include\nmerge commits.)\n\nSince the top merges in your example are by Dave Miller (and not by you),\nit looks like that's what happened in this case.\n"},{"id":"168332","messageId":"4DD6BE8D.4080708@hotmail.com","threadId":"27417","inReplyTo":"20110520162502.7854.qmail@science.horizon.com","subject":"Re: git -- how to revert build to as-originally-cloned?","fromName":"John Lumby","fromEmail":"johnlumby@hotmail.com","sentAt":"2011-05-20T19:18:37Z","receivedAt":"2011-05-20T19:18:37Z","isPatch":false,"sender":{"key":"johnlumby@hotmail.com","avatar":null},"body":"On 05/20/11 12:25, George Spelvin wrote:\n> Er, no.  One \"git merge\" command produces (at most) one commit.\n> It may be that the head of the branch you merged in was already\n> a merge commit, but tha\n>\n> You may find \"gitk\" useful for for visualizing all of this.\n\nI have tried gitk.    Can you or someone tell me what the colours of the \nnodes in the top left signifies?\nSpecifically,   a commit of mine (done since all the merging I've been \nasking about) shows as yellow,\nwhereas all the ones prior to that show as blue.   (I have not altered \nor changed the colour scheme so\nit's whatever the default is)\n\n>\n> A merge *is* exactly one commit.  A \"merge commit\" is just a commit with\n> more than one ancestor.  Now, that merge can *point to* lots of other\n> commits, but it doesn't exactly \"consist of\" them.\n>\n>\n>\n> Now, what might have happened to you was a \"fast forward\" merge.\n\nYes!    actually in the output of the merge command (that I showed in my \noriginal posting) it said\n\nUpdating 72a8f97..1b1cb1f\nFast-forward\n\n\n\n> If you have a history like this:\n>\n> o--o--o--a--b--c--d\n>\n> And you ask git to merge a and d together, the result will be simply d.\n> Git, by default, avoids creating useless merges in such a case.  So if\n> you merge in someone else's work, and you haven't done anything locally\n> since their branch split off from your HEAD, the result will not include\n> a merge commit at all.  (A NEW merge commit; they branch might include\n> merge commits.)\n>\n> Since the top merges in your example are by Dave Miller (and not by you),\n> it looks like that's what happened in this case.\n\nYes indeed,   thanks for explaining.\nSo what would be the correct way,  before doing my fast-forward merge,\nto have made some kind of mark pointing at \"a\",  which I could then have \nused\nto undo the fast-forward,  without having to calculate the number of \ncommits in between?\n(supposing my branch was not anchored at \"a\" but at some much earlier \npoint)?\n\nCheers,    John Lumby\n"},{"id":"168333","messageId":"4DD6C253.2040309@esperanto.de","threadId":"27417","inReplyTo":"4DD6BE8D.4080708@hotmail.com","subject":"Re: git -- how to revert build to as-originally-cloned?","fromName":"Paul Ebermann","fromEmail":"paul.ebermann@esperanto.de","sentAt":"2011-05-20T19:34:43Z","receivedAt":"2011-05-20T19:34:43Z","isPatch":false,"sender":{"key":"paul.ebermann@esperanto.de","avatar":null},"body":"John Lumby schrieb:\n> On 05/20/11 12:25, George Spelvin wrote:\n>> Er, no.  One \"git merge\" command produces (at most) one commit.\n>> It may be that the head of the branch you merged in was already\n>> a merge commit, but tha\n>>\n>> You may find \"gitk\" useful for for visualizing all of this.\n> \n> I have tried gitk.    Can you or someone tell me what the colours of the\n> nodes in the top left signifies?\n> Specifically, a commit of mine (done since all the merging I've been \n> asking about) shows as yellow, whereas all the ones prior to that\n> show as blue. (I have not altered or changed the colour scheme so \n> it's whatever the default is)\n\nFor the nodes:\nYellow is the current HEAD. Red is your worktree, if differing\nfrom the index, green is the index, if differing from HEAD.\nEverything else (in blue) are other commits in the repository.\n\nThe color of the lines is not significant, I think (or at least\nI didn't recognize any regularity here).\n\n(This is for my version of gitk, whichever this might be. I didn't\nfind a way to find out. It says \"(c) 2005-2010\" in the \"about\" dialog\nand \"(c) 2005-2009\" in the start of the source code.\n\n\nPaŭlo\n"},{"id":"168334","messageId":"20110520202220.24482.qmail@science.horizon.com","threadId":"27417","inReplyTo":"4DD6BE8D.4080708@hotmail.com","subject":"Re: git -- how to revert build to as-originally-cloned?","fromName":"George Spelvin","fromEmail":"linux@horizon.com","sentAt":"2011-05-20T20:22:20Z","receivedAt":"2011-05-20T20:22:20Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> I have tried gitk.  Can you or someone tell me what the colours of\n> the nodes in the top left signifies?  Specifically, a commit of mine\n> (done since all the merging I've been asking about) shows as yellow,\n> whereas all the ones prior to that show as blue.\n\nNothing.  It just tries to use different colours so you can tell the\nlines apart.  But the specific colour is no more meaningful than\nshadings on a map.\n\n> So what would be the correct way,  before doing my fast-forward merge,\n> to have made some kind of mark pointing at \"a\",  which I could then have\n> used to undo the fast-forward,  without having to calculate the number\n> of commits in between?  (supposing my branch was not anchored at \"a\"\n> but at some much earlier point)?\n\nThe basic tool to do that is \"git tag <name>\", which creates a tag with\nthe given name.  (The difference between a tag and a branch is simply\nthat a branch is updated when you commit.)\n\nHowever, most people don't bother with an explicit name; see the man page\nfor git-rev-parse for a list of all the ways to refer to old revisions.\n@{1} is the usual syntax for \"the current branch before the last change\",\nor you can use the older name ORIG_HEAD, too.\n\n\"git reflog\" will show an extended history.\n"},{"id":"168335","messageId":"20110520202627.24966.qmail@science.horizon.com","threadId":"27417","inReplyTo":"20110520202220.24482.qmail@science.horizon.com","subject":"Re: git -- how to revert build to as-originally-cloned?","fromName":"George Spelvin","fromEmail":"linux@horizon.com","sentAt":"2011-05-20T20:26:27Z","receivedAt":"2011-05-20T20:26:27Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":">> I have tried gitk.  Can you or someone tell me what the colours of\n>> the nodes in the top left signifies?  Specifically, a commit of mine\n>> (done since all the merging I've been asking about) shows as yellow,\n>> whereas all the ones prior to that show as blue.\n\nGeorge Spelvin wrote, in a fit of insanity:\n> Nothing.  It just tries to use different colours so you can tell the\n> lines apart.  But the specific colour is no more meaningful than\n> shadings on a map.\n\nCorrection: What Pual Ebermann said.  I was talking about the colour\nof the LINES.  I didn't read your question carefully enough.\nMy apologies.\n"}]}