search

joachim-n / dorgflow

Automated git workflow for drupal.org patches.
69 stars 10 forks source link

Optionally clone project #23

Open geek-merlin opened 7 years ago

geek-merlin commented 7 years ago

To start with, you need to have an up to date git clone of the project you want to work on, be it Drupal core or a contrib project.

Sometimes i don't have a project clone or want a new... ;-)

joachim-n commented 7 years ago

Presumably this would happen when you do something like 'dorgflow 12345' without a git clone yet.

That's not going to be completely straightforward. The process would be something like this:

  1. retrieve the issue node (as currently done)
  2. check we're currently in a git repo. First problem here: what if you're in a Drupal core repo and wanting to work on a contrib project? (I tend to have all my contrib git clones in a folder called 'sandbox' and then symlink them into a Drupal codebase, but that's just me.) So the options are:
    • no git repo: need to clone
    • found a git repo: figure out whether it's a repo for Drupal core, or for a contrib project. The issue node data we've fetched will have a node ID for its project reference field, and we ideally shouldn't fetch the project node as that will slow things down, so we should hardcode Drupal core's node (3060 IIRC) and check for that.
      1. if the git remote is Drupal core and the issue's project is something else, we need to clone
      2. anything else, assume we're fine and that the current git repo matches the project of the requested issue.
  3. (optional) Need to clone: prompt the user whether to clone the repo. At this point, we do need to get the project node, as we need the project short name for the git clone command and also for the user prompt.
  4. Continue as normal with getting patches from the issue node etc.

Given the need to prompt the user, I think this is going to be postponed until https://github.com/joachim-n/dorgflow/issues/4 gets in -- though I'm struggling with that.

geek-merlin commented 7 years ago

Yes it think it's just a nice-to-have. Also i think it does not need to ba auto-magick. A simple option like --clone-project (which is asumed when not in a git) would do.

jurgenhaas commented 7 years ago

I've had this requirement myself too and even more so, inside of a composer based Drupal project environment, this was always difficult because each composer update in the project root would also reset my modules projects if a released version was required by that root project.

To solve all these requirements I've developed a composer plugin which does the trick: https://packagist.org/packages/lakedrops/dorgflow

Please let me know what you think.

joachim-n commented 7 years ago

I'm afraid I don't know much about Composer, and to be honest, I avoid using it as much as possible as it always seems to break things for me.

But it looks like you've made something pretty useful for those people who do manage to get Composer not to burn their kittens! If you want to file a new issue & a PR to add something to the README with a link to your project, please do!

jurgenhaas commented 7 years ago

Thanks @joachim-n I've created that pull request and would be happy if you committed that.

Regarding your trouble with Composer, I'm surprised. I hear that every now and then but with Drupal 8, I can't imagine how to live without composer and it looks like even more so in the near future. But that's probably off-topic here.