Obviously I'm new to Git and SourceTree. I used SourceTree to force-push 43 commits into our master on GitHub, and now GitHub does not show any of the commits made before the earliest of those 43, which apparently thought it was adding all of its files for the first time.
How can the GitHub repo be set back, as though this force-push never happened, or - better - so that it shows the numerous earlier commits it already knew about before this force-push?
(I've been using the force-push with another repo fine with batches of commits; the problem in this case seems to be that the commit earliest in this batch somehow thought it was an initial load, or something like that, essentially causing the master in GitHub to be reset from that point.)
There is no danger of anyone else pulling from this repo; it's private and just used as a work log at the moment, which is why it's important to get back to the earlier history.
I'm not sure there's any way to do this in SourceTree - it's generally designed to support only the 'happy path' workflows, and not so much the 'oh crap I need to undo this' workflows in my experience :smile: I don't use it all that much, so happy to be corrected here by someone else.
You should be able to revert to the prior state by accessing the reflog from the terminal (see https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog). Do this by:
git reflogcommand to identify the last-known-good state of your repo
git reset --hard <commit>to revert back to it
git push --forceto reset the remote repository back to that state
Hope this helps!
Was that the pushes did start failing at some point, in both repos. Given the forced push worked fine in the other repo, there was no obvious reason it would fail on this one. The fail was not so much the force push per se, but that the first commit in the pushed batch thought all its files were new, for some reason, apparently. I will turn to StackOverflow if necessary, was hoping the solution could be executed via SourceTree,,
To restore, you're almost certainly going to need to go to the terminal. You'll probably have more luck on StackOverflow in getting an answer with a specific terminal command to run.
Secondly, you shouldn't be force-pushing on a regular basis. If a push needs forced, it's because something has been changed in the local history that will remove commits from your remote's history. Sure, usually it's because you've done some sort of rebase and those commits have been replaced with new ones, but your usage should be: wait until a non-forced push fails, then consider whether a force push is safe this time.
Thanks for this. The problem is / was that the pushes did start failing at some point, in both repos.
Given the forced push worked fine in the other repo, there was no obvious reason it would fail on this one. The fail was not so much the force push per se, but that the first commit in the pushed batch thought all its files were new, for some reason, apparently.
I will turn to StackOverflow if necessary, was hoping the solution could be executed via SourceTree.
I wasn't trying to suggest that a force push was the core cause, but forcing a push with your local repo in the condition of forgetting the history is the problem. I was just recommending you be more cautious in the future before force-pushing, and to avoid getting in the habit of checking the "force" box when it isn't necessary. There certainly may be a way to do this in SourceTree, and it would be wise to wait for an answer (for all you know I've never even used the thing). But, in my experience, SourceTree does not display commits that aren't associated to a branch, and you would need to either see the commits or (at least) know one of their commit hashes in order to fix your repo. I know you can do this via git commands, I've seen answers on Stack regarding similar issues. Good luck!
Thanks for your replies. We did find a local clone and force-pushed that, but now the Github copy is back to what it was, without the latest 50+ commits.
Attached is a screenshot from SourceTree that shows the current situation: we have the purple line of commits simply stopping, then the blue line starts. The first blue-line commit is one where Git thinks all the files in the project are being added.
How do we make the two lines become one?
Screen Shot 2014-11-25 at 2.47.04 PM.png
Here's what I'd do. First, checkout the highlighted commit. Copy the files somewhere outside of your git working copy. Next, checkout master (or create a new branch from master and checkout that). Next, overwrite your working copy with the earlier backup, then commit any changes with the original commit message ("Manual update..."). From here, you should be able to cherry pick each of the remaining commits into your new branch. A merge between the two will probably fail because, to git, you've added two different files with the same name in the same location (and you've done this possibly hundreds or thousands of times), and (in my experience) it will fail rather than make an attempt to merge those together.
Hi folks, While the full post is over on our blog I'd like to share the dark theme we've got planned for 2019 here directly as well to keep the discussion going. The ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events