Git Partial Staging in Eclipse

Git Partial Staging in Eclipse

When committing changes to your  source control system, it’s considered good practice to only resolve a single task with each commit. There are several advantages to this approach:

  • The history reads like a list of tasks that were accomplished
  • Each commit can be easily reviewed, as it only does one thing
  • Commits can be easily reverted or cherry-picked

However, when working with source code, it’s temping to sneak-in another small change into your current commit. Take the following example:

Screen Shot 2014-06-02 at 10.57.06 PMLet’s assume we want to implement a more accurate method for computing pi. It might also be temping to fix the typo in the computePie() method name.

Screen Shot 2014-06-02 at 10.57.36 PMHowever, these are two independent tasks. If the implementation of the computePi method was reverted (or did not pass code review), I would still expect the typo to be corrected. While I could stash the work I’m doing, fix the typo, retrieve the stash and continue, the overhead of that workflow would likely deter me. With Eclipse Git (EGit) there is a much easier way.

From the staging view, double-click on the file. A compare dialog will appear. On the left are your current changes; on the right is the currently staged work. You can now copy changes from the left to the right, effectively staging parts of your file. In this case I will stage the correction to the method name.

Screen Shot 2014-06-02 at 11.11.26 PMIn a second commit I will change the implementation of the method that computes Pi. Now these two change-sets can be pushed, reviewed, cherry-picked, tested and reverted, separately!

Screen Shot 2014-06-02 at 11.23.29 PM

  • Bananeweizen
    Posted at 10:19 am, June 3, 2014

    Nice trick, Ian. Do you know if your suggested workflow will still play nicely with gerrit as the push target? Typically I avoid multiple dependent commits, and instead switch local branches (or reset) in between such commit series. In the past we often got into trouble when intermediate commits of such series had to be reworked (where gerrit then complains about outdated dependencies).