I been trying to follow this tutorial on using Eclipse and GITHUB when multiple people are writing within the same project using branches. I believe I understand everything and how its working.. HOWEVER.. my hash isn't updating like the video is showing on local branches.
https://www.youtube.com/watch?v=KfeqnernMmE
If you look at minute 3:50 - 3:60 you will see him do a COMMIT and it will then update on the local branch and generates a new HASH etc...(text in grey next to ChangeDefaults in the video) My Eclipse won't freaking do this. I make a change exactly like he does, I do a commit, but my Hash's and comment text (all the text in GREY) don't update or change at all. They same the exact same as it was before and I'm not seeing any onscreen errors or anything.
What am I missing?
Apparently there were 2 things I was doing wrong.
1) I wasn't using the correct Repository when I was modifying things. I had the wrong "Project" open.
2) I was missing an update and had to update my GIT inside my eclipse.
Related
I am trying to jump over my shadow and finally learn git at a basic level. Like countless beginners before me I ran into the dreaded "egit rejected non-fast-forward" error when trying to push after merging in the remote changes and "marking as merged".
It seems like I already found a solution for this problem, but it is cumbersome and not compatible with the eclipse compare editor. I do it like this:
Push my changes - causes the "egit rejected non-fast-forward" error
Pull changes - The compare editor now contains <, = and > markers. I can't comfortably compare and push around changes as the right side of the compare editor is empty and the left contains my changes and the remote conflicting changes above each other, which is pretty useless.
Painfully pick the parts I want by manually editing the text.
Am I using egit the right way?
Is there a way to properly use both sides of the compare editor?
I want to see my version which will be pushed and it's differences to the current remote version at all times during the merge.
I'm not familiar with egit, but it sounds like you are dealing with a merge conflict. Am I right in assuming that someone else also has push access to the branch you're working on? What likely happened is they pushed new changes to the branch, which is what is causing the rejection. And by pulling, you're trying to merge in some conflicting changes that you have to resolve. Here is a better explanation of the same problem.
The bad news is that merge conflicts always have to be resolved manually. The good news is that it looks like egit provides a merge tool for resolving these conflicts. This egit wiki page might help you find the comparison tool that you're looking for. Basically, just select the file that has conflicts and then select Team > Merge Tool
.
If that doesn't work, you can always confidently resolve merge conflicts just by using the git merge markers (<, >, and =). Read this for a detailed explanation of how those are used in Git. Basically, anything below <<< and above === will be your changes. The code below === and above >>> will be their changes. And you either have to pick which side you want, or you can customize it even further. by deleting everything and re-writing the code yourself.
Here's an example. This is something you might see when resolving a merge conflict. The top show you the commit at your local HEAD, your version of the commit. And the bottom, below the === shows the commit at origin/master, the version you just pulled in.
<<<<<< HEAD:test.html
<h1>This is my version</h1>
======
This is their version
>>>>>> origin/master:test.html
To keep only your version, you could just replace that entire block with this. It's like the arrows and equal signs are giving you a choice. Do you want the top (yours), or the bottom (theirs)?
<h1>This is my version</h1>
Alternatively, maybe you want a combination of both. Here, you would be keeping your <h1> html tag, but using their text.
<h1>This is their version</h1>
I hope this helps you feel more comfortable with resolving merge conflicts. If you want to learn more about Git, I always recommend git-scm.
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.
I think I am just merely (coming from an SVN background) confused with how Git conflicts are handled by EGit within Eclipse.
I understand that it shows textually in the normal standard method by which to show conflicts as stated here: http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented however it isn't very clean and with thousands of lines of code it becomes unmanageable to avoid accidently deleting lines that are not meant to be deleted.
Is there any GUI within EGit that can show me each conflict with an step over ability?
I have searched around and I heard about the merge tool however when I follow the instructions by right clicking on the top level node of the tree (i.e. right click models folder that has the <> type icon denoting a conflict, which has a conflicted file of User.php within it) the merge tool is greyed out.
Am I using the merge tool wrong?
Edit
I found out that a bug can cause EGit merge tool to not show: Why is the merge tool disabled in Eclipse for a EGit-managed project? however I am using EGit 1.3.0 so I should be way past this bug.
I have given this question two days both here and on the EGit forums: http://www.eclipse.org/forums/index.php/t/371459/ unfortunately (even after everyone viewed it) no one had a real answer so I decided to solve my conflicts manually and just merge that way.
This way was, in reality, quicker and easier than trying to solve why the merge tools were not working for me, ironically.
I have a problem!
We are working on an iPhone-app and are using git. The problem is that if someone changes something in the project(adds a file and so on..) and i try to pull that change, I have to merge it.
But the merge isn't painless, I often end up getting a corrupt project file and have to spend quite some time just to fix that.
Does anybody have a solution for this problem?
(Sorry for my crappy English)
Project files are notorious for conflicting. I would enable rerere (stands for "Reuse Recorded Resolution") so that if you have to redo conflict resolutions, you can at least have your decisions cached from the previous time you did them. An excellent write up on rerere is located here: http://progit.org/2010/03/08/rerere.html
If you have the inclination, the better thing to look at is an advanced topic of writing a custom merge driver. See "Defining a custom merge driver" in http://git-scm.com/docs/gitattributes
Hope this helps.
Three important steps:
Cause git to ignore everything in the project file except for the project.pbxproj under the .xcodeproj folder - use .gitignore for this.
before you pull a changed .pbxproj close your project. One of the biggest problems you face is that if you get a new version while Xcode has the project file open it can just save its "current" version over the changed one you want.
merges will sometimes result in spurious data like ">>>>YOURS" or ">>>>THEIRS" merge markers getting included in the project file. If you have to merge do it manually with a tool like filemerge where you can inspect each change and choose whether to include it or not.
If all this fails and you get a corrupted project file anyway
accept the version someone else submitted and redo your own changes, it's almost always easier and the link errors will remind you soon enough.
learn the value of frequent commits.
I'm using svn for the first time, to maintain a custom version of Wordpress. I'm using the subclipse plugin in eclipse. The time has come to merge the changes in the latest release of Wordpress with my customised code base.
I have tried creating a branch and adding the new Wordpress release there, then performing a merge. No changes were made however.
Could someone walk me through the setup of project like this? I fear I am missing something basic.
Thanks.
This is assuming you merge from branch (containing the latest version of Wordpress) to trunk (your customized codebase).
(Make sure that you have committed everything you need into branch.)
Team --> Switch to another branch/tag/revision... your working copy to trunk (the target of your merge operation), and resolve any conflicts that come up at this point.
Team --> Merge opens a dialog where you will be performing the merge operation. Change the "From" URL to reference branch (the source of your merge operation, i.e. what you want to merge into your working copy). "From Revision" should point to the revision in branch where you want your merge operation to "start" from - typically the revision that was last merged in from branch to trunk (or most likely the head revision in your case, if you really want to merge just that latest changes in branch).
Set "To Revision" to point to the latest revision in branch (= the head revision).
At this point you are ready to perform the merge - Dry run command lets you preview what will happen during the merge, and Merge will perform the actual merge.
Once the merge operation has been completed, you need to make sure that all changes that were performed against your working copy are ok, and resolve all conflicts.
When you're done with resolving conflicts and reviewing the changes, commit the changes to trunk in a single commit operation. For your own convenience, it is strongly recommended that you add a commit message where you specifically state what this commit is for ( = merging revisions from X to Y from branch to trunk, what was the purpose, etc.).
Hope this helps.
Converting wordpress project to vendor branch procedure
If you are using svn for the first time I suppose you have not started with a clean wordpress copy, branched from there and edited the branched version, have you? ;)
If that is so you might have a problem at your hands.
Background
Unlike "regular diffs" SVN merge does not compare right-side code/folders with left-side code/folders.
While svn merge might fall back to a diff-like mechanism if it does not find a history, I would not recommend relying on that as it can be quite prone to unneccessary conflicts.
SVN Merge is used to reproduce changes that have been recorded in the SVN history. It is like telling a painter "Hey you know how this picture looked before you added that tree on the hill? That Tree was great! Look here i've copied the same base picture but now it's with a sunset. Can you paint the same tree again but on this picture with the sunset?"
The painter might be able to reproduce the tree because he knows how he had done it. He might even have a draft somewhere.
The picture, that is wordpress. The painter, its svn with you commanding it. The tree thats your modifications. The picture now sunset-themed is the newer wordpress version.
What most likely you did is copy wordpress vanilla into your svn, modify it, work with it.
To stick with the picture example, the history would contain commands like "copy whole picture, add tree, add leaves".
Now you bring a new version of wordpress, a new picture so to say and put it besides your older modified version. The Problem is, you human and smart know its quite much the same picture and even though the newer verison is different you just have to copy the tree, SVN does not have that knowledge. For SVN your wordpress 1.7 folder (modified) is completly distinct from wordpress 1.8. They share no history because nothing in SVNs log indicate it. SVN is a bureaucratic snob isn't it? ;)
Now what people do to allow svn to maintain that historic connection between wordpress 1.7, your modified 1.7 and the new 1.8 is they use branching right at the beginning of their works.
So you would start off with a clean 1.7 wordpress in a "vanilla-wordpress" folder, store it in svn and branch it to, say, "my-modified-wp". There you hack away until you feel like updating wordpress from upstream. People then download the latest wordpress copy overwrite their vanilla wordpress and merge the resulting changeset.
In the picture example commands would be these:
"Buy original picture
copy original picture as my picture
draw tree on my picture
draw sunset on original picture (someone else did that for you, aka update)
*reproduce* sunset on my picture too"
You can cleanly reproduce the sunset because you know how the picture looked before the sunset was applied.
Your problem though is that you did not start that way off but edited on your downloaded wordpress right away. So your newer copy of wordpress can not be easily associated with your modified version.
One way to establish history relations
download the **exact** wordpress version you started your project with
Put it into /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.7.1" to tag the import.
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/branches/my-new-modified-wordpress" or whatever your project/WP-edition is called.
Now comes the trick part
Scroll back the svn log of your "old-modified-wordpress". The one that you did not branch. You have to find the first revision AFTER your initial import of the old wordpress. Once you found that revision you take its number and use it in the second of these two commands:
change into a local checkout of "/branches/my-new-modified-wordpress"
issue "svn merge -r **4**:HEAD http://svnserver.tld/repositorypath/my-**old**-modified-wordpress". If 4 was the first revision during which you made own modifications.
You are telling svn the following: "Take all changes in my old branch between revision 4 and NOW and reproduce them on my new branch."
If all works out you should have two identical branches. the old-modified and the new-modified with the slight difference that the new-modified has a solid history with your "/vendor/wordpress/current" branch.
This ancestry allows you to contunously do the following:
Download the wordpress version you wish to upgrade too and **overwrite** /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.9.3" to tag the new version.
change into local checkout /branches/my-new-modified-wordpress
issue "svn merge http://svnserver.tld/repositorypath/vendor/wordpress/current"
profit
This procedure I describe with less storystelling at the link allready. But before it can work you have to establish the ancestry relation between the branches.
Subversion svn:externals file override?
I know it has been alot to read :). If you plan do soem drawing, think of "change commands" not states and you'll be fine.
C