On Wed, 9 Apr 2014 08:34:53 -0700 (PDT) Fabio Sobral <flsob...@gmail.com> wrote:
[...] > Let's say we have a Java class with a field declared as Object, but > for some reason we decided it should actually be an int[], so we > changed it on the developMajor branch only. [...] > After checking every commit that changed the file I finally got to > that commit we made six months ago only to developMajor, and now it > says it was applied to both developMajor and develop! There's no way > this could go unnoticed for 6 months! > I checked with my co-workers and one of them that hasn't been working > on this particular project last updated his repo about 3 months ago. > So I checked out his version of the develop branch and the damned > field is declared as Object, as it should be. The history also says > that commit made 6 months ago was applied only to the developMajor > branch. > > I don't know how this happened, but apparenly this commit leaked from > one branch to the other in the past 3 months. Should that even be > possible? You should possibly excercise a bit more caution with terminology: commits in Git never "leak" anywhere in any form: once created, a commit is persisted in the repository and never changes. Moreover, Git branches do not "own" commits, and commits do not "belong" to branches: a branch or a tag is merely a pointer to a single commit, and it's that commit's link to its parent (then and further down) that forms what we preceive as a branch. (I'm nitpicking because to comprehend possible causes for your trouble it helps to have a clear picture of how Git represents the history of a project it maintains.) What might legitimately "leak" between branches are *textual changes.* Let me repeat: only textual changes only ever move between commits (and hence branches), when needed. There are three legitimate causes for a textual change made in a commit to appear in another: 1) True merge (that is, not fast-forward, which is a trivial case). 2) Cherry pick. 3) Editing a file by hand. While I beleive (as opposed to thinking) it might be technically possible for such a textual change to surprisingly appear in an unexpected line of development due to some repository corruption, I'd first check wastly more possible reasons such as user error. To do this, use the `git blame` tool which is able to tell you who and when introduced a particular change to a file. Let me reiterate on the importance of understanding the distinction between commits and textual changes with regard to the contents of the files. Consider a simple true merge. Suppose we have two lines of history, with tip commits A and B, respectively; B has some commit C in its line of history which introduced a change which is present in B, and we're about to merge B into A. Normally after doing this the resulting commit will refer to a state of the repository which has both changes contained in A and B. So the resulting merge commit M is usually said to contain the changes of A and B, both. That's what everyone knows about merge commits and that's how merge commits are used to both bring other changes in and form a history graph. But obviously no one prevents me from running the merge using the "--no-commit" command-line option, then update the staging area so that it excludes the changes introduced by commit C and then commit the result. What happens is that there will be a merge commit, changes from B will be in the resulting state but there will be no C's changes! I'm also able to *introduce* arbitrary changes, not present in neither A nor B, before recording a merge commit. The same logic applies to cherry picks: no one prevents you from changing the changes it brings in arbitrary ways before recording a commit. What I'm leading you to is that while considering merge commits as the points of bringing in changes is okay and useful but it implies everyone doing merge commits plays by the rules, and it's textual changes what matters, not how the history looks like in a history browser. You might also find reading the second part of [1] particularly amusing. So start with `git blame`. If that does not work try resorting to `git fsck` (a thread a day ago dealt with it so you might look it up) but really I don't beleive in repository breakage. 1. http://randyfay.com/content/avoiding-git-disasters-gory-story -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
