which is the current repo for this gem?

[jrochkind]

I'm getting confused, seeing which one I get an answer on.

There's this repo, and there's https://github.com/technicalpickles/capistrano-gitflow , which is a fork of this one.

This one has more recent commits than technicalpickles, and is identified as github as the 'original'.

However, the gemspec for the latest release on rubygems points to technicalpickles. As exposed by 'homepage' link on https://rubygems.org/gems/capistrano-gitflow

So what's up, which is repo has the latest code matching current gem release, and who, if anyone, is actually the maintainer/committer?

Thanks!

[apinstein]

IIRC I have merged in all of technicalpickles stuff into master, I just don't think he ever pushed the new gem. He set it up so I can't...

You should be able to confirm that by looking at the network.

LMK if you need more help. I'd look but I'm swamped.

Alan

On Mar 19, 2012, at 4:38 PM, Jonathan Rochkind wrote:

I'm getting confused, seeing which one I get an answer on.

There's this repo, and there's https://github.com/technicalpickles/capistrano-gitflow , which is a fork of this one.

This one has more recent commits than technicalpickles, and is identified as github as the 'original'.

However, the gemspec for the latest release on rubygems points to technicalpickles. As exposed by 'homepage' link on https://rubygems.org/gems/capistrano-gitflow

So what's up, which is repo has the latest code matching current gem release, and who, if anyone, is actually the maintainer/committer?

Thanks!

---

Reply to this email directly or view it on GitHub:
#4

[jrochkind]

