SJGP Software

Source Control or Version Control management tools are a reality of modern development, playing an essential role in helping teams collaborate and helping projects track code-base changes over time. As I have moved from one team or organization to another, I have met different Source Control tools. Whichever one you work with, there is probably an Eclipse plugin for it. Many are good enough that for day-to-day dev work you will never need to use the command line, saving those interactions for the rarer, more administratively difficult tasks. The essential thing is to have a plugin for those day-to-day dev activities, but which one depends on your team's tool. I will touch on some of the best ones here.

This post describes the real-world scenario, then offers the steps to solve the issue at the bottom. If you are in a hurry, jump to the end of the post to see the steps in Eclipse, without my self-indulgent story-telling! A few months ago, my team switched from the ancient Visual SourceSafe to Git. While we tried to minimize the process impact, the change-over was such a big shift in thinking that, months later, I still field several questions a week. Here is a recent trouble-shooting sample: a colleague got caught in mid-task with an urgent fix, and mucked up some commits in her local repository. Her question: how can only the fix-commit be pushed. Email excerpt: Hey Steve! Okay - so I have 2 files that I need to push to repository X for a high priority fix for tomorrow. I have a 3 rd file that I was in the middle of changing when I had to interrupt to get the high priority one fixed and in.  It is currently in a state of flux and full of errors. But when I went...

Actually, 2 tips about Git History view in Eclipse today: (1) Faster loading of History view in Eclipse Sometimes in Eclipse, viewing the History of a file, folder, repository or branch can take several seconds to load. Git promises faster access to the History of source changes because they are local, and this is generally true. But when there are thousands of files and many years of history, including occasional refactoring and restructuring, the History view can lose some of that speed. One simple setting change made our History views in Eclipse faster: In Eclipse, select Window -> Preferences. In the tree-view of categories, navigate to Team -> Git -> History Uncheck the preference for “Follow Renames” Click OK. This made a big speed improvement in our History view’s load time.  But it comes with a cost:

Recently a colleague of mine used the Git Cherry-pick feature to bring one of their commits from one branch of our repository to another. They hit a somewhat complex merge conflict and, in trying to resolve all of the conflicts in the file, they got confused about what needed to be done. They came to see me with the question: can they cancel their cherry-pick and partial merge, and start over? The answer is Yes: it is possible to abort a merge or a cherry-pick Git operation. Most of the time it is not needed; with a little work and human intelligence, the merge conflicts can be resolved without too much trouble. But sometimes, in cases like my colleague faced, a more complex merge winds up confusing the developer, and they want to go back and start over. If you use git from the command-line, it’s as simple as: git cherry-pick --abort or git reset --merge On my team, about a quarter of us use Git from the command line, but most - like my colleague in this story -...

Git can include many files in a single commit. You can modify, add, or delete multiple files, then commit the new state of the working directory. What if we deleted multiple files, and now we need to recover in Git some but not all of what has been deleted? Since Git tracks the state of our repository as a series of snapshots (aka Commits) in time, we can recover the file by looking at a past snapshot / commit and “checking out” the resource(s) we must recover. For example: Let's say that a few days ago I deleted several files from the Git repository. I deleted them on my local, committed the change, and pushed to the server. Other developers have done many other commits since then. Now, it turns out one of the files is needed after all, but the others should remain deleted. How to get the one file back? I will show some Git command-line steps to retrieve it. There are other ways, using your IDE, File Explorer, Tortoise or your UI of choice. But the command-l...

Sometimes, when using Git repositories and the Eclipse IDE, we want to access other remote repositories within the one we are currently using. One example, which I will use as the scenario for the steps below: a team converted existing code and its history to Git from another source-control management tool, with separate repositories for closely related but distinct release points. When they need to make a fix to a past release, on the past release's "hotfix" branch, they want to do as little work as possible to bring that fix into the current cutting-edge "dev" branch of their main repository. Other writers have offered How-To's for the git command-line steps to do so. What I will do is to show how the setup and configuration can be done within the Eclipse IDE (I used Mars for the screen-shots).

Using Git and the Eclipse IDE, you have a series of commits in your branch history, but need to back up to an earlier version. The Git Reset feature is a powerful tool with just a whiff of danger, and is accessible with just a couple clicks in Eclipse. In Eclipse, switch to the History view. In my example it shows a series of 3 changes, 3 separate committed versions of the Person file. After commit 6d5ef3e, the HEAD (shown), Index, and Working Directory all have the same version, Person 3.0.

This is an abbreviated version of a fuller post about Git Rebase in Eclipse. See the longer one here : One side-effect of merging Git branches is that it leaves a Merge commit. This can create a history view something like: The clutter of parallel lines shows the life spans of those local branches, and extra commits (nine in the above screen-shot, marked by the green arrows icon). Check out this extreme-case history:  http://agentdero.cachefly.net/unethicalblogger.com/images/branch_madness.jpeg Merge Commits show all the gory details of how the code base evolved. For some teams, that’s what they want or need, all the time. Others may find it unnecessarily long and cluttered. They prefer the history to tell the bigger story, and not dwell on tiny details like every trivial Merge-commit. Git Rebase offers us 2 benefits over Git Merge: First, Rebase allows us to clean up a set of local commits before pushing them to the shared, central repository. For ...

Note: I led the project to convert a team's Source Control Management tool and processes from Microsoft Visual SourceSafe to Git. This is an edited version of a How-To document I wrote and distributed in response to some questions about Merge vs Rebase in Eclipse. As you know, I’ve been recommending using local Git branches to separate your projects. By that, I mean create a branch from the Dev branch, make your changes and commit them as often as necessary to your local branch, switch branches when you need to switch projects, etc. One side-effect of using local branches is that when you bring your work into the main Dev branch, it leaves a new commit, a Merge commit. This means that, even though we do not have feature branches on the server, we can still wind up with a history that looks like this on the server: We wind up with the clutter of parallel lines showing the life spans of our local branches, and extra commits (nine in the above screen-shot, marked by the...

Let me give a shout-out to Abstrakti Software for a job well done and excellent customer service. My small team recently completed a project to move all of our development work from Visual Source Safe to Git source control management. Our code base was very large, with hundreds of thousands of source files across dozens of VSS projects spanning more than 17 years of history. Preserving the VSS History was one of the project's top priorities, and for that we looked into a handful of tools that were designed for just that purpose.