I program Java using Eclipse and SVN in my company and one of the commit rules it's that each commit have their own purpose, and it's always one.
Sometimes I can get some work done but can't publish it on the server until the end of the day (it will break the build) and then I have to do some other work (non related to the first) and commit it, but if I do that I'm commiting changes related to 2 tasks.
What I want here it's to have a way to say to Eclipse that I want to separate those changes and on both of the tasks I want to work with the trunk code. So, basically it's a branch, but that never existed, in order to let me make separate commits. I thought about having N eclipse workspaces working with the trunk code and use each onde for each change, but that seems overkilling.
Is it doable?
In Intellij you have changelists that you can commit separately. Maybe this question can help you further on your way: Changelists in subclipse
The only way I can think of doing it so that you can make two different sets of changes within a single file is to checkout a second working copy for the second tasks set of changes, and work on those independently. When either task is complete you can commit the changes made in that working copy, and update the other working copy before committing that once it builds.
Related
I know this could've been a question previously asked, but I am not sure it was answered properly.
I am trying to fix merge conflicts when merging to the master branch. So what I did was, I checked out the master branch, did a git fetch, git pull, then checked out my feature branch, and fixed the merge conflicts I needed to fix.
Now, all the files I have fixed will need to be manually added, then committed, then pushed to the master branch. That, I understand.
However, a lot of files showed up in the Changed to be committed section, that are already on the master branch, when I checked the git lab repo.
My question is, am I supposed to keep those and commit them alongside my changes? or should I remove them and just commit and push my changes?
I have tried following this After a Git merge conflict, a lot of files I didn't touch become changes to be committed, but I didn't find it pretty helpful.
If you git diff each file to be commuted with the main branch you should see only your core changes, not the merged changes.
For example: if you are using a tool like IntelliJ, if you right click on an uncommitted file and git compare it with the main branch, only the “new changes” should be highlighted, the merged changes should not be.
So I wanted to try out converting our backend API source code which is written in Java and see how it looks (IIRC there is a preview before converting), but once I did it it automatically started converting all the files in the selected folders, and in the end it asked for code corrections, which I responded with no as I wanted to cancel it and now I am stuck with a broken code base with no other options than:
Reverting to the last git commit and reimplementing all the changes done from my side (I could have prevented it but committing before the conversion but oh well)
Continue using Kotlin to code in but I have code errors which I don't know how to fix
What I am asking instead is if there's anyway to convert Kotlin back to Java in IntelliJ IDEA? Thank you in advance
Intellij has a feature called Local History and it can be used to go back in time for things you did not commit to your source control system. This history is retained until you install a new version of IntelliJ IDEA or invalidate caches. Read more in the Intellij help for the feature.
Your source code constantly changes as you edit, test, or compile. Any version control system tracks the differences between the committed versions, but the local changes between commits pass unnoticed. Local History is your personal version control system that tracks changes to your source code on your computer and enables you to compare versions and roll changes back, if necessary. Local History is always at your disposal, no steps are required to enable it.
Local History is independent of external version control systems and works with the directories of your project even when they are not under any VCS control. It applies to any structural artifacts: a project, a directory or package, a file, a class, class members, tags, or selected fragment of text.
I'm really impressed with the startup time of IntelliJ which is really fast, however, every time I open it when it has started its always doing this indexing which causes everything to slow down, even if previously I have gracefully closed IntelliJ, the next start it will index again, why is that?
IntelliJ may not be the only application using your project working directory.
If you use version control like git, SVN, or hg, or other tools such as code generators that operate on the project, then they will likely not know about IntelliJ(with or without version control-ignored IntelliJ data), and will simply write their changes.
For that reason, the IDE reindexes completion and outline data to be consistent with the code,
Assume I have a class.
package org.my.domain;
public class BestClassEver{}
My Workflow
Through some refactoring, I change this class's package.
package org.another.domain;
public class BestClassEver{}
I commit this to my local repository using git and push it to a remote repository.
git add .
git commit -m "Refactoring"
git push origin master
Another Developer's Workflow
Another developer modifies the class, without pulling my changes.
package org.my.domain;
public class BestClassEver{
private String something;
}
Then commits and pushes to the remote repository
git add .
git commit -m "Some Changes"
git push origin master
Questions
Will Git merge the other developer's changes into the class?
If not, what happens?
Is this workflow something that needs to be coordinated amongst the team?
Git won't allow the other developer to push his changes without pulling.
It will throw an error that both refs don't match and therefore his local branch needs to be updated with the remote refs.
That's pretty much all there is to know about that. If there are changes in the remote repository, unless you do a forced push, git won't allow you to push changes if there are changes in the remote.
EDIT
Once he pulls, if there are any conflicts in the file, the developer will have to correct any conflicts, commit them and only then he will be able to push.
If there are no conflicts, git will automatically merge those changes and the developer will be able to push after the pull.
EDIT AGAIN
I didn't realize that you were moving the file. In any case, running git status would give you an idea as to the state of your local repository after a pull. If there was any conflicts, you'd be able to correct them.
NOTE
On git rebase or git pull --rebase are usually used to give you a much cleaner commit history as they will pretty much will apply any local changes on top of any other changes that were pulled.
On the other hand, git pull and git merge will usually make an extra commit to link the changes on the branches.
For more information take a look at this guide Git Rebasing
It is always good idea to let people work on different parts of program.
Merge or rebase in this case should be fully automatic, but in real world it is always a bit dramatic and sometimes there are some conflicts. Of course, this merge/rebase will be done after server rejects push for beeing non-fast-forward.
When such thing fails, some workarounds include:
Just repeating "refactoring" in the other branch prior to merging;
Converting the work to patch (git format-patch), editing the patch (applying that "refactor" to it) and applying the edited patch (git am). It is like manual rebasing.
I think it's better to separate merge-complicating refactoring (one that involves renaming, for example) and usual minor refactoing.
Sometimes for a merge-complicating refactoing a script can be written (such as find -name '*.c' -exec sed 's/something/anything/g' -i '{}' ';'). The script be used to repeat the refactoring multiple times in various places when we need it, so avoiding to merge refactored code with non-refactored one.
YES. Git is able to identify those changes. I am working on a project using git on my own fork (forked from origin). In the meantime another developer refactored the codebase on the original fork, which includes changing package structure.
I used the following commands:
git stash save // this saves all your work onto a personal stash
git pull // fetches all the latest changes on the primary fork and merges
git stash apply stash#{0} // or whatever the stash is where you saved your personal work
Now you will have the refactored codebase+your changes. You can now commit without any conflict and the packaging will not be changed.
Just note that in my case I waited for the original fork to be refactored and then I committed my changes, which are only changes to few files and not repackaging.
Also note that if you have added new files, then you might have to edit a few imports to make sure the imports are correct.
eg. import org.my.domain;
should now be edited to: import org.another.domain;
So I'm making some changes/fixes to someone's subclipse mod and had a few questions.
First, I noticed that an svn commit fails when trying to commit a single file that is identical to the existing one in the repository. (And returns -1 for the revision #) Makes sense.
Does this happen if you commit multiple files, only some of which have no changes?
Is the best way around this to just do a diff (on every file?) before attempting to commit?
If anyone knows, that'd be great. Or if you can point me in the right direction? (My google-fu failed me)
If the file is identical, SVN will not commit it. If you provide a list of files, the ones that are identical will just be skipped. I assume you are working with the SVN API and not Subclipse GUI or command line client as you do not see a -1 in either of those.
If you are 100% sure the file is 'identical', then the quickest solution would be to do a 'revert' on the troublesome file (by right-clicking on the file then selecting 'Team' then 'Revert'). Subversion does 'atomic' commits, ( What is the value of atomic commits in Subversion? ) , which basically means if one commit fails in a batch commit, then they all fail.