Thanks! I'm confused by your response though -- technicalpickles is
currently the only one with the ability to push a new gem, that much
is true, yes? Okay, i guess he's the one to talk to about any
additional changes? Or if I don't hear from him (so far haven't to an
issue I posted there), just go ahead and fork it and rename it and
push my own under a new name, is pretty much where it's at, if he
doesn't seem interested in maintaining or I can't get in touch with
him (sounds like you don't have time at the moment either). That seem
about right?

On Mar 19, 2012, at 4:53 PM, Alan Pinstein wrote:

IIRC I have merged in all of technicalpickles stuff into master, I
just don't think he ever pushed the new gem. He set it up so I
can't...

You should be able to confirm that by looking at the network.

LMK if you need more help. I'd look but I'm swamped.

Alan

On Mar 19, 2012, at 4:38 PM, Jonathan Rochkind wrote:

I'm getting confused, seeing which one I get an answer on.

There's this repo, and there's https://github.com/technicalpickles/capistrano-gitflow
, which is a fork of this one.

This one has more recent commits than technicalpickles, and is
identified as github as the 'original'.

However, the gemspec for the latest release on rubygems points to
technicalpickles. As exposed by 'homepage' link on https://rubygems.org/gems/capistrano-gitflow

So what's up, which is repo has the latest code matching current
gem release, and who, if anyone, is actually the maintainer/
committer?

Thanks!

---

Reply to this email directly or view it on GitHub:
#4

---

Reply to this email directly or view it on GitHub:
https://github.com/apinstein/git-deployment/issues/
4#issuecomment-4583330

[apinstein]

So, mine is the canonical, but technicalpickles forked mine and published that to RubyGems before we got in touch with each other. Madness has ensued.

I worked with him months ago to merge in all of his changes and also fixed some bugs. They are all on my repo. You can see this from the network view:

https://github.com/apinstein/git-deployment/network

I have just been using the gem via git URL so it hasn't bothered me to not have the latest gem on RubyGems.

We both have lots of watchers and forks. I guess he isn't up to working on this anymore though...

Unfortunately he renamed his repo, which complicates things. I am scared to rename my repo as so many people depend on the old name.

I will see if he can add me to the RubyGems so at least I can update that gem.

Frankly I am a little scared to update it because a bunch of stuff has changed and so many people depend on it for deployment. I couldn't easily handle an onslaught of support requests if there were a problem.

What is your goal anyway? I am not sure what you're trying to achieve.

Alan

On Mar 26, 2012, at 8:52 PM, Jonathan Rochkind wrote:

Thanks! I'm confused by your response though -- technicalpickles is
currently the only one with the ability to push a new gem, that much
is true, yes? Okay, i guess he's the one to talk to about any
additional changes? Or if I don't hear from him (so far haven't to an
issue I posted there), just go ahead and fork it and rename it and
push my own under a new name, is pretty much where it's at, if he
doesn't seem interested in maintaining or I can't get in touch with
him (sounds like you don't have time at the moment either). That seem
about right?

On Mar 19, 2012, at 4:53 PM, Alan Pinstein wrote:

IIRC I have merged in all of technicalpickles stuff into master, I
just don't think he ever pushed the new gem. He set it up so I
can't...

You should be able to confirm that by looking at the network.

LMK if you need more help. I'd look but I'm swamped.

Alan

On Mar 19, 2012, at 4:38 PM, Jonathan Rochkind wrote:

I'm getting confused, seeing which one I get an answer on.

There's this repo, and there's https://github.com/technicalpickles/capistrano-gitflow
, which is a fork of this one.

This one has more recent commits than technicalpickles, and is
identified as github as the 'original'.

However, the gemspec for the latest release on rubygems points to
technicalpickles. As exposed by 'homepage' link on https://rubygems.org/gems/capistrano-gitflow

So what's up, which is repo has the latest code matching current
gem release, and who, if anyone, is actually the maintainer/
committer?

Thanks!

---

Reply to this email directly or view it on GitHub:
#4

---

Reply to this email directly or view it on GitHub:
https://github.com/apinstein/git-deployment/issues/
4#issuecomment-4583330

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[jrochkind]

Yeah, I might be better of making own fork, copy and pasting code from you at the moment.

My goal is I'm actually NOT interested in 'flow' from staging to production, or even multi-stage cap at all (emphasize: YET). But I AM interested in a cap task that automatically adds a tag to my git repo, say, deploy-yyyy-mm-dd-x. It turns out that doing even just that in a robust and foolproof way is a bit tricky -- and you've solved that problem very nicely as a subset of everything else you did.

So, I dunno, the question is about refactoring your code to allow optionally just the git tagging piece. It hypothetically makes sense for your package to allow just git tagging, and then later someone could 'upgrade' to the complete multistage flow with tagging.

But if it's too hard to refactor your code to do that without potentially breaking something, perhaps I should just copy-and-paste what you've figured out into my own thing that just does tagging.

Either way, i'd encourage you to bug technicalpickles to get gem release rights. Eventually there's going to be a bugfix or feature you need to release. And possibly then release a patch version of the gem that has no changes except pointing to your repo as the home page in the gemspec, so that'll show up on rubygems.org. Right now, it's a multi-hour process just for a developer to track down where the canonical repo and potential maintainer is (you know, in case you want to actually try to check with them before forking, renaming, and releasing your own gem, to be polite, heh. Or just to know which repo to fork from to get up to date code!)

[apinstein]

Ah well in that case you should probably get away with copy/paste rather than refactoring.

If you end up with a nice library then maybe we could refactor capistrano-gitflow to use YOUR tagging lib. I think it will be easier for you that way.

In the meantime I'm trying to get RubyGems rights.

Alan

On Mar 27, 2012, at 3:58 PM, Jonathan Rochkind wrote:

Yeah, I might be better of making own fork, copy and pasting code from you at the moment.

My goal is I'm actually NOT interested in 'flow' from staging to production, or even multi-stage cap at all (emphasize: YET). But I AM interested in a cap task that automatically adds a tag to my git repo, say, deploy-yyyy-mm-dd-x. It turns out that doing even just that in a robust and foolproof way is a bit tricky -- and you've solved that problem very nicely as a subset of everything else you did.

So, I dunno, the question is about refactoring your code to allow optionally just the git tagging piece. It hypothetically makes sense for your package to allow just git tagging, and then later someone could 'upgrade' to the complete multistage flow with tagging.

But if it's too hard to refactor your code to do that without potentially breaking something, perhaps I should just copy-and-paste what you've figured out into my own thing that just does tagging.

Either way, i'd encourage you to bug technicalpickles to get gem release rights. Eventually there's going to be a bugfix or feature you need to release. And possibly then release a patch version of the gem that has no changes except pointing to your repo as the home page in the gemspec, so that'll show up on rubygems.org. Right now, it's a multi-hour process just for a developer to track down where the canonical repo and potential maintainer is (you know, in case you want to actually try to check with them before forking, renaming, and releasing your own gem, to be polite, heh. Or just to know which repo to fork from to get up to date code!)

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[jrochkind]

Thanks!

I'd encourage you to release a new version with your bugfixes once you
manage to get rights!

While pointing directly to the git repo in the Gemfile mostly works,
it can run into weird problems (can't 'bundle package' it, although I
guess there's no reason you'd need this gem in deployment anyway.
usually anyhow) You also identified yourself one of the problems with
pointing right to the git repo -- if people were pointing to the
actual released gem instead of a git url, you could change the name of
the git project without disrupting them! As long as you didn't change
the gem release name.

Also, I would have had no idea that I should be pointing directly at
git repo to get the latest bugfixes that would possibly never
otherwise appear in a release becuase of gem ownership issues. I think
I'm not alone in making an assumption that the latest stable release
is from a released gem, and there's nothing in the docs anywhere to
tell me otherwise in this case.

Anyhow, thanks for the cool code!

On Tue, Mar 27, 2012 at 4:28 PM, Alan Pinstein
reply@reply.github.com
wrote:

Ah well in that case you should probably get away with copy/paste rather than refactoring.

If you end up with a nice library then maybe we could refactor capistrano-gitflow to use YOUR tagging lib. I think it will be easier for you that way.

In the meantime I'm trying to get RubyGems rights.

Alan

On Mar 27, 2012, at 3:58 PM, Jonathan Rochkind wrote:

Yeah, I might be better of making own fork, copy and pasting code from you at the moment.

My goal is I'm actually NOT interested in 'flow' from staging to production, or even multi-stage cap at all (emphasize: YET). But I AM interested in a cap task that automatically adds a tag to my git repo, say, deploy-yyyy-mm-dd-x.  It turns out that doing even just that in a robust and foolproof way is a bit tricky -- and you've solved that problem very nicely as a subset of everything else you did.

So, I dunno, the question is about refactoring your code to allow optionally just the git tagging piece. It hypothetically makes sense for your package to allow just git tagging, and then later someone could 'upgrade' to the complete multistage flow with tagging.

But if it's too hard to refactor your code to do that without potentially breaking something, perhaps I should just copy-and-paste what you've figured out into my own thing that just does tagging.

Either way, i'd encourage you to bug technicalpickles to get gem release rights. Eventually there's going to be a bugfix or feature you need to release. And possibly then release a patch version of the gem that has no changes except pointing to your repo as the home page in the gemspec, so that'll show up on rubygems.org.  Right now, it's a multi-hour process just for a developer to track down where the canonical repo and potential maintainer is (you know, in case you want to actually try to check with them before forking, renaming, and releasing your own gem, to be polite, heh. Or just to know which repo to fork from to get up to date code!)

---

Reply to this email directly or view it on GitHub:
#4 (comment)

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[apinstein]

Yes, agree on all points! Enjoy. LMK if you get a lib set up for tagging.

On Mar 27, 2012, at 5:35 PM, Jonathan Rochkind wrote:

Thanks!

I'd encourage you to release a new version with your bugfixes once you
manage to get rights!

While pointing directly to the git repo in the Gemfile mostly works,
it can run into weird problems (can't 'bundle package' it, although I
guess there's no reason you'd need this gem in deployment anyway.
usually anyhow) You also identified yourself one of the problems with
pointing right to the git repo -- if people were pointing to the
actual released gem instead of a git url, you could change the name of
the git project without disrupting them! As long as you didn't change
the gem release name.

Also, I would have had no idea that I should be pointing directly at
git repo to get the latest bugfixes that would possibly never
otherwise appear in a release becuase of gem ownership issues. I think
I'm not alone in making an assumption that the latest stable release
is from a released gem, and there's nothing in the docs anywhere to
tell me otherwise in this case.

Anyhow, thanks for the cool code!

On Tue, Mar 27, 2012 at 4:28 PM, Alan Pinstein
reply@reply.github.com
wrote:

Ah well in that case you should probably get away with copy/paste rather than refactoring.

If you end up with a nice library then maybe we could refactor capistrano-gitflow to use YOUR tagging lib. I think it will be easier for you that way.

In the meantime I'm trying to get RubyGems rights.

Alan

On Mar 27, 2012, at 3:58 PM, Jonathan Rochkind wrote:

Yeah, I might be better of making own fork, copy and pasting code from you at the moment.

My goal is I'm actually NOT interested in 'flow' from staging to production, or even multi-stage cap at all (emphasize: YET). But I AM interested in a cap task that automatically adds a tag to my git repo, say, deploy-yyyy-mm-dd-x. It turns out that doing even just that in a robust and foolproof way is a bit tricky -- and you've solved that problem very nicely as a subset of everything else you did.

So, I dunno, the question is about refactoring your code to allow optionally just the git tagging piece. It hypothetically makes sense for your package to allow just git tagging, and then later someone could 'upgrade' to the complete multistage flow with tagging.

But if it's too hard to refactor your code to do that without potentially breaking something, perhaps I should just copy-and-paste what you've figured out into my own thing that just does tagging.

Either way, i'd encourage you to bug technicalpickles to get gem release rights. Eventually there's going to be a bugfix or feature you need to release. And possibly then release a patch version of the gem that has no changes except pointing to your repo as the home page in the gemspec, so that'll show up on rubygems.org. Right now, it's a multi-hour process just for a developer to track down where the canonical repo and potential maintainer is (you know, in case you want to actually try to check with them before forking, renaming, and releasing your own gem, to be polite, heh. Or just to know which repo to fork from to get up to date code!)

---

Reply to this email directly or view it on GitHub:
#4 (comment)

---

Reply to this email directly or view it on GitHub:
#4 (comment)

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[jrochkind]

hey, so I'm doing that thing, it's basically ending up pretty easy to add the functionality of this thing in too, but based on a refactored codebase. Kind of having fun with it, in the minutes here and there I find to work on it. (And the stuff figured out in your code on proper git command line invocations to get what we want is crucial, it would not be fun if you hadn't figured that out for me already!)

Question about desired features. Your documentation still says tags will be "production-yyyy-mm-dd.x", but your code does a fancier template with (interactively entered) short description, account name of person doing the deploy, etc.

How important do you think this fancier template is to your users, or how important is it to you? Should I bother implementing it? (If I do, I might do something clever with a configurable format template string or something).

update: oh, and when/if I'm finished, happy to make you a committer on the code/releaser on the gem if you want.

[jrochkind]

oh, and same thing for the feature to show the commit log and force interactive accept before doing a production deploy. Has that worked out as useful as you anticipated, do you think people like/need it? Is it worth adding it to my refactored version?

(In my version, pretty much EVERYTHING will be easily configurable to turn it off or on and use what bits you need; but I'll also provide some optional 'requires' to give you out of the box standard workflows, including one as close to what your code does as I can or feel like getting. Is the plan anyway.)

[apinstein]

hey, so I'm doing that thing, it's basically ending up pretty easy to add the functionality of this thing in too, but based on a refactored codebase. Kind of having fun with it, in the minutes here and there I find to work on it. (And the stuff figured out in your code on proper git command line invocations to get what we want is crucial, it would not be fun if you hadn't figured that out for me already!)

cool! definitely most of the work was in the git-fu!

I was doing a bunch more git-fu today for our migrations system. We don't allow migrations to run out-of-order thus when switching between feature branches things get sticky trying to juggle migrations, so I wrote a script that runs as a git post-checkout hook to figure out how to solve the problem whenever you switch branches.

Here's a link if you think any of it would be useful for you:

https://github.com/apinstein/mp/blob/githook/VCSHelper.php#L200

Question about desired features. Your documentation still says tags will be "production-yyyy-mm-dd.x", but your code does a fancier template with (interactively entered) short description, account name of person doing the deploy, etc.
How important do you think this fancier template is to your users, or how important is it to you? Should I bother implementing it? (If I do, I might do something clever with a configurable format template string or something).

Docs are out-of-date. We do like the auto-naming stuff; making it work off of a template would be cool. We found over time that having something more descriptive after the unique prefix is really helpful when scanning lists of tags for things.

Alan

[apinstein]

Oh yeah I love that. It prevents us from pushing without remembering to look at what we're pushing!

Alan

On Apr 5, 2012, at 6:48 PM, Jonathan Rochkind wrote:

oh, and same thing for the feature to show the commit log and force interactive accept before doing a production deploy. Has that worked out as useful as you thought, do you think people like/need it? Is it worth adding it to my refactored version?

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[jrochkind]

How about the "serial number" included in tag that seems to increment every time you do a new deploy? That's harder to implement while also allowing a configurable template for the tag. Is that actually important to your use case?

[apinstein]

yes, it's very important, and frankly should be for you, too. it's what makes the tags sort in date order when sorted lexicographically.

On Apr 9, 2012, at 10:54 AM, Jonathan Rochkind wrote:

How about the "serial number" included in tag that seems to increment every time you do a new deploy? That's harder to implement while also allowing a configurable template for the tag. Is that actually important to your use case?

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[jrochkind]

hmm, I don't understand, if you're tagging eg staging-yyyy-mm-dd, shouldn't that sort by date order, lexicographically, all by itself?

But maybe I'm having trouble what's going on in general. Can you explain what the git commands in last_tag_matching actually do? Esp change at c0ac685

In my version of git, there's no git log --tags option, having trouble figuring out what's supposed to be going on there.

[apinstein]

git tag -l 'production*'

That sorting is critical to the code being able to find tags based on dates.

On Apr 9, 2012, at 11:55 AM, Jonathan Rochkind wrote:

hmm, I don't understand, if you're tagging eg staging-yyyy-mm-dd, shouldn't that sort by date order, lexicographically, all by itself?

But maybe I'm having trouble what's going on in general. Can you explain what the git commands in last_tag_matching actually do? Esp change at c0ac685

In my version of git, there's no git log --tags option, having trouble figuring out what's supposed to be going on there.

---

Reply to this email directly or view it on GitHub:
#4 (comment)