# RE: git -- how to revert build to as-originally-cloned? 5 messages from 2011-05-20 to 2011-05-20. Participants: George Spelvin, John Lumby, Paul Ebermann. Thread: https://gitlist.dev/t/27417 ## George Spelvin, 2011-05-20 16:25 Subject: RE: git -- how to revert build to as-originally-cloned? Message-ID: <20110520162502.7854.qmail@science.horizon.com> URL: https://gitlist.dev/e/20110520162502.7854.qmail%40science.horizon.com ``` Ah - I should have said that I selected only merges in my git log command - git log --merges (With no qualifier, git log returns about 3.8 million lines / 150 MBytes, hard to work with) > And, based on what the command now returns, it seems that the first two > that I listed before (which are no longer present) were as a result of my > (single) merge command, i.e. my merge resulted in merging : > . two merges that were done by someone else in the master that I > cloned into my /b filesystem, > . maybe some other non-merge commits that I did not query before > and now don't know Er, no. One "git merge" command produces (at most) one commit. It may be that the head of the branch you merged in was already a merge commit, but tha You may find "gitk" useful for for visualizing all of this. > You've lost me here. If a merge can consist of many commits, > including other merges (see above), then how can one commit be a merge? > Note that in my original git log --merges output that I posted in my > earlier post, i.e. the one before I reset, there was *no* record of *my* > merge command itself, only of the sub-merges that my merge dragged along. > I think this is the crucial (to me) point - git did not record what I did, > only the effects of what I did. Not saying this is wrong or right, > but significant. Okay, here's the basic confusion. Commits have pointers to other commits, and are organized into a linked list. (Actually, a directed acyclic graph, since a commit can have more than one ancestor pointer.) Thus, a commit identifies *both* a single snapshot *and* a complete development history. We tend to talk about a "commit" when describing the former, and "branch" when talking about the latter, but they're actually the same object. A merge *is* exactly one commit. A "merge commit" is just a commit with more than one ancestor. Now, that merge can *point to* lots of other commits, but it doesn't exactly "consist of" them. The other thing is that the ancestors of a merge are symmetrical. They are numbered for reference, but the practical results of "merge A with B" and "merge B with A" are identical. Every commit points to the full development history that produced it. Now, what might have happened to you was a "fast forward" merge. If you have a history like this: o--o--o--a--b--c--d And you ask git to merge a and d together, the result will be simply d. Git, by default, avoids creating useless merges in such a case. So if you merge in someone else's work, and you haven't done anything locally since their branch split off from your HEAD, the result will not include a merge commit at all. (A NEW merge commit; they branch might include merge commits.) Since the top merges in your example are by Dave Miller (and not by you), it looks like that's what happened in this case. ``` ## John Lumby, 2011-05-20 19:18 Subject: Re: git -- how to revert build to as-originally-cloned? Message-ID: <4DD6BE8D.4080708@hotmail.com> URL: https://gitlist.dev/e/4DD6BE8D.4080708%40hotmail.com In-Reply-To: <20110520162502.7854.qmail@science.horizon.com> ``` On 05/20/11 12:25, George Spelvin wrote: > Er, no. One "git merge" command produces (at most) one commit. > It may be that the head of the branch you merged in was already > a merge commit, but tha > > You may find "gitk" useful for for visualizing all of this. I have tried gitk. Can you or someone tell me what the colours of the nodes in the top left signifies? Specifically, a commit of mine (done since all the merging I've been asking about) shows as yellow, whereas all the ones prior to that show as blue. (I have not altered or changed the colour scheme so it's whatever the default is) > > A merge *is* exactly one commit. A "merge commit" is just a commit with > more than one ancestor. Now, that merge can *point to* lots of other > commits, but it doesn't exactly "consist of" them. > > > > Now, what might have happened to you was a "fast forward" merge. Yes! actually in the output of the merge command (that I showed in my original posting) it said Updating 72a8f97..1b1cb1f Fast-forward > If you have a history like this: > > o--o--o--a--b--c--d > > And you ask git to merge a and d together, the result will be simply d. > Git, by default, avoids creating useless merges in such a case. So if > you merge in someone else's work, and you haven't done anything locally > since their branch split off from your HEAD, the result will not include > a merge commit at all. (A NEW merge commit; they branch might include > merge commits.) > > Since the top merges in your example are by Dave Miller (and not by you), > it looks like that's what happened in this case. Yes indeed, thanks for explaining. So what would be the correct way, before doing my fast-forward merge, to have made some kind of mark pointing at "a", which I could then have used to undo the fast-forward, without having to calculate the number of commits in between? (supposing my branch was not anchored at "a" but at some much earlier point)? Cheers, John Lumby ``` ## Paul Ebermann, 2011-05-20 19:34 Subject: Re: git -- how to revert build to as-originally-cloned? Message-ID: <4DD6C253.2040309@esperanto.de> URL: https://gitlist.dev/e/4DD6C253.2040309%40esperanto.de In-Reply-To: <4DD6BE8D.4080708@hotmail.com> ``` John Lumby schrieb: > On 05/20/11 12:25, George Spelvin wrote: >> Er, no. One "git merge" command produces (at most) one commit. >> It may be that the head of the branch you merged in was already >> a merge commit, but tha >> >> You may find "gitk" useful for for visualizing all of this. > > I have tried gitk. Can you or someone tell me what the colours of the > nodes in the top left signifies? > Specifically, a commit of mine (done since all the merging I've been > asking about) shows as yellow, whereas all the ones prior to that > show as blue. (I have not altered or changed the colour scheme so > it's whatever the default is) For the nodes: Yellow is the current HEAD. Red is your worktree, if differing from the index, green is the index, if differing from HEAD. Everything else (in blue) are other commits in the repository. The color of the lines is not significant, I think (or at least I didn't recognize any regularity here). (This is for my version of gitk, whichever this might be. I didn't find a way to find out. It says "(c) 2005-2010" in the "about" dialog and "(c) 2005-2009" in the start of the source code. Paŭlo ``` ## George Spelvin, 2011-05-20 20:22 Subject: Re: git -- how to revert build to as-originally-cloned? Message-ID: <20110520202220.24482.qmail@science.horizon.com> URL: https://gitlist.dev/e/20110520202220.24482.qmail%40science.horizon.com In-Reply-To: <4DD6BE8D.4080708@hotmail.com> ``` > I have tried gitk. Can you or someone tell me what the colours of > the nodes in the top left signifies? Specifically, a commit of mine > (done since all the merging I've been asking about) shows as yellow, > whereas all the ones prior to that show as blue. Nothing. It just tries to use different colours so you can tell the lines apart. But the specific colour is no more meaningful than shadings on a map. > So what would be the correct way, before doing my fast-forward merge, > to have made some kind of mark pointing at "a", which I could then have > used to undo the fast-forward, without having to calculate the number > of commits in between? (supposing my branch was not anchored at "a" > but at some much earlier point)? The basic tool to do that is "git tag ", which creates a tag with the given name. (The difference between a tag and a branch is simply that a branch is updated when you commit.) However, most people don't bother with an explicit name; see the man page for git-rev-parse for a list of all the ways to refer to old revisions. @{1} is the usual syntax for "the current branch before the last change", or you can use the older name ORIG_HEAD, too. "git reflog" will show an extended history. ``` ## George Spelvin, 2011-05-20 20:26 Subject: Re: git -- how to revert build to as-originally-cloned? Message-ID: <20110520202627.24966.qmail@science.horizon.com> URL: https://gitlist.dev/e/20110520202627.24966.qmail%40science.horizon.com In-Reply-To: <20110520202220.24482.qmail@science.horizon.com> ``` >> I have tried gitk. Can you or someone tell me what the colours of >> the nodes in the top left signifies? Specifically, a commit of mine >> (done since all the merging I've been asking about) shows as yellow, >> whereas all the ones prior to that show as blue. George Spelvin wrote, in a fit of insanity: > Nothing. It just tries to use different colours so you can tell the > lines apart. But the specific colour is no more meaningful than > shadings on a map. Correction: What Pual Ebermann said. I was talking about the colour of the LINES. I didn't read your question carefully enough. My apologies. ```