Can I commit only parts of my code using SVN or Mercurial?

Question

I use Tortoise SVN usuallly, but I have been looking into Mercurial since it is a distributed revision control system.

What I am looking for, in both systems, is a tool that let me pick only parts of a file and commit them. If I want to do this now, I have to copy to a temp version of the file and keep only the changes I want to commit in the current version, and then copy the temp version to the current version again after committing. It's just such a hassle and the program should be able to do this for me.

I heard Git supports this, please let me know if this is correct.

Answer 1

Mercurial can do this with the record extension.

It'll prompt you for each file and each diff hunk. For example:

% hg record
diff --git a/prelim.tex b/prelim.tex
2 hunks, 4 lines changed
examine changes to 'prelim.tex'? [Ynsfdaq?]  
@@ -12,7 +12,7 @@
 \setmonofont[Scale=0.88]{Consolas}
 % missing from xunicode.sty
 \DeclareUTFcomposite[\UTFencname]{x00ED}{\'}{\i}
-\else
+\else foo
 \usepackage[pdftex]{graphicx}
 \fi

record this change to 'prelim.tex'? [Ynsfdaq?]  
@@ -1281,3 +1281,5 @@
 %% Local variables:
 %% mode: latex
 %% End:
+
+foo
\ No newline at end of file
record this change to 'prelim.tex'? [Ynsfdaq?]  n
Waiting for Emacs...

After the commit, the remaining diff will be left behind:

% hg di
diff --git a/prelim.tex b/prelim.tex
--- a/prelim.tex
+++ b/prelim.tex
@@ -1281,3 +1281,5 @@
 %% Local variables:
 %% mode: latex
 %% End:
+
+foo
\ No newline at end of file

Alternatively, you may find it easier to use MQ (Mercurial Queues) to separate the individual changes in your repository into patches. There is a MQ variant of record (qrecord), too.

Update: Also try the crecord extension, which provides a curses interface to hunk/line selection.

Answer 2

Yes, git allows you to do this. The git add command has a -p (or --patch) option that allows you to review your changes hunk-by-hunk, select which to stage (you can also refine the hunks or, edit the patches in place). You can also use the interactive mode to git-add (git add -i) and use the "p" option.

Here's a screencast on interactive adding which also demonstrates the patch feature of git add.

Answer 3

Check out TortoiseHG, which will do hunk selection and let you commit different changes to one file as to different commits.

It will even let you commit all changes to some files together with partial changes to other files in one commit.

http://tortoisehg.bitbucket.io/

Answer 4

I asked a similar question just a little while ago, and the resulting answer of using the hgshelve extension was exactly what I was looking for.

Before you do a commit, you can put changes from different files (or hunks of changes within a file) on the "shelf" and then commit the things you want. Then you can unshelve the changes you didn't commit and continue working.

I've been using it the past few days and like it a lot. Very easy to visualize and use.

Answer 5

Mercurial now provides an option --interactive (or -i) to the commit command, which enables this functionality right out of the box.

This works directly from the command-line so it's perfect if you are a command-line enthusiast!

Running

> hg commit -i

begins an interactive session which allows examination, editing and recording of individual changes to create a commit.

This behaves very similarly to the --patch and --interactive options for the git add and git commit commands.

Answer 6

I would recommend not working like this.

If you have to sets of changes, set A which is ready to check in and set B which is not ready yet, how can you be sure that only checking in set A will not break your build/tests? You may miss some lines, forget about lines in a different file, or not realize a dependency that A has on B breaking the build for others.

Your commits should be discreet atomic changes that don't break the build for you or others on you team. If you are partially committing a file you are greatly increasing the chances you will break the build for others without knowing about it until you've got some unhappy coworker knocking on your door.

The big question is, why do you feel the need to work this way?