Jump to content

Submitting to git project / repeater module


darrenc
 Share

Recommended Posts

I had an idea for a very minor/modest enhancement that I'd like to make to the repeater module. I've never contributed or really used GIT and I don't know how it all works with regards to how people can submit things to the processwire project in order for them to be included:

  • Is it welcomed?
  • Is there a specific procedure that I should follow?
  • I don't presume to be the best developer so if my code isn't particularly good am I just wasting time and hindering rather than helping?
  • etc.

I think maybe that's enough said for you to understand where I'm coming from. Please let me know how you think an amateur like me should proceed. Thank you kindly.

Link to comment
Share on other sites

@darrenc

The way you submit enhancements/fixes to a project on github is to first fork the project, then make the changes to your forked version, then submit a pull request to the original project.

Ryan will receive notification of your PR and he can then review and accept the changes as is, or modify them as needed.

Obviously it's hard to know whether your changes will be coded the way Ryan would prefer or not. Depending on the change it might be just as productive to simply submit an issue asking for the enhancement. You could look through some of the previous PR and issues and see if you think your enhancement suggestion and your coding quality would make it better suited to one approach or the other.

Sorry, not a definitive answer, but hopefully helpful.

  • Like 4
Link to comment
Share on other sites

@darrenc

In addition to adrian's remarks above, I've found that Ryan is great at picking up a good idea from a pull request and making whatever adjustments he feels necessary to slip it into the codebase. Don't worry about dotting every 'i' and crossing every 't' at this point; just get used to git and github and then make sure that your proposed changes make sense and have a good rationale and you have a good chance of seeing the code get accepted even if it is modified along the way.

  • Like 6
Link to comment
Share on other sites

In fact I know ryan likes to retype pull requests himself so he has full understanding of the code changes and tweaks them as necessary.

This is opposed to my occasional blind acceptance of pull requests on my own modules that is definitely not best practice! :)

  • Like 4
Link to comment
Share on other sites

I have one more question, and I am curious to hear how people handle it in their own development environments:

  1. github - my forked processwire 
  2. local - processwire "working directory"
  3. local - processwire running, installed on my local dev/testing webserver

#2 is where the git magic happens; branching, making commits, and then pushing to #1 and eventually making a pull request. My question is about how #2 and #3 work on your own environments. 

In order to get processwire up and running, #2 has to install and change files (/site/, .htaccess). Now in #3 state, this is where I would actually be making code changes and testing to see if I break something. Then I would have to copy my changes back to #2 in order to do the git business? This seems very inefficient obviously, but I don't know if there's another way to make #2 and #3 be the same directory?

Link to comment
Share on other sites

@darrenc

There are a couple of approaches you could take to set this up. I'll describe one that uses a symlink. 

As you already know this will only be a change to the repeater module I'd be tempted to create a symlink from the wire/modules directory from #2 into #3 and make sure that I had #2 switched over to what folks call a 'feature' branch. This is a branch of the codebase that you dedicate to adding just one thing which, in this case, would be your changes (or just one change) to the core repeater module. 

Here it is set out in a little more detail. In the root of your local 'working directory' you'd do...

  1. 'git checkout dev' so you have the dev branch checked out
  2. 'git checkout -b super-repeaters' (substituting 'super-repeaters' with a better name for your feature) which creates and checks out a new feature branch called "super-repeaters".
  3. Make sure your local installation's wire/modules/fieldtype/FieldtypeRepeater/ (the whole dir) is a symlink to your #2's wire/modules/fieldtype/FieldtypeRepeater/ directory.

Any changes you make to the repeaters in your installation you are then making to the corresponding files in your working directory. 

When you've tested your code and are happy with it you 'git add' and 'git commit' as required into your super-repeaters branch. You can then send changes to github with 'git push origin super-repeaters' (or whatever your branch is called) and use github to create a PR to Ryan.

A couple of gotcha's to look out for...

1) Make sure your text editor is setup for utf-8 file encoding with no BOM marker.

2) Make sure you setup the editor to use linux style end-of-lines (\n not \r\n or \r.)

Hope that helps. Just ask if you need anything else.

  • Like 5
Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...