If I compare the output of git log and the commit history in the Xcode 9 Source Control Navigator, there is a marked difference and many recent commits tend to be missing. For instance, right now git log lists 10 commits from today, whereas only 5 are visible in Xcode. I think Xcode's commit history does update occasionaly, but I haven't noticed any patterns in its behavior. In any case, I do not recall this being a problem up until Xcode 9 and the changes it includes to how source control is handled.
I've tried switching to another branch and then back to master. The Pull and Fetch and Refresh Status items in the Source Control menu have no effect. In Preferences/Source Control, Refresh Local Status Automatically is enabled. Restarting Xcode also does not help.
Admittedly, I do tend to do most of my interaction with git (pull, commit, push etc.) from a separate terminal window. Xcode is of course much easier to use for diffing.
Here are two screenshots that illustrate the issue (5 vs 15 commits):
This image shows the output of git log --oneline --decorate --graph --all.
Does anyone know what might be causing this issue?
Commits are not missing to show in xcode.
The different results caused by xcode only show the commits on master branch, while git log show the commits for all branches.
You can obviously find in the output of git log --oneline --decorate --graph --all that the commits ce514, 12b6a, ef7a0, ccdfc etc on master branch, while the commits from 8487c to f5da3 on other branches (not master branch).
And if you execute the command git log master --oneline, it will list the commits only on master branch, and the result will be same as xcode shows.
Related
I am using SourceTree as a git client.
A while ago, I had a major problem with my project and my git, so I had to reactivate a copy of my workspace from an external source. For that purpose I had created a complete new repository. Commiting to that now.
Today I've noticed, that most of my files appear as "modified" in Xcode. Even after commit and push (with SourceTree).
Source Control shows my two branches, what is correct:
And the History shows perfectly all the commits:
My feeling tells me, that in the background the old repository information is still present and does this bug. How do I handle this? Help is very appreciated.
Edit:
git diff --ws-error-highlight=new,old Output
Close Xcode. If you can avoid it, don't reopen Xcode :-) If it's an absolute must, reopen Xcode. The M markers should be gone.
This worked for me:
Delete derived data folder(Steps: Click Xcode on top left -> Preferences -> Locations -> Click on the right arrow below Derived Data and that will you take you to the Derived Data folder in Finder. Delete it)
Quit Xcode (Don't just close the project)
Reopen Xcode
Check if the nature of the diff is related to eol (end of lines).
See "git diff - show me line ending changes?", like:
git diff --ws-error-highlight=new,old
If that is the case, try first:
git config --global core.autocrlf false
Then try again to clone your repo, and see if XCode still display those differences.
In your case, this is not about eol, but about an update done in your files.
Check for any .gitattributes file: is there a smudge directive in those files (which would explain an automatic process taking place on checkout)
See Keyword expansion for an example of smudge script.
Something seems to update JTAppleCalendar to its latest relase (6.0.1 from 7 days ago)
My feeling tells me, that in the background the old repository information is still present and does this bug.
Simply try, in command-line, to clone again that repo (in a brand new local path) and check if the issue persists in that new cloned repo.
to the JTAppleCalendar, I have changed from 6.0.0 to 6.0.1 manually. around 7 days ago. when the new xcode 8.0.1 arrived
In that case, all those files should be listed as modified: that is what Git does.
I had made a few new views in a new branch off of the master branch and had finally finished making those and was ready to merge back to to master branch but xcode crashed right in the middle of the merge and now source control says my last commit was 14 days ago and has reverted to that version even though i have been committing it every day. Does anyone know how to get the files back and get my source control to remember the most recent commits. Thanks.
Try "git reflog" to see if you see all your previous commits.
Use "git reset --hard HEAD^" to go back to that commit. "HEAD^" in this case is the commit hash you will see with "git reflog".
My coworker was on one branch, I was on the other. When she merged her branch with mine, my changes did not get in. The source files were "M" (Modified) in Xcode and not "C" (Conflict) so we assumed it was ok. I went back to my branch and I saw that the the code I changed was still there and my code was working fine. Then we thought to try the merge again but being on my branch from my desktop. Same thing showed up where the files were "M" and none were "C".
Again my changes got overriden. So now I'm trying to go back a merge. I tried using the Github tool I downloaded from http://mac.github.com/ by clicking on the most recent commit, and rolling back to that commit, but my changes still seemed to be gone. I do not see the merging of the branches in the history. Is that because I haven't committed after merging?
How can I get back to my branch before I merged?
I haven't used Xcode's version control GUI nor Github tool. If you know the sha1 of the commit which had your changes, you can do this at the command line:
git reset --hard <the sha1>
That will reset your current branch to be at your commit. It will also reset the files in the working tree. Be careful. If you have uncommitted changes, they will be lost.
You can reset the last n number of unpushed commits(commited yet but not pushed). Then command you need to use is
git reset HEAD -- will omit the last commit
git reset HEAD^n -- will omit the n number of last unpushed commits.
I'm using Git Gui and Gitk on Windows. How do I undo a hard reset from within the past two hours?
(Is it possible to do this from these applications, without using the command line?)
I saw this SO post, which says that undos are possible before git's garbage collection occurs. I might have quit and reopened one or both of these applications.
If you had changes in your working tree that were not committed when you did git reset --hard, those changes are gone for ever. You have to use your memory (in your head) to recreate them.
Changes that were committed after the commit to which you switched are not lost. They likely have no reference pointing to them, making them more difficult to locate. The tool to list all low-level changes to the repo is git reflog.
After you locate the commit which you want to revert to observe the hash number in the first row and use git reset --hard #hashnumber or git checkout #hashnumber to get the changes.
I found this useful line on http://quirkygba.blogspot.com/2008/11/recovering-history-with-git-reflog.html:
gitk --all $(git reflog | cut -c1-7)
This will display all the hidden changes in gitk, where you can comfortably view, point, click and create new branches.
As you mentioned the unreferenced commits are normally being kept in the repository for 30 days.
EDIT: I have to add stuff here so that my edit is at least 6 characters. I know, sometimes code fixes are less than 6 characters, but there might, after all, be something else to improve in this post.
See the answers by Brian Riehman and Pat Notz in the link in the question.
One solution is to use the command line.
In Windows, open DOS in the directory containing your .git directory.
Type something like the following to see what commit you want to go to:
"c:\Program Files\Git\bin\git.exe" reflog
To go to a certain commit, type something like the following, where the last expression is the SHA1 code of that commit:
"c:\Program Files\Git\bin\git.exe" reset --hard 5eb4080
I don't think you can undo a hard reset to get uncommitted changes back - you can undo a rebase because the blobs are still available, but if you never committed your newest changes to Git ever, anything it overwrote is most likely history. I'd love to find out that I'm wrong though!
Using TortoiseGit (I'm trying to avoid command line usage) how does one delete all commits that accended from a certain commit, and "get back in the past" (example usage: continued doing something, figured I didn't like where it was going, and decided to go "back" disregarding all in between).
In short I wish to go 5 commits "back", and delete them afterwards.
Go to TortoiseGit -> Show log. Select the most recent commit you want to keep, everything above will be erased. Then right click on it and select "Reset "master" to this" and choose Hard. Be careful though because once you do this all the commits after it will be forever lost unless they are stored off in another branch somewhere.
I've never used Tortoise anything (unless you count the electronica group), but I'll give you this info in case you don't find a way to do it with the GUI or you end up deciding to go CLI after all.
As #Tuxified mentions, you can accomplish this with git reset --hard <COMMIT>. You need to specify a commit, which can be done in any of an intimidating panoply of possible ways; the most common have forms like HEAD~4, which specifies a commit 4 commits before the head of the current branch, and deadbeef42, which specifies a commit whose SHA1 starts with 0xdeadbeef42. If you're running linux or OSX, you can get the full details on commit specifiers via man git-rev-parse, under "SPECIFYING REVISIONS".
You can also rename the current branch (git branch -m new_branch_name) and then create a new branch with its head at the place you want to revert to. The advantage is that if you end up wanting to use all or some of the stuff you did there, you can still readily access it; and if you typo the commit, you're saved from a big holycrap moment. Plus git branches are super lightweight so the only real downside is that there will be another branch listed. To make the new master branch you would use git branch master <COMMIT>, and then you check it out. So the net effect here is the same as the first option, except that you still have your old changes saved in the branch new_branch_name. You can even merge those changes back in later, after new commits to master, if you feel like it.
Note that either of these techniques are considered "rewriting history" and will cause issues if you're sharing your repo with others. If you're being smart and pushing to a backup repo in cloud city or another pc, you will have to fix things on that end before you can push to it again.
This is probably way more info than you need right now, but if you end up using git a lot you'll probably want to learn this stuff at some point. Sorry I don't know how to use Tortoise...