0

I'm having a problem with our git repo. We have one LFS file that is only ever modified by one of our users, on a mac. The mac user pulls and pushes without incident.

But on the Windows dev's PC, git (or tortoisegit) automatically marks the LFS file as modified, even when it's not. I think it's because the switch from pointer to file isn't cleanly understood by tortoisegit.

The ugly effect is that the Windows user tries to push and gets a "you must pull" message, but then tries to pull and gets a merge conflict due to the not-really-modified LFS file. However, there is no resolve... option in the tortoisegit dropdown for the supposed conflict. A revert sets the icon back to unmodified, but any tortoisegit action still fails as though the lfs file has been modified and resets the icon status to modified.

Since the user can't push, can't pull, and can't resolve a merge conflict that's causing the inability to push or pull, the user is stuck. I googled and found some old posts suggesting tortoisegit doesn't handle lfs quite right and causes this, but does anyone have any better idea of how to resolve this than scary trial-and-error with git commands?

RealHandy
  • 534
  • 3
  • 8
  • 27

1 Answers1

1

A proper solution to this would be one in which the lfs file does not wrongly get marked as modified. However, I'm now using this workaround:

  1. The (windows) user commits changes in tortoisegit, making sure to uncheck and thus not include the falsely-marked-modified lfs file in the commit
  2. The user deletes (not tortoisegit deletes, just plain old windows file deletes) the falsely-marked-modified lfs file
  3. The file is now shown as "missing" in tortoisegit status, if viewed
  4. The user does a pull, and the lfs file is pulled successfully without a merge conflict
  5. The user can now push the commit successfully

This is the method we are using until we discover a fix for the lfs file being incorrectly flagged as modified.

RealHandy
  • 534
  • 3
  • 8
  • 27