2

I have some commits that have vanished from our RELEASE Branch (the branch we use to publish to production).

For the sake of argument let's refer to them as commits B, C, D and E.

Essentially what happened is that I merged some commits from my fix into this release branch.

If I checkout my branch at this point I see the history of changes applied before it including changes made by a couple of developers from a few days prior.

However, if I then check out the next commit, a specific range of 4 commits from a few days prior vanish.

That next commit is a merge from the master branch into release.
There are quite a few commits here but absolutely none of them mention the files from the "vanished" commits.

The merge was done with the following commands:

git checkout master
git merge release
git push
git checkout release
git merge master
git push

At which point, the previous commits were vanished.

Looking at the latest copy of release, commits A, F, G... are all there. As well as the work merged over from master.

But somehow B-E do not show up and there's no history indicating a revert anywhere.

After commit B, one developer branched off of RELEASE and subsequently checked some changes over onto master.

Perhaps that threw things off?

There are no commits indicating a revert, and from SourceTree, if I log any of the selected files I don't see the commits in history.

Running git branch --contains, however, shows these commits to be on both release and master.

Commit E is a Merge branch 'RELEASE' into RELEASE commit indicating the developer did a pull here... nothing unusual really.

I know this may be too vague but I'm not that strong at Git and am not sure what details are helpful here for an answer. I'm happy to provide any additional info that I can, though. With that being said, here is the graph. Commits B-E are indicated by the hash codes of BBBB, CCCC, DDDD, EEEE. I believe commit XXXX is where I synced with the latest in RELEASE, and commit YYYY is where the changes from B-E 'vanished'.

C:\Users\AcmeCoDev7\Documents\GitHub\1.0 [release]> git log --graph --oneline --decorate
*   YYYY (HEAD -> release, tag: v0.0.573, origin/release, origin/master, origin/HEAD, master) Merge branch 'release'
|\
| *   XXXX Merge branch 'release' of https://github.com/AcmeCo/1.0 into release
| |\
| | * 62ea661 (bug fix) encode...
| | *   6f768f9 Merge branch 'dev_branch' into release
| | |\
| | * \   8b2e629 Merge branch 'dao_optimize' into release
| | |\ \
| | | * | c5c333b (origin/dao_optimize) removing stuff
| | | * | ea1d574 Yank out images
| | * | | ecce9a2 Fixed NPE
| | |/ /
| | * |   9713b1e Merge branch 'release' of https://github.com/AcmeCo/1.0 into release
| | |\ \
| | | * \   1dfcd3d Merge branch '658-analytics' into release
| | | |\ \
| | | | * | c98a2ca (origin/analytics) null check
| | * | | | d2c9ef0 Added exception detail 
| | |/ / /
| | * | | 156b40e Implementing check
| * | | | 1a65293 Round up/round down for different types
| |/ / /
| * | | 43646b5 logging
| |/| |
| * | | f83e4c6 add Integration tests 
| * | | 8a862e8 adding javadocs 
| |/ /
| * |   EEEE Merge branch 'release' of https://github.com/AcmeCo/1.0 into release
| |\ \
| | * | dfee3b8 Remove stuff
| * | | DDDD Added null check 
| |/ /
| * | CCCC fix bug where bundles kits werent showing in yoy growth
* | |   9a32b08 Merge branch 'dev_release_local_branch'
|\ \ \
| * | | f1e3762 716 :: the edit form for a product is not displayed
| * | | e147fa9 716 :: the edit form for a product is not displayed
| |/ /
| * | BBBB roll up inventory 
| * |   889c26f Merge branch 'lock-step-chunck' into release
| |\ \
* | \ \   341e729 Merge remote-tracking branch 'origin/670-lock-step-chunck'
|\ \ \ \
| | |/ /
| |/| |
| * | | c7d0675 (origin/670-lock-step-chunck, 670-lock-step-chunck) 670 :: remove the locking listener
IcedDante
  • 6,145
  • 12
  • 57
  • 100
  • Under (essentially) no circumstances should a git commit vanish after a pull or fetch without doing `--force` or similar. (System resources willing: filling up temp space or force setting clocks makes all kinds of odd things happen.) – bishop Mar 15 '16 at 19:41
  • How are you viewing these commits? The `git log` command traverses the commit graph in ways modifiable via various arguments. I suspect you're using some kind of GUI viewer that may skip commits so as to hide "irrelevant" detail, even if it's actually relevant. – torek Mar 15 '16 at 19:42
  • we're hosted on github and our repository isn't *that* big :-) If somebody, god willing, did a force, would there be any indication to see that using the git console or sourcetree? – IcedDante Mar 15 '16 at 19:43
  • 2
    Show us the result of `git log --graph --oneline --decorate`. If you have anything sensitive in there, feel encouraged to omit it. – Makoto Mar 15 '16 at 19:43
  • If I checkout the commit _before_ the vanishing happened and run git log, I see the changes on the missing files! Checking out the next commit and running it again shows the history entry not showing up. I'll work on cleaning up the graph and get that here – IcedDante Mar 15 '16 at 19:55
  • It now sounds like you're saying the commits are *not* vanishing from the history, but rather, that at commit X, your tree looks the way you expect, then at commit Y (a descendent of X), your tree looks wrong. If that's the case, it means whoever made commit Y simply broke the tree first. GIt stores what its user tells it to, not what you think the user should have told it to.... – torek Mar 15 '16 at 20:05
  • torek- not sure I follow. If commit Y results in file codechanges.java to lose changes that were made in a previous commit, would not a diff show that clearly? I'm posting the graph now. Thanks everyone! – IcedDante Mar 15 '16 at 20:14
  • 1
    When you ask `git show` or `git log` to show you a *merge* commit, git uses what it calls a "combined diff" to compare the merge against *both* parents. A combined diff shows only files that have differences against *both* parents, so if a user decided that merge commit Y should have the "wrong" parent's code in it, `git show` will show nothing, because commit `Y` matches one of its parents (just, the *wrong* one: the one specified by the user who made it, rather than the one you believe they should have chosen). Note that you can use `git show -m` to see more. – torek Mar 15 '16 at 20:19
  • I see- does a user "decide" to have the wrong code by resolving a conflict incorrectly, or is there another way? – IcedDante Mar 15 '16 at 20:22
  • I have this same problem - sort of. Technically nothing is missing, but it's bothering me that the Github Desktop client isn't showing a few commits that should be present, even if their effects are there. – MutantOctopus Mar 15 '16 at 20:28
  • torek - using `git show -m` is pretty verbose (lots of files were merged), but it does show the missing changes! The merge at `YYYY` did modify the changes from B-E, but the team here is still not really sure about the "why that would happen" part. No conflicts were generated during the merge but I did not do a review of each file before the commit.. is it possible that git decided to do this merge quietly? – IcedDante Mar 15 '16 at 20:34
  • The verbosity is why `-m` is not the default. As for the actual merge and its results, it depends on who did the merge and how (e.g., what command(s), any custom merge drivers, and so on). A bog-standard merge *should* have combined changes from the merge-base as usual, though: see http://stackoverflow.com/a/35954651/1256452 – torek Mar 15 '16 at 21:08

0 Answers0