From: Tim Harper Date: Mon, 21 Jul 2008 22:55:24 GMT Subject: Re: Bizarre missing changes (git bug?) Message-ID: <191E68A7-7F91-48E7-BC47-BEC74CC7EC42@gmail.com> In-Reply-To: On Jul 21, 2008, at 4:53 PM, Tim Harper wrote: > > On Jul 21, 2008, at 2:37 PM, Linus Torvalds wrote: > >> >> >> On Mon, 21 Jul 2008, Tim Harper wrote: >>> >>> Anyone run into this before? Any idea what might have caused it? >>> We're a bit >>> concerned about this because if we don't know how to avoid this, >>> we no longer >>> can feel certain that when something is committed, it will make it >>> out in our >>> release. >> >> Read up on '--full-history'. >> >> By default, git simplifies the history for logs that have path >> simplification: only walking down the side of a merge that all the >> data >> came from (ie the unchanged side). So it only leaves merges around if >> there was changes from _all_ parents. >> >> So without --full-history, if any parent matches the state, it just >> removes the merge and picks that parent that contained all the state. >> Obviously, any changes to that file can be sufficiently explained by >> walking just that limited history, because they must have changed in >> _that_ history too! >> >> That default behaviour leads to a *much* simpler history, and is >> usually >> what you want - it avoids unnecessary duplication when something was >> changed trivially the same way in both branches - 'git log' will >> just pick >> the first branch. >> > > Agreed - this was an insightful decision. > >> So, if you had two (or more) commits that both fixed the same bug in >> different branches, and thus both branches actually ended up with >> the same >> contents, it does mean that "git log " will only show >> _one_ of >> the fixes. >> >> In this case, it apparently showed another version than the one you >> were >> looking for. >> >> Linus > > Git has made me feel stupid on various occasions. This is no > exception as the problem turned out being in the chair, not in git. > > After running through git bisect, and ran the command Alex Riesen > suggested, it made it pretty crystal clear where things went wrong. > It turned out to be a bad merge that was from a conflict related to > white-space issues, and the wrong resolution was chosen (a > resolution that also consequently turned out to be no change). > > Another false impression I had is a merge conflict resolution would > always be displayed in a merge commit. However, after running over > the merges again, if you pick the right or left, discarding the one > or the other, nothing is shown in "git log -p" for the merge > commit. Is there a way to see what was chosen for a conflict > resolution? Seeing that in the merge commit would have made things > a little more clear. > Actually, I found it: http://www.kernel.org/pub/software/scm/git/docs/git-log.html "git log -p -c" gives me what I was looking for Tim > Thank you for articulating git branch's behavior - all is clear as > mud now :) > > Tim