How to contribute a patch

juanjonavarro · 2014-03-05 11:55:15

Hello, I want to send a patch to textpattern (it’s really just an outdated file in the multi-site installation).

What is the “official” method to contribute:

Send a diff file to one of the members of the subversion repository
Clone and pull request to github repository
??

Thanks

Gocom · 2014-03-05 13:47:40

Former. As we still are using the SVN and Google Code (while I believe we should migrate to git) the workflow is:

Checkout the SVN repository.
Do your alterations.
Create diff: svn diff > my_feature_name_r12345.patch where 12345 is the revision you modified.
Create a new issue and attach the patch to it.

philwareham · 2014-03-05 16:04:11

Funnily enough, there’s currently a discussion about Textpattern using GitHub here

I’d be very happy for the project to move to git, and to GitHub. So would a quite few of our users by the sounds of it.

juanjonavarro · 2014-03-05 17:02:10

Done

+1 for Github use

CeBe · 2014-07-06 08:08:26

Is there a “Contribute How-To” anywhere?
A few questions are coming when browsing Google code:

the project home tab gives two branches (dev and stable)
the source tab gives a third one (crockery)

Which one should be chosen, and why?

And:

Gocom wrote #279479:

svn diff > my_feature_name_r12345.patch where 12345 is the revision you modified

I see that Juanjo numbered the revision r5747, but the patch was finally integrated in r5851.
How should the revision number be actually determined?

Thank you!

Bloke · 2014-07-06 22:04:19

CeBe wrote #281936:

Is there a “Contribute How-To” anywhere?

There’s probably one on the wiki, but it’s probably out of date. Probably :-/

Which one should be chosen, and why?

If you are submitting a patch that affects the current released product, then you should submit it by sending us a diff against the stable release. If you’re patching against the next, unreleased version, then diff against the dev branch instead.

Crockery is a previous-era branch that was never officially released. Considered dead. We should probably change that example on the Google Code page!

How should the revision number be actually determined?

If you checked out r5862, your patch should contain that revision number in its filename so we know which revision to apply the patch to. If you checked out r5862 and, in the meantime before your patch is completed, some more changes came along that bumped the Google Code revision to r5864, you can either:

merge the newer changes into your local branch (svn update), generate your diff patch and set its filename to have r5864 in the title, OR
don’t merge the new changes and send us the patch with the original r5862 in the title (because that was the revision you checked out and is therefore the version you worked on, and which your patch is “tested against”)

Of course, we’d prefer the first option if possible, because it’s less work for us to check out a specific revision to test your patch and then have to ‘merge forward’ to roll in any new changes since your patched revision, but if the differences aren’t too great between the two revisions or your patch is fairly simple then the second option is fine.

The actual revision number of the integrated feature when it lands in core will differ from your patch number, don’t worry about it. Just make sure your patch number matches the revision you checked out/worked on and everything will be fine… until we move to GitHub and then everything gets a shedload easier.

Hope that helps.

CeBe · 2014-07-11 14:39:46

Bloke wrote #281944:

Hope that helps.

It does, thank you!

Textpattern CMS

Textpattern CMS support forum

#1 2014-03-05 11:55:15