search

apinstein / git-deployment

Capistrano recipe for a deployment workflow based on git tags
116 stars 43 forks source link

which is the current repo for this gem? #4

Open jrochkind opened 12 years ago

jrochkind commented 12 years ago

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 commented 12 years ago

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: https://github.com/apinstein/git-deployment/issues/4

jrochkind commented 12 years ago

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: https://github.com/apinstein/git-deployment/issues/4

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

apinstein commented 12 years ago

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: https://github.com/apinstein/git-deployment/issues/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: https://github.com/apinstein/git-deployment/issues/4#issuecomment-4707746

jrochkind commented 12 years ago

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 commented 12 years ago

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: https://github.com/apinstein/git-deployment/issues/4#issuecomment-4725030

jrochkind commented 12 years ago

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: https://github.com/apinstein/git-deployment/issues/4#issuecomment-4725030

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

apinstein commented 12 years ago

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: https://github.com/apinstein/git-deployment/issues/4#issuecomment-4725030

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

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

jrochkind commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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: https://github.com/apinstein/git-deployment/issues/4#issuecomment-4987555

jrochkind commented 12 years ago

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 commented 12 years ago

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: https://github.com/apinstein/git-deployment/issues/4#issuecomment-5026447

jrochkind commented 12 years ago

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 https://github.com/apinstein/git-deployment/commit/c0ac6854b906f7c5a4875def63c035621a27a7fc

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 commented 12 years ago

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 https://github.com/apinstein/git-deployment/commit/c0ac6854b906f7c5a4875def63c035621a27a7fc

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: https://github.com/apinstein/git-deployment/issues/4#issuecomment-5027611

jrochkind commented 12 years ago

git tag -l 'production' is NOT what your code seems to do, right? It does this that I don't understanding (passing literal backtics to git, what?)

last_tag = `git describe --exact-match --match '#{pattern}' \`git log --tags='#{pattern}*' --format="%H" -1\``.chomp

But yeah, git tag -l 'production-*' seems simpler (and I understand what it does). It will list tags in the correct order if they've already been added as production-yyyy-mm-dd, right?

Is the issue only when you have two tags that have the same yyyy-mm-dd, you need to be sure which came second?

What if I can get git to actually give a list sorted chronologically by when the tag has been applied, would that eliminate the need for lexicographic sorting matching chronology, or would it still be needed?

apinstein commented 12 years ago

git tag -l 'production' is NOT what your code seems to do, right? It does this that I don't understanding (passing literal backtics to git, what?)

last_tag = git describe --exact-match --match '#{pattern}' \git log --tags='#{pattern}*' --format="%H" -1``.chomp

But yeah, git tag -l 'production-*' seems simpler (and I understand what it does). It will list tags in the write order if they've already been added as production-yyyy-mm-dd, right?

Well even with git describe you want them to be date-sorted, and it's the same problem. I suppose you could move the date sorting into ruby but then it'd have to do more work to get all the tags and parse them.

Is the issue only when you have two tags that have the same yyyy-mm-dd, you need to be sure which came second?

Yes that's the point.

What if I can get git to actually give a list sorted chronologically by when the tag has been applied, would that eliminate the need for lexicographic sorting matching chronology, or would it still be needed?

Could work though frankly that might be tricky, too. I am actually not sure the data is even there. Remember people on different machines might be doing the tagging....

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

jrochkind commented 12 years ago

looking into it, the date the tag was made IS in git, so long as it was an 'annotated' tag (with -a and/or -m), not a 'plain' tag.

Not sure if time out of sync on different machines will be a problem though. As a real user, have you had that issue in real life where different developers on different machines are tagging staging-* or production-* tags near simultaneously? (seems like that could be a race condition even with your current code, if it's done in just the 'wrong' sync order).

Sorting based on actual date-of-tag is definitely a lot simpler. Other than the possibly-not-likely issue of developers near-simultaneously tagging, are there other cases where you'd want something OTHER than the actual most recent tag matching 'staging-*'? Like someone tags a tag beginning 'staging-' , but it intentionally sorts lexicographically not most recent, and it's NOT meant to be the next deploy?

jrochkind commented 12 years ago

I also can't figure out how your current code works at all or what it's intended to do, and it does NOT work on my machine at all, so one way or another I've got to do something different in my version.

apinstein commented 12 years ago

I am not sure....

There are a ton of users of this system; perhaps a poll to the user base would be better?

Unfortunately this was a side-project and I didn't TDD it so there are really no specs other than the code itself.

Sorry I wish I could help further I just don't have tons of time.

Alan

On Apr 9, 2012, at 1:40 PM, Jonathan Rochkind wrote:

looking into it, the date the tag was made IS in git, so long as it was an 'annotated' tag (with -a and/or -m), not a 'plain' tag.

Not sure if time out of sync on different machines will be a problem though. As a real user, have you had that issue in real life where different developers on different machines are tagging staging-* or production-* tags near simultaneously? (seems like that could be a race condition even with your current code, if it's done in just the 'wrong' sync order).

Sorting based on actual date-of-tag is definitely a lot simpler. Other than the possibly-not-likely issue of developers near-simultaneously tagging, are there other cases where you'd want something OTHER than the actual most recent tag matching 'staging-*'? Like someone tags a tag beginning 'staging-' , but it intentionally sorts lexicographically not most recent, and it's NOT meant to be the next deploy?

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

jrochkind commented 12 years ago

no prob, i'll do what makes sense to me, and do something, and see if anyone other than me wants to use it (if you wanted to use what i end up with, assuming I ever finish, and/or wanted to be a committer on it, and/or wanted to call it the next version of gitflow, I'd be overjoyed, but if you don't, no problem, it'll just get a new name and be my thing).

I have no idea how one would go about polling all the potential users of the thing anyhow!

If I release and then find out someone needs mine to do something different than it does, I'd see if I could make it do that, if I had time and could figure out how, of course.

apinstein commented 12 years ago

Fair enough. Good luck!

On Apr 9, 2012, at 1:59 PM, Jonathan Rochkind wrote:

no prob, i'll do what makes sense to me, and do something, and see if anyone other than me wants to use it (if you wanted to use what i end up with, assuming I ever finish, and/or wanted to be a committer on it, and/or wanted to call it the next version of gitflow, I'd be overjoyed, but if you don't, no problem, it'll just get a new name and be my thing).

