1

Suppose A modifies X. Then, A commits its changes and pushes to origin.

Then B modifies Y. B commits its changes. Then B makes a pull (supposedly bringing the changes made by the commit made by A) from origin. Then B pushes to origin.

The last commit done by B says that B! made the changes on X and Y, but B never touched X. Sometimes, the commit made by B would overwrite the changes made by A to X (as if A never made any change).

This case was happening (more than once) to me and my team.

Before that, the "weirdest" things we did were:

  • git update-index --assume-unchanged path/to/file

And

  • git rm . --cached, (modify .gitignore), git add .

Any ideas? Thanks.

By the way, we ended up creating a new repo, but I'm curious.

Link to the real repo:

On this commit, laygr stands for B and app/View/Requests/view.ctp stands for X.

Could it be...?

Could it be that sublime (a well-known code editor) didn't reload the changes on X and when I did my commit, git thought that I reverted the file?

Lay González
  • 2,901
  • 21
  • 41
  • When you mention that B's changes overwrite A's sometimes, was B working on the same lines as A? With how git works, merges are done line by line, so the only issue that would arise is that...which theoretically should result in a merge conflict... I would see what results from doing (if you still have old repo): gitk [filename] – ryanlutgen Nov 10 '13 at 06:59
  • You cannot "pull commit", but you can pull branch. And pulling the branch does implicit merge [(confusingly)](http://stackoverflow.com/a/18930564/1734130). – mvp Nov 10 '13 at 07:01
  • @Vizkos, B never touched X, so there shouldn't be any conflict. Later we made an artificial conflict scenario and it worked normally. – Lay González Nov 10 '13 at 07:22
  • from your real repo - what is the id of the merge commit generated by the `git pull` you mentioned? – michas Nov 10 '13 at 07:50
  • @michas This is the history of "X" https://github.com/aliciacatalina/multiproveedores/commits/6911502a7f7914f1c2b9239288947395ca9866c0/app/View/Requests/view.ctp The last commit shown there is where I overwrote the second last commit shown there. – Lay González Nov 10 '13 at 07:56
  • So, 6911502a7f7914f1c2b9239288947395ca9866c0 is the commit that overwrote app/View/Requests/view.ctp – Lay González Nov 10 '13 at 07:59
  • There is no magic in commit 6911502a. According to the history you definitely did the changes listed there. :) – michas Nov 10 '13 at 08:05
  • BTW: Your history looks pretty noisy. Think about using `git pull --rebase` instead of `git pull` to avoid all those implicit branches and merges. – michas Nov 10 '13 at 08:13
  • It's all in the development branch. We planned to do the rebase-squash when releasing. Is a good practice to do rebase even on the development branch? – Lay González Nov 10 '13 at 08:22
  • @michas I'll study this: http://randyfay.com/content/rebase-workflow-git Thanks for the advice. – Lay González Nov 10 '13 at 08:27

3 Answers3

2

This is the part of your repository you are talking of. The marked commit is the one you were referring to. That commit is just an ordinary commit and the one looks like an explicit merge commit done by Alicia. - What exactly is the question here?

$ git log --boundary --graph --decorate --name-status d1f6bd97ca3483720f899e69a1bd7c5afd63b9c3 ^6911502a7f7914f1c2b9239288947395ca9866c0^
* commit d1f6bd97ca3483720f899e69a1bd7c5afd63b9c3
| Author: Alicia G <alicia.gonzalez.90@gmail.com>
| Date:   Sat Nov 9 09:41:51 2013 -0600
| 
|     tabs styling for advanced search
| 
| M     app/View/Requests/view.ctp
|    
*   commit 468d6f3b36a11659c96e8b6e2adc3b8844dba63f
|\  Merge: 849a468 6911502
| | Author: Alicia G <alicia.gonzalez.90@gmail.com>
| | Date:   Sat Nov 9 09:11:21 2013 -0600
| | 
| |     borro mi database porque lay lo borro de nuevo
| |   
| * commit 6911502a7f7914f1c2b9239288947395ca9866c0
| | Author: Lay <lay.gr@me.com>
| | Date:   Sat Nov 9 04:32:46 2013 -0600
| | 
| |     busueda super eficiente y resultados agrupados    <<===================
| | 
| | M   app/Controller/ProductsController.php
| | M   app/Controller/SupplierServicesController.php
| | A   app/Lib/ProductResult.php
| | M   app/Model/Product.php
| | M   app/Model/Supplier.php
| | M   app/View/Requests/view.ctp
| | M   app/webroot/js/requests-view-partial.js
| |     
* |   commit 849a468c067012f423969e596b3e2b573ff18e3c
|\ \  Merge: d845fd6 f04f996
| | | Author: Alicia G <alicia.gonzalez.90@gmail.com>
| | | Date:   Fri Nov 8 19:51:17 2013 -0600
| | | 
| | |     Merge branch 'development' of github.com:aliciacatalina/multiproveedores into development
| | |    
* | | commit d845fd6a28328421655718e0324f755a1bee7d65
| | | Author: Alicia G <alicia.gonzalez.90@gmail.com>
| | | Date:   Fri Nov 8 19:51:07 2013 -0600
| | | 
| | |     front
| | | 
| | | M app/Config/database.php
| | |    
| o | commit f04f996951c6e1a8caca926ac77a9252465f8559
|/ /  Merge: 0c582b1 e56eb22
| |   Author: ozgarza <ozielgarzalopez@gmail.com>
| |   Date:   Fri Nov 8 19:50:44 2013 -0600
| |   
| |       Merge branch 'development' of https://github.com/aliciacatalina/multiproveedores into development
| |   
o | commit e56eb22ef799c275b4d254a9db154c8a96529035
 /  Merge: 7f518fd 678bfcf
