Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

brian_d_foy (44)

brian_d_foy
  brian.d.foy@gmail.com
http://www.pair.com/~comdog/

Journal of brian_d_foy (44)

Tuesday October 14, 2008
03:33 PM

Use git to easily make third party module patches

[ #37664 ]

In the olden days, to make a patch to a module, you had to have the original, untouched file and a copy that you modified. You'd then use diff to compare the two files.

At the Pittsburgh Perl Workshop, Ricardo was asking how to do some odd thing in git. Instead of anyone answering his question, everyone asked what he was doing. It turns out he was patching someone's module and making it a git repo while he worked. The process is really handy:

  1. Download module distribution and unpack it
  2. Make it a git archive with git init
  3. Add the initial content to the index with git add .
  4. Commit the initial content with git commit -m "* Version 1.23 from CPAN"
  5. work, work, work
  6. Generate your patch with git format-patch --stdout -1
  7. And Bob's your uncle

There are other ways that you can do this, and you can change around the process in git. I like that git is lightweight enough to make it actually useful for everyday work.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Use git to easily make third party module patches 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • A variation on step 6 and 7:

    step 6. Generate patch with git format-patch -1

    step 7. Send directly to the RT queue for the module, assuming that the first line of the commit description makes a good bug title and the rest a decent description: git send-email -to bug-Language-l33t@rt.cpan.org 0001-mypatch. (one can also uses --compose to write something different as the description as well)

    step 8. Marty's your uncle as well. :-)

  • I have been using the same technique with darcs for some time now, and it works very well with darcs, too. It's my preferred way to develop and submit patches. Just using a ".bak" file to diff against is fine if you have just one change, but what if you end up with 5 changes in which some depend on each other? Often when I start patching, it's difficult to foresee whether I'll end up with 1 patch, or more than that.

  • with apologies to Miguel de Cervantes, Pierre Menard, Joe Darion, and Sophia Loren/Sheena Easton ...

    the workflow with subversion would be the same, except the default output of 'svn diff' is usable by patch, so no special command needed.

    I used the equivalent of svn diff | ( cd $newdir; patch) just the other day to propagate changes from a local svn tree to one built with https login & comit bit.

    --
    Bill
    # I had a sig when sigs were cool
    use Sig;

    • How would you do this in Subversion without maintaining a repository? Maybe you can, but I just don't know how.

      • use someone else's repository? :-)

        a local repository of any sort ... even old sccs/rcs ... is always a good idea for hyper-meta-undo, if for nothing else. if git is better for that than svn, that's interesting news.

        see also answer to Aristotle's similar question.

        --
        Bill
        # I had a sig when sigs were cool
        use Sig;

        • That is exactly what git (or any other DVCS for that matter) is so good for. :-)

          In fact, that’s something I’ve said a couple of times – that DVCSs represent a backtracking to what local-only systems like RCS offered, and a move forward from there in the opposite direction for cross-host collaboration from the one that CVS and its offspring Subversion took. Instead of layering collaboration onto RCS by moving the repository out of a subdirectory of the working copy and behind a networked d

    • Subversion makes the mental overhead of creating a repository very much greater than any DVCS, where you just say git init or hg init or bzr init or whatever you prefer – there’s no need to pick a place for you repository, it just goes wherever your working copy is. There’s also no need to turn the current directory into a working copy after checking it in initially by checking it right back out, which may in turn require casting a path to a URL (since svnadmin only works locally).

      It seems

      • well, what i was patching has public read only repository, so i didn't have to create one. (it may be a bug or feature that creating a new one on googlecode takes mousing not commands.) I applied the diff-is-patch from my anonymous checkout with tested fixes in it to a new authenticated checkout with comit privs in addition to uploding the patch file, redundant i know.

        i see your point that if you have just a tarball of source, creating a local repository easily is good. Needing a cheat sheet for creating

        --
        Bill
        # I had a sig when sigs were cool
        use Sig;

        • Nothing that can’t be scripted to a single command though.

          Sure, but you have to do it. Subversion does not (and by its nature as a centralised system cannot) provide a useful default for you, so everyone needs to establish their own convention and then script the sequence to their preferences. That’s obvious blinking twelve territory.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.