Re: Git - Pushing to a production website
- From
Jacob Helwig <jacob.helwig@gmail.com>
- Date
- Jan 10, 2009, 06:41 UTC
- Message-ID
- <8c9a060901092241y23e56cbbr6aa7f322afaa2f6b@mail.gmail.com>
- In-Reply-To
- <20090109222344.3539138a@family.dyweni.com>
On Fri, Jan 9, 2009 at 20:23, <4jxDQ6FQee2H@dyweni.com> wrote:
Show 9 quoted lines
> Hi, > > Our company's website is stored in a GIT Repository. > > The repository is coded for our test server. When we push updates to > the production server, have manually run a script to patch several > files to make the code work on the production server (i.e. port > numbers, etc). >
Are these all static pages? If they're Perl/PHP/Ruby/whatever, why not add tests for the Live vs. Dev? Check for an environment variable, or a file on disk, etc, etc? That way any checks described below won't get "confused" by the (no longer necessary) patches, and you won't have to worry about rebasing commits, and any potential conflicts there.
Show 17 quoted lines
> I'd like to write a script to email me whenever someone changes files > on the production server without checking those changes back into git > (i.e. running 'git status | grep "nothing to commit" ...'). > > However, this approach get confused by the files patched to work > correctly. > > Is there any way to 'save' those patched files so they don't get > reported by 'git status', yet not mung up the git history every time > we push out an update? > > Thanks! > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >