Here is the context:
I am using egit within Eclipse
I made a number of commits that I have not pushed to the remote repository
I suddenly notice a bug with my app that wasn't there before
How can I quickly update my working directory with earlier git commits until I find the first commit that introduced the bug? How do I then get back to my latest local commit?
I used hard git resets to do this recently and would have lost my last set of git commits if I hadn't found this answer so there must be another, safer way to achieve the same result.
I am running into a bug in my latest version of the code and want to go back in time until the bug no longer shows up.
That is called git bisect, and is not implemented in Egit.
You should consider using git in command-line, in order to launch a bisect session.
I just figured out the answer to my own question.
It's actually quite simple:
Do git checkout of earlier versions until identifying the last version that does not exhibit the bug and the first one that does
Then do a git switch to the master version to go back to the latest committed version
The checkouts are not intended to make further changes to the code but are quick and useful for updating the working directory without messing with the git directory, which is all what's needed to quickly pin-point the appearance of a new bug in the git tree.
Related
Getting this issue in spring tool suit while fetching/pull latest changes from remote branch. i don't have git bash on my local previously it was working fine right now i am getting below mention issue.
Couldn't lock local tracking ref for update
I also encountered same problem
But I removed this problem using GITHUB Desktop tool.
Once I executed pull from STS, its showed the dialog box with error as shown above. and a up arrow got appended showing there are some commit to be pushed,
though I had not made any commits before this pull. The changes from pull were not added to my local project.
I checked on Github Desktop, and it also showed same arrow.
I pushed it from tool, and it was resolved. The changes from pull got added to local project.
While you don't have git bash, Eclipse is using its own JGit (java-based implementation of Git)
As recommended in "egit lock fail eclipse", do check if you have any "<refname>.lock" file under .git/refs/". (howlger refers to eclipse issue 417860:
I checked in jgit and egit sources and found that the only occurrence of the text "[lock fail]" is used when fetch fails to update a remote tracking branch.
This can happen if a previous crash didn't cleanup a "<refname>.lock" file which git creates as a lock to guard the ref against concurrent updates.
git remote prune origin
solved same problem for me
The case:
Locally, I have a commit where I have deleted a file. Remotely, someone else have changed this file.
Now, when I merge, I find that git has the put the changed file in my working tree. This is probably the way git works, and in git command line, I'd be able to use git mergetool to choose between the deleted or changed file.
In eGit, however, how would I make this choice?
We ended up with a quite unusable work-around where we first addded the file to the index and then deleted it in working tree and then saved this change (deletion) to the index.
Technical info:
The version of eGit (feature) we're using is 4.9.2.201712150930-r.
The version of git we're using is 2.16.1
Background:
My team have recently moved to using Git as our revision control system. There's a general wish from team members to use an integrated solution and since we're working with Eclipse, eGit seemed to be the way to go.
I would suggest that all your team members follow this process:
Commit your changes to your local repository.
Pull with rebase to merge with the remote origin branch.
Resolve the conflicts, if any. In your case, if you deleted the file before the other team member modified it, then that person would have noticed that the file has been deleted.
Push the commit upstream.
This process has worked for us. Hope this helps.
We recently moved to git from svn (both using Eclipse). I am in the (perhaps bad) habit of writing my Java code first, getting everything to work and then going back and adding comments. In SVN this was easy. I would just create a Fisheye review with my Jira task. The review would have a list of all the files I changed and methods I added or modified. I would note it and abandon the review. Then I would edit all the files listed and add the comments.
However, Fisheye does not (I believe) work with git. I could do a git status to see the files I changed but the local branch is already updated so it will not list any files. And all it does is tell me I am something like one commit ahead of the remote branch but does not list any files.
Is there some way to see a lit of the files I have changed with git so I can add comments? And when I say I wait for my comments I really mean mostly for added classes and methods. If I do something like add a line or two to a method I will generally add the comment too.
changing comments on git commits is not that easy. Each git commit has a sha-checksum which also includes the previous git commit. If you change a commit you change the current commits sha-checksum. therefore you create a new commit. All following commits of your branch must now be rebased on top of this new commit.
The command line provides the git rebase -i [commitid] where you can do lots of modifications including changing comments on commits. I never did this with a GUI but egit might support that too. Just refer documentation on egits rebase feature.
I found out how to do this.
The "Synchronize Workspace" in eclipse appears to show all the changed files not yet pushed remotely. I have not done any pushes, so this showed me what files changed.
Working in Eclipse with EGit. We have code on GitHub. My collaborator pushed changes to GitHub. I can see them on GitHub. When I try to do a fetch, EGit says everything is up to date. However, when I do a Synchronize Workspace on my local machine, it does not show the changes that are on GitHub. Someone suggested that perhaps the changes had already been fetched, which seems rather mysterious to me, but I want to check out that possibility. I cannot find any way, though, to show the fetches that have been done. Is there a way in EGit to see what has been fetched, short of merging it? Or failing that, a command line git command?
In my iPhone app, I am using the in-built Git repository of Xcode 4 so that all the team members can work on the same project.
Now the problem is that even after I commit my changes to the repository, It still shows modified (M) symbol in front of the committed file.
What could be wrong?
I want to ensure that once I commit the changes it should not show "M" for that file.
Is there any setting which I have to do to make it work fine?
What can be done?
The built-in Git repository is a local repository only. How do you share that with your team? If you hooked that repository to GitHub, for example, you will experience problems as the implementation is not 100% reliable. I would use the command line in this case and git add/commit/push the changes. There are discussions and tutorials in the GitHub Blog.
Without knowing what you're doing in Xcode, or how you have set up your repository all I can say is that you should check the status of your repository in the command line. Maybe your commit fails for some reason and you're not seeing the message in Xcode.
Try git status to see what state your repository is in.
Try git add <your files> and then git commit to see if you can actually commit your changes.
Did you stage your files before committing (git add)? Otherwise the commit will do nothing.
You would need to Push the changes in Xcode 4 to remove the "M" or modified status. If you don't have the command line mojo like most people, you can just use the functions built in as they were intended.
It won't solve your issue of sharing as it is only a local repo. I'm finding that even using Xcode 4 with an outside repo, you need to learn some command line stuff or it just isn't going to work, or at the very least kick your butt enough to make you consider giving it up.
*edit
Just to make it clear, the process for Xcode 4 is as follows:
File-->Source Control-->Commit
File-->Source Control-->Push