Use git to easily make third party module patches

brian_d_foy on 2008-10-14T20:33:18

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.

---

can be submitted to RT directly too...

Yanick on 2008-10-15T16:45:26

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. :-)

darcs works well for this too

markjugg on 2008-10-15T20:57:59

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.

go with git, or with subversion, it's all the same

n1vux on 2008-10-15T21:02:57

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.

Re:go with git, or with subversion, it's all the s

brian_d_foy on 2008-10-15T21:13:22

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

Re:go with git, or with subversion, it's all the s

n1vux on 2008-10-21T19:18:04

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.

Re:go with git, or with subversion, it's all the s

Aristotle on 2008-10-22T00:31:08

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æmon, they instead provide for reconciliation between many different copies of the repository. This turns out to be much more powerful.

Re:go with git, or with subversion, it's all the s

Aristotle on 2008-10-19T12:21:13

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 like small potatoes, but when you turn something that takes five commands and has a free variable into a single command that requires no thinking whatsoever, it changes the quality of the game. You start creating throw-away repositories for the littlest reason because the only decision left is whether to create one or not.

Re:go with git, or with subversion, it's all the s

n1vux on 2008-10-21T19:13:36

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 a local repositry would be a drag. Nothing that can't be scripted to a single cowmand though. and you can use the same repository in ~/svn for multiple projects if interleaving versions isn't going to be a problem for your security and compliance officer.

Re:go with git, or with subversion, it's all the s

Aristotle on 2008-10-22T00:22:25

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.