I have no idea how one would go about polling all the potential users of the thing anyhow!

If I release and then find out someone needs mine to do something different than it does, I'd see if I could make it do that, if I had time and could figure out how, of course.

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

jrochkind commented 12 years ago

It's intentional that when you promote a staging tag to production, you don't create a new yyyy-hh-tag, it re-uses the exact timestamp etc from staging?

        promote_to_production_tag =~ /^staging-(.*)$/
        new_production_tag = "production-#{$1}"

So if your last staging tag was on March 1, and you're promoting it to production on march 10, the production tag will still look like "production-2012-03-01-ETC". I understand that right, and it's intentional?

apinstein commented 12 years ago

Yes, it was intentional at the time so that you could easily tell corresponding staging and production tags. I am not sure if it's needed if there were a utility to help show deploy history.

I am also not sure how that works now that tags have suffix labels.

Sent from iPhone.

On Apr 9, 2012, at 6:24 PM, Jonathan Rochkindreply@reply.github.com wrote:

It's intentional that when you promote a staging tag to production, you don't create a new yyyy-hh-tag, it re-uses the exact timestamp etc from staging?

       promote_to_production_tag =~ /^staging-(.*)$/
       new_production_tag = "production-#{$1}"

So if your last staging tag was on March 1, and you're promoting it to production on march 10, the production tag will still look like "production-2012-03-01-ETC". I understand that right, and it's intentional?

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

jrochkind commented 12 years ago

okay, thanks. Based on your response, I'm leaning toward re-formulating the tag for production:

Sadly, the opposing argument is: in your current code you're prompted to add the 'what' only for staging, and it makes sense to copy that 'what' over to production, not abandon it or require it to be entered again.

Sigh. Well, nothing's perfect. I'll do what I can and see if anyone other than me wants it!

jrochkind commented 12 years ago

oh, I'm also adding a 'show_tags' option that will show you the last X production or staging tags WITH commit messages, to make it easier to see exactly what dates they were actually tagged, who tagged em, and what the commit message was.

But I'm still not entirely happy with losing the previously interactively entered 'what' on the staging tag when you retag for production. sigh.

jrochkind commented 12 years ago

Okay, I got kind of obsessed on this stuff and worked on it when I should have been working on other things, heh. It was a fun little puzzle.

I have a gem that I think is pretty cool -- basically refactored version of what you're doing to be much more flexible. It does some things differently though, and lacks a couple of potentially important features that you've got. (It's probably got a couple edge case bugs I don't know about yet hiding in there somewhere too, I'd imagine)

Check it out if you have time: https://github.com/jrochkind/cap_git_tools

If you wanted to take it for a test drive and give me feedback, that'd be awesome. It's not actually released as a gem to rubygems yet, but I can do so if that would make it easier for you to test. If you have no time, that's cool too.

If you're interested in being a committer/gem-releaser on my code, happy to make you such.

For the couple potentially important things my version does not do, see the "To Be Done" section of the readme -- it definitely doesn't support the tag formats the way you want at the moment (it hypothetically could, but it's a bit tricky, and I don't personally need/want them so not sure when/if I'd get to it).

Would be happy to get feedback, critique, suggestions, whatever! Also fine if you have no time for such.

technicalpickles commented 9 years ago

For what it's worth, I added @apinstein as a collaborator/owner on the rubygems sometime shortly after the last message in thread.

apinstein commented 9 years ago

We no longer use this project internally; we’re doing something similar but different. y’all do whatever :)

On Aug 17, 2015, at 9:24 AM, Josh Nichols notifications@github.com wrote:

For what it's worth, I added @apinstein https://github.com/apinstein as a collaborator/owner on the rubygems sometime shortly after the last message in thread.

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

bogdanRada commented 8 years ago

Currently capistrano-gitflow supports now capistrano 3 also. If anyone is interested i can submit a pull request here to merge changes from capistrano-gitlflow into this repository also. Let me know please what you think.