Git - Pushing to a production website

Git - Pushing to a production website

[4jxDQ6FQee2H]

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).

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!

Re: Git - Pushing to a production website

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote:
>Our company's website is stored in a GIT Repository.

Interesting.  I like the thought.

>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).
>
>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?

You could simply commit after running the perl script.  You could even commit 
to a branch so that it's (a little) less likely those changes get integrated 
into master.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Git - Pushing to a production website

[4jxDQ6FQee2H]

> You could simply commit after running the perl script.  You could
> even commit to a branch so that it's (a little) less likely those
> changes get integrated into master.

How about this, ran by the post-update hook:


For the first update:

 - Do a git pull
 - Then create a new branch 'working' and checkout
 - Apply the patches to 'working' and commit

This leaves 'working' == 'master^'

For subsequent updates:
 - Compare the SHA1 hashes for 'working' and 'master^'.
   - If they don't match, throw an error and exit
 - Assuming they match, checkout 'master' and delete 'working'
 - Do a git pull
 - Then create a new branch 'working' and checkout
 - Apply the patches to 'working' and commit


This would keep the working directory clean and allow future updates to
occur, if no one commits anything to git 'working'.  If they did, the
script would exit and prevent the update requiring the developer to
review the commit logs and cherry-pick where necessary.

Re: Git - Pushing to a production website

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On Friday 2009 January 09 22:46:18 4jxDQ6FQee2H@dyweni.com wrote:
>> You could simply commit after running the perl script.  You could
>> even commit to a branch so that it's (a little) less likely those
>> changes get integrated into master.
>
>How about this, ran by the post-update hook:
>
>For the first update:
>
> - Do a git pull

I'm not enitirely sure you want post-update doing the pull.

> - Then create a new branch 'working' and checkout
> - Apply the patches to 'working' and commit
>
>This leaves 'working' == 'master^'

Actually, it leaves HEAD == working and master == working^.

>For subsequent updates:
> - Compare the SHA1 hashes for 'working' and 'master^'.
>   - If they don't match, throw an error and exit
> - Assuming they match, checkout 'master' and delete 'working'
> - Do a git pull

(See above)

> - Then create a new branch 'working' and checkout
> - Apply the patches to 'working' and commit
>
>
>This would keep the working directory clean and allow future updates to
>occur, if no one commits anything to git 'working'.  If they did, the
>script would exit and prevent the update requiring the developer to
>review the commit logs and cherry-pick where necessary.

It wouldn't *completely* prevent changes to working as one could "git 
commit --amend" and still have working^ == master.  That said, if developers 
get creative enough they can probably bypass most measures, at least those 
based on a hook.

A privileged process for updates could stash the expected SHA for master and 
working somewhere developers can't write.  That should prevent even dedicated 
developers from making unauthorized changes, modulo security/cryptographic 
exploits.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Git - Pushing to a production website

[4jxDQ6FQee2H]

> > - Do a git pull  
> 
> I'm not enitirely sure you want post-update doing the pull.

Really?

Let's say the website lives in /srv/www/htdocs
Let's also say the git repository lives in /srv/www/git

All developers pull/push from /srv/www/git  (git@server:/srv/www/git)

The website is a clone of /srv/www/git and only tracks 'master'.
Post-update (simplified) changes to /srv/www/htdocs and does 'git pull'.

I'm referencing this article:
  http://jblevins.org/log/tools/managing-websites-with-git

Would you recommend a different way to automatically push any changes
to 'master' down to the website?



> 
> > - Then create a new branch 'working' and checkout
> > - Apply the patches to 'working' and commit
> >
> >This leaves 'working' == 'master^'  
> 
> Actually, it leaves HEAD == working and master == working^.

I'm sorry - I mixed up my terminology.

I am referring to the branch's log.

'working' has 1 more log entry than 'master'.

Example:
 - git log master | grep ^commit | tail -n 2 | head -n 1
 - git log working | grep ^commit | tail -n 1 | head -n 1

Both of these commands should return the same commit hash.

Re: Git - Pushing to a production website

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Friday 09 January 2009, 4jxDQ6FQee2H@dyweni.com wrote about 'Re: Git - 
Pushing to a production website':
>> > - Do a git pull
>>
>> I'm not enitirely sure you want post-update doing the pull.
>
>Let's say the website lives in /srv/www/htdocs
>Let's also say the git repository lives in /srv/www/git
>
>All developers pull/push from /srv/www/git  (git@server:/srv/www/git)
>
>The website is a clone of /srv/www/git and only tracks 'master'.
>Post-update (simplified) changes to /srv/www/htdocs and does 'git pull'.

Ah.  I was assuming you were "git pull"ing in the repository that the hook 
was running from.  In this case you are "git pull"ing in a different 
repository, which should be fine.

>> >This leaves 'working' == 'master^'
>>
>> Actually, it leaves HEAD == working and master == working^.
>
>I'm sorry - I mixed up my terminology.
>
>I am referring to the branch's log.
>
>'working' has 1 more log entry than 'master'.

Yes, which means working^ == master.

commit-ish^ means the first parent of commit-ish
commit-ish^2 means the second parent of commit-ish
commit-ish~2 means the "first grandparent" of commit-ish

>Example:
> - git log master | grep ^commit | tail -n 2 | head -n 1
> - git log working | grep ^commit | tail -n 1 | head -n 1
>
>Both of these commands should return the same commit hash.

As would:
- git rev-parse master
- git rev-parse working^
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Git - Pushing to a production website

[david]

On Fri, 9 Jan 2009, Boyd Stephen Smith Jr. wrote:

> On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote:
>> Our company's website is stored in a GIT Repository.
>
> Interesting.  I like the thought.
>
>> 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).
>>
>> 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?
>
> You could simply commit after running the perl script.  You could even commit
> to a branch so that it's (a little) less likely those changes get integrated
> into master.

one nice thing about git commit is that if there are no changes it doesn't 
make a commit.

I have a couple files on my desktop (firefox status files for example) 
that I have a cron job do a commit on every min so that when firefox 
crashes in a way that can't be recovered by it's 'restore old pages' 
option I can go back and save things anyway.

David Lang

Re: Git - Pushing to a production website

[Jacob Helwig]

On Fri, Jan 9, 2009 at 20:23,  <4jxDQ6FQee2H@dyweni.com> wrote:
> 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.

> 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
>

Re: Git - Pushing to a production website

[David Aguilar]

On Fri, Jan 9, 2009 at 8:23 PM,  <4jxDQ6FQee2H@dyweni.com> wrote:
> 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).

The simplest solution is to not track those files at all.
Instead of tracking app.conf, mv it to app.conf.sample
and track that instead.  Likewise, add an entry for app.conf
in .gitignore.

When devs create new sandboxes they just
        cp app.conf.sample app.conf
and all is well because app.conf is in .gitignore.

If you literally do 'git mv' in a sandbox and push it out then
be careful since pushing that change to production will do
exactly what it was told to do (remove the config).
it's a small price to pay for simplicity, though, so just
remember to keep a backup.


> 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" ...').

Having the config files in .gitignore eliminates a lot of work in
your update hooks and it makes writing this script much easier.

The only extra cost comes in having to manage the config files
separately from the application, but it's nothing that can't be
automated.


> 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!
> --


-- 
    David

Re: Git - Pushing to a production website

[Sitaram Chamarty]

On 2009-01-10, <4jxDQ6FQee2H@dyweni.com> <4jxDQ6FQee2H@dyweni.com> wrote:

> 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).
>
> 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" ...').

Shouldn't they change it in a sandbox and push it to prod
when it gets done instead of directly changing on prod?

> 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?

If you can enforce no changes directly to prod, you can have
the prod server's "master" branch be the one that QA or
whatever pushes to (no direct changes on prod).

You'd manually (one-time) create a branch called
prod_patches where you'd make just the changes needed (port
numbers etc as you said).

This would be the "checked out" branch.

On each push to master, a hook would just "cd wherever; git
rebase master"; the port changes would carry over.