Just hurriedly committed to sourcetree to bit bucket and lost 2 hours work
Asked by montage:

I only use source tree for one of one project that has mainly text file (sql scripts) and now an excel file. For other code projects I use the git command line.

I got an error that said something like "Commit was successful though push failed" which makes sense if I needed to pull first. Only thing was there was nothing to pull after fetching and going back to commit there is now no changes. My colleague who uses the git cmd line says the symptoms are like an rebase hard as all changes since my last commit yesterday failed. The other interesting thing was that I was the last person to commit yesterday and there was no reason to pull before pushing!  

I believe this might be to do with something committing the excel being open (file closed though excel 2016 still open) with the file that is in source control as this is only an file I started to commit recently.   

I regularly update source tree and was running the latest version at the time of this error a short time ago.


Answers:
author: montage
body: 90% sure I know what I did. I miss clicked just above the OK button and that checked the "Rebase Instead of Merge". Perhaps I need an better mouse though this is bad usability being able to click the label a long way from the check box and the text and able to change the check box on the same line.


author: thinsoldier
body: Exactly how did your work get lost? If your commit was successful then your work is stored in that commit.
>
> ```
> as all changes since my last commit yesterday failed
> ```

Yes it does sound like you checked out you last commit and chose to abandon you uncommitted changes.

Any time you're about to do something in git you're not sure about, consider doing these 2 things.

#1: copy your modified files to another folder so if anything goes wrong you still have them.

#2: make a new branch and commit your changes there so if anything strange happens on the main branch you were working on, you can copy or cherry-pick from your backup branch. Even if it's experimental work you're not sure you want to save, commit it to a backup branch anyway. You can always delete it later. And even days after you've deleted it you can recover it via \`git reflog\`.


author: Seth
body: True, but it may have interfered with the commit. Maybe it hadn't written the changes to the actual file yet, but just had them in memory, so the commit didn't include them? Just guessing at this point...


author: thinsoldier
body: I might be wrong but I think git transmits the objects stored within the hidden .git folder and not the actual file in the working folder, so having the file open shouldn't interfere with the git push.


author: Seth
body: I imagine you've done this, so I'm posting as a comment instead of an answer. But just in case:

When you get the message "Commit was successful though push failed", you don't usually have to come back and re-attempt the commit, just the push. Double check that the "unmodified" files don't have your changes.

Besides that, it certainly is possible that Excel may have interfered with Git. I've not personally versioned any active office files, so I have no experience with that kind of interaction. I wouldn't expect it to result in the error message you listed, though.


Tags: windows