|   Author: Alicia G <alicia.gonzalez.90@gmail.com>
|   Date:   Fri Nov 8 19:49:40 2013 -0600
|   
|       front
|  
o commit 8bae829dac9b892408cfb58afc9900d6026c593f
  Merge: 6ad499c ab68cd1
  Author: Ana Daniel <ana.daniel@icalialabs.com>
  Date:   Fri Nov 8 20:51:16 2013 -0600

      Merge branch 'development' of github.com:aliciacatalina/multiproveedores into development

The history of the one file is even more "boring":

$ git log --name-status --oneline --graph origin/development -- app/View/Requests/view.ctp
* 9579fac datos de ordenes en orders index
| M     app/View/Requests/view.ctp
* e6818f0 orders view
| M     app/View/Requests/view.ctp
* da88164 requests view
| M     app/View/Requests/view.ctp
* 42eceb9 removal of search by id
| M     app/View/Requests/view.ctp
* feabe49 view de requests OTRA VEZ, GRACIAS LAY
| M     app/View/Requests/view.ctp
* d1f6bd9 tabs styling for advanced search
| M     app/View/Requests/view.ctp
* 6911502 busueda super eficiente y resultados agrupados
| M     app/View/Requests/view.ctp
* 6ad499c view de solicitud
| M     app/View/Requests/view.ctp
* 7f518fd front
| M     app/View/Requests/view.ctp
* a550ba1 tabs for advanced search
| M     app/View/Requests/view.ctp
* f4763b0 aoeu
| M     app/View/Requests/view.ctp
* b1d2544 refactor de como funcionas las formas para productos
| M     app/View/Requests/view.ctp
* dad790f title fix
| M     app/View/Requests/view.ctp
* 33f1b87 avance de búsqueda de proveedores
| M     app/View/Requests/view.ctp
* 85cac04 actions
| M     app/View/Requests/view.ctp
* 5f095dd table styles
| M     app/View/Requests/view.ctp
* df636f6 Login y asignación automática de requests a usuarios.
  A     app/View/Requests/view.ctp
michas
  • 25,361
  • 15
  • 76
  • 121
  • On commit "busueda super eficiente y resultados agrupados", This shouldn't be: M app/View/Requests/view.ctp ... I didn't modified app/View/Requests/view.ctp. What is worst, the "change" I did to that file was to revert it as it was in an older time. – Lay González Nov 10 '13 at 08:07
  • According to the commit history you definitely did. - There seems to be no git magic involved. – michas Nov 10 '13 at 08:12
  • Yeah... evidence says it was my fault. But then it happened to another member of the team; that's when we decided to create a new repo. I'll try to replicate the problem with my team and report if we discover a cause other than human error. – Lay González Nov 10 '13 at 08:18
  • For now, I'll select your post as the answer as if it is implying human error. – Lay González Nov 10 '13 at 08:20
0

One possibility is that the access mode was changed by B. In this case, Git will mark X as changed even if B didn't change the content of X.

If so, you can refer to this page to let git ignore such changes: How do I make Git ignore file mode (chmod) changes?

Community
  • 1
  • 1
volatilevar
  • 1,626
  • 14
  • 16
  • But, sometimes, the changes made to X would not only be attributed to B, but actually removed as if B reverted X. A chmod would explain the attribution of the changes of X to B, but not the reversion of the changes made to X. – Lay González Nov 10 '13 at 07:33
0

I did exactly as you described:

$ git log --name-status --graph --decorate
*   commit af88faba5e3f05c23b466796e153cb3202fd2e42 (HEAD, master)
|\  Merge: 9a660b5 a2fb37d
| | Author: B <B>
| | Date:   Sun Nov 10 08:24:46 2013 +0100
| | 
| |     Merge branch 'master' of <remote> into master
| |   
| * commit a2fb37d566e820f9ebcf456bd213d84f14b14321
| | Author: A <A>
| | Date:   Sun Nov 10 08:23:08 2013 +0100
| | 
| |     modifyX
| | 
| | M   X
| |   
* | commit 9a660b557aab3a5adc802d9734ca53aa648fd643
|/  Author: B <B>
|   Date:   Sun Nov 10 08:24:29 2013 +0100
|   
|       modifyY
|   
|   M   Y
|  
* commit d7bdb719327d0e396c2c7553392101434b662c4e
  Author: A <A>
  Date:   Sun Nov 10 08:21:48 2013 +0100

      first

  A     X
  A     Y

The first commit adds files X and Y, then B changes Y while A changes X. Finally B makes a pull which implies a merge between both previous changes. The merge itself did not change any files it only merges the existing commits.

michas
  • 25,361
  • 15
  • 76
  • 121