Channels ▼

Pablo Santos

Dr. Dobb's Bloggers

Disintegrating changes with GIT and Plastic

March 28, 2009

Committing code is easy with any version control system even integrating (merging) branches can be unless you're bound to some ancient tool.

Nowadays a very common modern practice with modern SCMs (ok, GIT can do it, Plastic can do it, and I guess that Mercurial can too) is to isolate each change (bugfix, new feature, new experiment, whatever...) on a new branch and then integrate them together on the main (or master for gitters) branch.

So, integration is easy, but what happens when you want to disintegrate a change?

In order to make the post more informative, I'll be explaining the process for both GIT and Plastic SCM.

Suppose I've made some changes on my codebase (I'll start working on a single branch to make things easier) so that it looks like the following:

I've made some changes on the changeset (commit) in the blue square third from the left, and then continued working.

I modified two files on commit 12 (the one in blue) and here are my changes:

And the second file:

And then modified the same files again to make the sample easier to follow on commit 13 as follows:

 

Well, I'd like to get rid of the changes on cset 12, but still keeping the ones at cset 13, which are good changes coming from a different fix.

How should I do that?

Disintegration (how I like to say it), subtractive merge (Clearcase parlance, and also the name of the command in Plastic) or revert (as GIT would say) comes to the rescue!

 

The image shows the current situation, and the commands to create a new commit removing (disintegrating or subtracting) the changes made on cset 12.

In GIT you'll use the revert command while in Plastic you'll use sm, short from subtractive merge.

Subtracting graphically

If you're using Plastic, you can easily subtract a changeset from the branch explorer or the changesets view.

 

It will launch the subtractive merge process, which will show you the elements to disintegrate:

 

If the merge is not automatic (not like the case I described above, which doesn't require any manual operation), the three way merge tool will show up, like in a regular manual merge process.

What's the result?

Well, as expected, just the changes on commit 12 will be removed.

 

Check how the added code in cset 12 is now removed, and the removed one (second file) is there again.

Plastic will create a link between the disintegrated revisions the same way it does after merging, but this time using a special subtractive merge link type which is drawn on red on the 3D version tree as shown below:

 

Working with branches

What happens when we're working with branches?

Consider the following situation where your team have been working on a couple of branches and then merged them back to the main branch.

 

If you take a look at the 3D tree of one of the items involved in the changeset, you'll see the following:

 

Which shows the merge arrows (green) from the two source revisions into the destination ones.

What if now you realize that task001 shouldn't go to the next release? You should get rid of it, using disintegration.

 

A new cset will be created as a result of the operation, and now your trunk is ready to be released, not including task001 changes anymore.

 

Conclusions

Modern SCMs will allow you run potentially complex operations such us subtractive merge, and as you've seen they're really helpful even on a daily basis, to revert mistakes or buggy tasks.

At Codice we focus on making this operations not only doable, but also as simple as possible, avoiding repetitive and error prone tasks, which doesn't mean you don't need to know what happens under the hood.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video