How can I show parallel branch lines in IntelliJ git logs?
This is my old project and it shows like that.
In my newer project although I have multiple branches merged to master already, still, that beautiful view isn't there, it's just the straight line appearing.
Is this an IntelliJ bug or I don't get when those lines gets showed?
Judging by the screenshot, the history of your repository is just linear - there are no commits that have more than a single child - that is why no other branches are in the graph.
Branches in git are in fact just a reference to a commit. So several branches can be referencing the same commit without producing any branches in the graph. This seems to be the case.
Intellij has a plugin named GitHub, if you install it (from settings -> plugins)
you will have a 'git' tab at the bottom, inside that tab you will see the GUI you are referring to
Related
An Intellij Scope can be used to restrict the files analysed during "Inspect Code".
Question: Is there a way to define a scope from the files that differ between two commits or between a commit (or branch) and the current working directory?
This would simplify finding problems freshly introduced in a feature branch and would be particularly helpful for old code bases where running the inspections over the whole project generates too many unrelated findings.
Note that the Scope "uncommitted files" does not help a code review with several commits on a feature branch.
There is a feature request for it, please feel free to vote:
https://youtrack.jetbrains.com/issue/IDEA-145053/Run-inspections-for-the-scope-of-selected-commits
In a simple IntelliJ module, I just want to generate a .jar file with my .class files, via IntelliJ IDE commands.
Please be careful before marking this as a "duplicate":
Although I've seen Google and Stack hits with promising titles, I'm not finding a really good answer, or the title is misleading, or its an unanswered question. I cover one possible answer that I've seen before (below), and why I don't think it's a match.
I've used Eclipse in the past, but I'm rather new to IntelliJ.
I've worked with the "Project Structure / Artifacts" stuff. I can generate the giant jar, similar to using "shade", but it's huge because it includes all the nested dependencies. We want the small jar with just this module's class files because the system we're deploying to already has all the other jars in place.
I've seen some references to changing a target directory in the Artifacts dialog box, but it then talks about references being made in the Manifest file, which I don't want. The destination environment already has its java paths setup, so I'm worried that having jar references in this jar will mess that up. If this really is the answer then I'm confused about how it works.
Constraint 1: Can't use command line tools, since I'm actually walking somebody else through these steps, who likely doesn't have command line tools installed in the path, or wouldn't know how to use them, etc. They're not a coder. (Yes, I know this sounds like an odd scenario; I inherited this situation.)
Constraint 2: We want to keep this as a simple IntelliJ project, vs. converting to Maven or Ant or Gradle, etc.
Coworker had the fix.
Short Answer:
Remove all of the other jars/libraries from Output Layout tab of the Artifacts config dialog.
Longer Answer:
You still do File / Project Structure...
Then in the Project Settings, click Artifacts.
And then you still click the plus button (second column) ti create a new artifact setting.
The trick is the "Output Layout" tab in the third column of the window. Highlight all entries EXCEPT the compiled output of your project and delete all those other entries (click the minus button under that tab, directly above your_project.jar)
On my laptop this causes it to pause for a few seconds; I thought it didn't do anything, then finally it reflected that everything was gone except "'my_module' compile output"
Also check the "Build on make" (for when you later do Build / Rebuild Project)
If you need both a full jar and a slim jar, you can have more than one Artifact configuration with different names, and they will default to different output directories.
There are often conflicts in the Xcode project file (Project.xcodeproj/project.pbxproj) when merging branches (I'm using git). Sometimes it's easy, but at times I end up with a corrupt project file and have to revert. In the worst case I have to fix up the project file manually in a second commit (which can be squashed with the previous) by dragging in files etc.
Does anyone have tips for how to handle merge conflicts in big and complex files like the Xcode project file?
EDIT-- Some related questions:
Git and pbxproj
Should I merge .pbxproj files with git using merge=union?
RESOURCES:
http://www.alphaworks.ibm.com/tech/xmldiffmerge
http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge
http://tdm.berlios.de/3dm/doc/thesis.pdf
http://www.cs.hut.fi/~ctl/3dm/
http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/
Break your projects up into smaller, more logical libraries/packages. Massive projects are regularly the sign of a bad design, like the object that does way too much or is way too large.
Design for easy rebuilding -- this also helps if you're writing programs which must be built by multiple tools or IDEs. Many of my 'projects' can be reconstructed by adding one directory.
Remove extraneous build phases. Example: I've removed the "Copy Headers" build phase from all projects. Explicitly include the specific files via the include directive.
Use xcconfig files wherever possible. This also reduces the number of changes you must make when updating your builds. xcconfig files define a collection of build settings, and support #include. Of course, you then delete the (majority of) user defined settings from each project and target when you define the xcconfig to use.
For target dependencies: create targets which perform logical operations, rather than physical operations. This is usually a shell script target or aggregate target. For example: "build dependencies", "run all unit tests", "build all", "clean all". then you do not have to maintain every dependency change every step of a way - it's like using references.
Define a common "Source Tree" for your code, and a second for 3rd party sources.
There are external build tools available. This may be an option for you (at least, for some of your targets).
At this point, a xcodeproj will be much simpler. It will require fewer changes, and be very easy to reconstruct. You can go much further with these concepts to further reduce the complexity of your projects and builds.
You might want to try https://github.com/simonwagner/mergepbx/
It is a script that will help you to merge Xcode project files correctly. Note that it is still alpha.
Disclaimer: I am the author of mergepbx.
The best way I have found is to instruct Git to treat the .pbxproj file as a binary. This prevents messy merges.
Add this to your .gitatributes file:
*.pbxproj -crlf -diff -merge
To compare two Xcode projects open open FileMerge (open xcode and select Xcode (from the manu pane) --> Open developer tools --> FileMerge).
now click "left" button and open xcode project main directory.
click "right" button and open xcode project main directory to compare.
Now click "merge" button!
Thats it!
Another option to consider which may help to reduce the number of times you experience the problem. To explain, I'll call the branch that team members' branches come from the "develop" branch.
Have a convention in your team that when the project file is modified, the changes (along with any other changes required to ensure the build integrity) are committed in a separate commit. That commit is then cherry picked onto the develop branch. Other team members who plan to modify the project file in their branch can then either cherry pick into their branch or rebase their branch on the latest develop. This approach requires communication across the team and some discipline. As I said, it won't always be possible; on some projects it might help a lot and on some projects it might not.
I have a large Flash Builder project that is part of a much larger (.net) solution. I typically have, for the entire project, a forward dev branch going, as well one or more bug fix branches. What is the best way to set this up in Flash Builder, given that Flash Builder does NOT want to import an new project (bug fix branch) that has the same name as an existing (forward dev branch) project?
The best way is understand the workspace limitations. Eclipse doesn't accept projects with the same name, is an old problem. I could say you, isn't only eclipse, but a lot IDEs have such problem and bugs about it.
We want a create a project, production, what is the current stable version, at least one bug test and the next project version. Then, in this Eclipse case, you should name it to something like ProjectNameProd, ProjectNameBugFix and ProjectNameNextVersion. It's also good for browser files by path, as you have the folder saying what is inside.
You can put all in one SVN or GIT repo, or create one repository for each one of these contents. Then, configure the Eclipse/Flash Builder to use SVN, follow this well explained.
Another, not well, approach is set one project and all your targets but it is really a mess to organize and keep things separated.
Hope help you.
I am using cruise control to constantly check my projects and so far it appears to be working better than continuum except for some minor issues.
If I have a project that depends on several other projects and I update one of those dependencies without updating its version number thus requiring no change in the parent pom, the parent will never get rebuilt.
Is this possible, or should I just go back and keep incrementing the pom after each change then make the corresponding changes in the parents as needed?
I was hoping this would be done automatically (if cruise control had tighter maven integration), so that I would magically know this change broke something downstream.
I am guessing my new format will probably be:
${date}.${buildNumber}
2009.12.18.1
Thanks,
Walter
If your projects are in a parent->child relationship in maven, building the parent should also the build its modules with the newly resolved dependencies everytime if you are using the install goal.
Based on your description, it sounds like you don't have a parent project with modules but instead of a handful of separate projects with dependencies between them. In this case, I would suggest you do two things
Change the versions in top level of your poms and in your to include -SNAPSHOT on the end. This forces maven to check for new versions of any dependency in a specified timeframe - daily by default. This behavior can by altered by specifically changing the updatePolicy for your repositories - you can have it check every single time if you wish. When it comes to tag and then build/release your projects, you'll want to remove the -SNAPSHOT qualifier for the release, and then re-add it back in after incrementing your version number to support your next development cycle.
In your CI server, you can force projects to build in succession. Since it looks like you switched to Hudson, it should involve setting up build trigger based on the completion of another project just like you'd like add a trigger for scm polling.
Unfortunately I don't know enough about cruise control to directly answer your question.
However I have had positive experience with Hudson. Hudson is widely used as a CI server, is free, and has excellent Maven integration plus handles what you describe perfectly.