Re: Bizarre missing changes (git bug?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 <filename>" 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux