The Little Known Label Option For diff

  • strict warning: Non-static method view::load() should not be called statically in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_argument.inc on line 744.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter_boolean_operator.inc on line 159.
Leeland's picture

I love it when I run over a simple solution to what seemed like a difficult (or at least convoluted) problem. Today I needed to generate some patch files to create a Crucible code review PRIOR to checking in the code. To do this is actually a little difficult by hand as the steps are:

  1. Take the shelved change list
  2. Unshelve the change list into some temporary perforce client: p4 unshelve –s 123456
  3. Create patch p4 diff –du100000 ./... >123456.patch (for files that contains less than 100000 lines it would be okay)
  4. Create review using comments from shelved list and the generated patch.
  5. Clean up the temporary p4 revert ./...
  6. Create a new review by uploading the patch file.

Well this is just fine except that if you have a FishEye instance there and it has a few projects you do need to "root" your patch against the repository "root" in other words the this patch:

--- .\new.txt   2012-05-02 09:02:04.577480400 -0700
+++ .\new2.txt  2012-05-03 13:05:31.956894700 -0700
@@ -1,7 +1,7 @@
-    ///    //  /////////  //      //
-    ////   //  //         //      //
-    // //  //  //         //      //
-    //  // //  ///////    //  //  //
-    //   ////  //         //////////
-    //    ///  //         ///    ///
-    //     //  /////////  //      //
+##    ## ######## ##      ##     #######
+###   ## ##       ##  ##  ##    ##     ##
+####  ## ##       ##  ##  ##           ##
+## ## ## ######   ##  ##  ##     #######
+##  #### ##       ##  ##  ##    ##
+##   ### ##       ##  ##  ##    ##
+##    ## ########  ###  ###     #########

Really needs to look like this:

--- path/of/file/in/depot/new.txt#23  2012-05-01 09:02:04.577480400 -0700
+++ path/of/file/in/depot/new.txt#24 2012-05-03 13:05:31.956894700 -0700
@@ -1,7 +1,7 @@
-    ///    //  /////////  //      //
-    ////   //  //         //      //
-    // //  //  //         //      //
-    //  // //  ///////    //  //  //
-    //   ////  //         //////////
-    //    ///  //         ///    ///
-    //     //  /////////  //      //
+##    ## ######## ##      ##     #######
+###   ## ##       ##  ##  ##    ##     ##
+####  ## ##       ##  ##  ##           ##
+## ## ## ######   ##  ##  ##     #######
+##  #### ##       ##  ##  ##    ##
+##   ### ##       ##  ##  ##    ##
+##    ## ########  ###  ###     #########

Why? Well lets just say I am doing delta-differential patch creations to allow a code review to be done in stages.

The key here is the header lines. I need them to have the proper path and file ID to map into the FishEye repository vs. the correct formatting for the type of repository (Perforce, Subversion, CVS, etc.).

My first thought was "well just make the patches and then filter them through a copy function that corrects the header line." Well in the process of doing that something was tugging at the back of my head to be remembered. I tried to ignored it and started coding. But, then I decided I should check the manual pages for the commands I am using. That thing in the back of my head nearly smacked my head into the monitor to be heard and my eyes locked on the --label option for diff.

Hmm, oh yeah I forgot about that. Heck I haven't used it since I think some time around the mid 1990s. Problem solved instantly. The function became a few lines of code, and heck if isn't nice and clean.

So how do you use it? Well you specify once, or twice. The first time it replaces what would have been used for the "old" or top line file. The second time it replaces what would have been used for the new file or second line file. So to produce the above required output the command goes from this:

diff -U10000 new.txt new2.txt

To this:

diff -U10000 --label "path/of/file/in/depot/new.txt#23" --label "path/of/file/in/depot/new.txt#24" new.txt new2.txt

Which means all I have to do is compute the proper "names" for what I am creating the patch file for and just pass those to the diff command I am calling.

BTW this works for diff most Linux variants as well as the diff.exe utility from either GnuWin32 or UnixUtils on Windows.

Also I know Beyond Compare (bcomp.exe, bcompare.exe) on Windows can do this too using the /title1=XXX /title2=YYY command line options.

Now back to my tasty beverage. Hope this helps!

Thread Slivers eBook at Amazon