Suppose I made changes to a file a.java in repository repo1 and committed my changes to a local branch branch1. Next I came to know that I can not directly push my change to repo1. Rather I have to fork the repo and then create a branch and PR from there. So now I forked repo1 to repo2 and created a branch. origin/branch2 and checked it out. Now how can I compare the file a.java from repo1 branch branch1 and bring the changes to repo2 branch branch2? It would be nice if I can do it in Intellij.
If the file is visible from your local repository (as in the other two repos are set as remotes) then git doesn't care.... you can provide the path to the two files and it will diff them (it really doesn't require any relation between the files... it can be 2 completely different projects altogether):
git diff repo1/branch1:path-to-file repo2/branch2:path-to-file2
That should work.
Now.. getting one IDE to do that kind of stuff? I don't think you will be able to pull it off. Might need to consider checking out the file from one branch to your local branch so that then you can pick the parts you want to keep and the ones you want to discard:
git checkout repo1/branch1 -- path-to-file
Or
git show repo1/branch1:path-to-file > path-locally # if the files do not have the same path in the 2 branches
Then feel free to check the things you want to keep on the IDE.
important
I am assuming your working tree is clean and you have no pending changes on the files you want to play with.
Related
I am having an issue while renaming a package and then pushing it to git remote repo. I used Intellij > Refactor > rename to rename the package, in local Git status is showing as renamed file but in github when raising a pull request it is showing that old package as deleted and new package as added.
How to resolve this and tell git to consider them as renamed ?
Example:
com.test.examplePackage ===> renamed to com.test.examplepackage (we have almost 500 files in this packge)
Now github is showing
com/test/examplePackage/Xyz.java -- deleted
com/test/examplepackage/Xyz.java -- added
Instead of com/test/examplePackage/Xyz.java ===> renamed to com/test/examplepackage/Xyz.java
Similar question has been already answered here:
How to make git mark a deleted and a new file as a file move?
In short, Git will consider the file/directory deleted if the content was modified beyond certain treshold. For this reason you may want to do separate commits for just renaming, and separate for changing file content inside.
Another factor that may be relevant in this case, is that when merging using squash your separate commits are bulked into one, which may explain the different behaviour locally and in github - commit squashing may be turned on by default in your repo.
I'm a beginner when it comes to version control. I've cloned a repository and started working on it, also for versioning am using EGit on eclipse because it's much easier.
So my problem is when I try to add the existing local git repository (Git Repositories -> Add an existing local repository to this view) to eclipse it says that no repository found (screenshot below). I think the reason is that he didn't find the .git folder on the project directory, because somehow the .git folder disappears and just after that I faced this issue. Maybe some of you will say that I need just to clone again the project and copy the .git folder and put it on the existing project, but the problem is that the remote project received many commits after my first clone, so can that affect my local project?
Thank you :D
click here to display the image
Clarification about .git folder
Without a .git folder you have not really a git repository!
The folder contains all repository data.
So your "repository" is currently only a normal file structure and has lost all git information - it's only the last working copy.
Wanted
As far as I understood, you want to apply your changes to the repository (and maybe later create a PR to origin/remote one...) but you lost the git data completely and you want to fix this.
Suggestion
Maybe you could do following
clone the remote repository to another, new location at your machine
checkout same branch where you formerly did your changes
search for the exact commit id where you started your uncommitted changes
(it's important to exactly checkout the same commit as before, so you have no merge problems later)
do a "git checkout $commitNumber"
now create your own branch from this point
(At this point we are on the same position as when you started your
former local changes - means same base)
copy files from your old location (containing your changes) recursively
into the new location - but ensure relative pathes do match!
(so GIT will recognize file changes as diff...)
open your Eclipse IDE
try to add the new location as an existing local repository inside
Eclipse
(this will work now)
open the "Git Staging" view
Now you should see your delta to your own branch, means your changes.
add your changes to index and commit them to your branch
merge your branch into wanted target main/master branch
IMHO this should solve your problem.
I am using git for the first time and I am trying to make a commit. I want to ignore all .project and .settings files so I went to my .gitignore file and added .project, .settings and saved. When I did that the .settings file doesn't appear anymore, however, I still see my .project file when I do git -status. Also, why is the .xml and java file in a different section that the .jar files:
Your git status output is showing you two types of files:
Changes not staged for commit
These are files which Git is tracking, and these files have been modified since the previous commit. But, the changes have not yet been staged. Unless you stage the changes using git add, they will not be committed. Here is how you would stage the change to the web.xml file:
git add path/to/web.xml
Assuming you really just started working, then the most likely explanation for why the .project is showing up as being tracked by Git is that you somehow added it. To fix this, you can try using:
git rm --cached .project
This removes the .project file from being tracked by Git. It would also remove it from the remote repository, but since you just started working and haven't pushed yet, this is a moot point.
Untracked files
These are files which Git is completely ignoring. From Git's point of view, these files are not there. I can see that you have a number of JAR files listed as untracked, which is probably a good thing, since in general it is a bad idea to add binary files, especially dependencies, to your Git repository. Should you see a source file listed as untracked, you could also run git add to add that file to Git.
The reason it is generally considered bad practice to add binaries to a Git repository is that Git doesn't handle diffs of binaries very well. Suppose you add a 1MB JAR file. Each time it changes, which could be fairly often if you are doing some open source stuff, a diff has to be stored for that binary. But, Git often will interpret the diff as being deleting the old file and replacing it with the entire contents of the new file. In other words, Git basically versions the entire binary for each change. Over time, this can cause your repository to become large and bloated, and it can be difficult to get rid of those binaries from your history. So, unless absolutely necessary, avoid storing binaries in your Git repository.
what I'd like to do is have files in a central location so that when I add people to my development team they can see the base version of these files but meanwhile have the ability for the rest of the team to work with their own local version.
I know I can just put the files in source-control (we use Tortoiese-SVN) and have my team change the local versions but I'd rather not as the exclamation mark signaling the file has been changed and needs to be committed, quite frankly, irritates me greatly.
I'll give two examples of what I mean:
We use quite a few build.xml files which relate to a single properties files which contains many definitions. Some of them can be different between team-members (mainly temporary working directories) and I'd like a new team-member to have the ability to get the properties file with the base config but change it if they wish.
Have the eclipse settings file in the SVN so that when a new team-member joins they can just retrieve the files from the server and have a base system running. If they wish they will be able to change some of these settings.
Thanks,
Ittai
What I have done in the past is having the file in a different location or with a different name inside the repository with an ignore real_file rule so that the subversion will not complain on the changed file, and have a small script that will copy the files to the concrete location.
For example, the .project Eclipse project file can be named eclipse-project-default in the repository. When a user downloads the local copy they run the script and they get a fresh .project (copy of eclipse-project-default) that they can change and will not show in the subversion status command.
The problem with this approach is that it is often easy to make a change to the file that should go to the central repository and is forgotten. The approach requires changing the actual file, and applying the same change to the config file that is actually uploaded. And then commit that change.
This really is a case for version control as you point out, but having said that I guess you could put a copy in a central file server and have them download it from their. You may even want to make this a read only file or directory.
If the status indicator bugs you that much you can set this file to be ignored by your version control system.
There is a project in Java where I work.
To have the project in Mercurial I know that I have to make a repository for all the classes.
As there is a lot of classes I think if maybe I can have a copy of a jar made of a copy of the repository plus the modifications I have to do.
So in Mercurial terms there is:
A main repo with all the classes
A litle repo with modifications and new classes
I want to do merge from B repo to A repo. And then I want to pull and update only the classes (*.java) that exists in my B repo.
I have tried unsuccessfully this:
To create B repo I clone A repo and
I delete all the files.
When I have to modify a .java I do a
wget of the particular file the
mercurial server in my local
machine. When the file is new I just
run hg add.
To do the commits I do hg commit -I
file1 -i file2 ... -i fileN for all
the files existing in the working
folder of B repo.
Then the unsuccessful part:
I can´t do a hg update only of the
existing files.
When the B repo is merged in A repo
it's all ok. But I can't run hg
commit of a merged state with -I
parameter. Its all or nothing.
When I pull from A repo and I try to
update I have the same issue 4.
I am aware of hg pull -f for start with a unrelated repo for B repo instead of a clone. But it has the same issue of the update. And it looks pretty ugly.
I think that transplant plugin it may help. I also read this How to combine two projects in Mercurial?.
Preserving the history of files in A Repo is a must, even if this history was generated in B Repo.
Do you know the best way to achieve this?
thanks
What you're looking for is called a Partial Clone and it isn't supported in mercurial.
Honestly, your workflow sounds pretty broken -- creating a subset repo and trying to keep it in sync is fighting against how the tools were intended to be used. Why not just build the jar you need from the full-repo but including only specific classes in the ant (I hope) <jar> tag. We have a repository with thousands of classes and the build all outputs many different jars each of which is a subset of the whole universe of classes.
That said, if you must stick with your current workflow you should modify it. Do not clone the full repository and then delete the files you don't want, because you're still including their full history.
Instead, use hg convert (the Convert Extension) to build your sub-set repository using a filemap and the --filemap option. Using both a source repository type of hg and destination type of hg you can use the filemap to include only the files you want. You'll end up not with a clone, but with a completely new repository, with all the original changesets, but only for the files you've specified. Using convert's built-in incremental mode would make converting only new changes from the full repo possible as a sort of update.