I'm using Source Tree, and I ran into extremely weird bug:
I have a problem with a "ghost" unstaged file to commit, that just wont go away:
When I try to commit it it does nothing, it wont even move into staged files.
It shows even right after downloading into a brand new repo from remote where the bug is not present.
I tried clearing all cache with Ccleaner, did not help. I also just deleted the file, which fixed the issue, then I returned the file back (without any changes), and the ghost commit returned...
It's super annoying, as it wont let me leave any branch I create, keeps on telling me I have uncommited changes even though I do not.
The change that keeps on poping up is very simple thing that was already implemented into remote. I would provide any more detail or info but not sure what to post. This is how it looks like, ALWAYS after a fresh branch is created:
Any idea how do I make this thing go away? It drives me crazy, thanks
EDIT:
Found the main problem, I had the same file twice on main remote, one capitalized the other one not: https://prnt.sc/pe6nwz Damn...
Related
I meant to stash my changes so I could see what my project was like before my changes, but when I went to bring it back I had accidentally overridden my stash. Not sure if it can be brought back.
I tried 'git fsck --unreachable', but there is a lot to sort through and I didn't see it anywhere
Up late trying to fix it, any help would be appreciated so I don't have to pull an all-nighter to redo my work.
Eclipse Jave EE IDE for Web Developers
Luna Service Release 2 (4.4.2)
Eclipse EGit 3.4.2.201412180340-r
So I am merging between two Git branches in Eclipse, something that I have done dozens of times without incident.
This time, for some reason, conflicts were detected. I'm not sure why. But nothing I do in Eclipse lets me get rid of them. I've used the "merge tool". It let me manually move over all the changes to just the way I wanted it to be. Saved the file, conflict did not go away. Won't let me add to index. Won't let me commit. Tried the Team Synchronizing perspective, with its "Mark as Merged" function. This had no effect, although I remember it fondly from the "bad old svn days".
Many outdated web pages exist which tell me about >>>>> and <<<<< marks. None of these are to be found in my file.
How do I get to the bottom of this? Short of deleting the project from Eclipse and recloning it from the Atlassian stash it remotes to, how can I get out of this catch-22?
Update: answered my own question. see below.
Yup, it's definitely a bug in the eclipse git tooling.
After all this, I came upon Eclipse EGIT - all committed, pulled, merged, marked as merged, still on push I get "rejected - non-fast forward", what am I missing? and tried the solution referenced there. This was partially effective. I went straight to editing the conflicted file, and found the >>>>> and <<<<< marks. I was able to edit and save the file, and when I added it to the index, the marks went away.
But there was still a problem. My file contained both changes that were marked as conflicting and changes not marked as conflicting. When I edited the file directly ONLY the conflicted changes were in the file. The non-problematic changes did not make it into the file. To get those I had to do a manual compare of workspace with branch and move those over.
Sheesh.
So here is what we have.
The "merge tool" is worse than useless for conflict resolution. It strips out the >>>>> marks which makes manual editing difficult. Also, "Team-->Add to Index" doesn't work after you use the merge tool. Don't use it! At least until a fix is released.
Manual editing would work if the non-conflicting changes were added to the file.
Beyond this, there shouldn't have been a conflict anyway. The "conflict" amounted to a blank line vs. a section of new code. If the differencer can't figure that out, that's a problem too.
Oops, from the history view, there is Reset-->Hard Reset. That gets me back to pre-merge. I feel dumb for having posted this question but will leave it up in case someone else hits this.
A colleague of mine was working on a VS project this morning, which he claims was in a folder clone of our central repository. He built a release version of the application which is still there with the correct date/time stamp on it.
He then said he committed several times during this time, but at some point, he tried pulling down changes from the central repository and merge them in with his changes. He can't really remember what steps he took, but the end result is that all the changes he did to the source were lost. now, i'm trying to help him to see if we can recover any of those changes.
He told me after he committed his changes (several commits), He went into the tortoisehg workbench, pulled, and saw that there were many changes in the central repository. He decided to either "Merge with local" or "Update" to the tip pulled down - he can't remember which. I showed him the two dialogs, and asked him if he discarded changes, shelved or anything else. He couldn't remember, really, but he did remember he had to back out because tortoisehg didn't like what he was doing. Eventually, he did seem to be able to update to the repository tip.
I'm thinking that unless he physically deleted the folder in which he was working, and then got the latest, those commits he claimed to have done would have been recorded somewhere? What are common errors people do when pulling the remote repo? Are there any log files or history i can check to see if i can salvage or at least tell where he was working on this stuff?
any hints to troubleshoot this would be greatly appreciated.
First of all backup the tree somewhere including .hg and everything under it. Then...
hg heads
...to see if he's just lost track of his commits. If it's there, it's just a case of updating back to it and doing a proper merge.
hg log -u 'His Username'
...to see if the commits are anywhere in the repo. If they're are there you can then work forward from them.
hg shelve --list
...to see if he's managed to shelve things somewhere
Take a look in .hg/strip-backups, to see if he's managed to strip his changes somehow. Anything else destructive should have left backups in .hg too.
That should be a good start. If none of those give any clues then others may be able to suggest some things.
I don’t know about TortoiseHG, but usually the first thing would be to check hg out.
This is the second time this has happened to me, and I don't know what's happening. I have a Git repository that I manage within Eclipse using eGit. I've been working with this repository steadily for months. Suddenly the repository is no longer available in the "Git Repositories" view. I try to add it back using the "add" utility. The dialog sees the repository, and allows me to select it, but it never adds it back to the view.
The last time this happened I had to complete remove my project, the folder, and add it from remote from scratch. I really don't want to have to do that again. Any suggestions?
That view should be reading the contents from a file.
workspace/.metadata/.plugins/.org.eclipse.core.runtime/.settings/org.eclipse.egit.core.prefs
Perhaps check its content to see what's in there, perhaps the path that's being stored has been corrupted or something.
Our team has noticed that CVS brings back deleted code if you have changes in your working file within the block of code that has been deleted. CVS does this silently without presenting the merge conflict markings.
Does anyone have a work around for this?
Is there a clever way to detect that this is about to happen?
From your description, it's unclear what is happening.
If one developer deletes a chunk of code from file X, and another developer makes changes in the middle of that deleted code, and that's all that happens, then I'd be very surprised if CVS was silent -- not that it couldn't happen, but I've never seen it happen in 10+ years of using CVS.
It is possible, because of the way that CVS tracks edits, that major changes could make it think that developer #2 added the code into a completely different location. Particularly if developer #1 makes several commits before developer #2 does an update.
The best work-around is probably to check the status of files before taking an update. You can do this with the "-n" switch:
cvs -nq update -P 2> /dev/null
If you see that a file you've changed is going to be updated, then you can take a closer look at it.