* Git - Pushing to a production website
@ 2009-01-10 4:23 4jxDQ6FQee2H
2009-01-10 4:38 ` Boyd Stephen Smith Jr.
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: 4jxDQ6FQee2H @ 2009-01-10 4:23 UTC (permalink / raw)
To: git
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!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Git - Pushing to a production website
2009-01-10 4:23 Git - Pushing to a production website 4jxDQ6FQee2H
@ 2009-01-10 4:38 ` Boyd Stephen Smith Jr.
2009-01-10 4:46 ` 4jxDQ6FQee2H
2009-01-10 5:58 ` david
2009-01-10 6:41 ` Jacob Helwig
` (2 subsequent siblings)
3 siblings, 2 replies; 10+ messages in thread
From: Boyd Stephen Smith Jr. @ 2009-01-10 4:38 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Git - Pushing to a production website
2009-01-10 4:38 ` Boyd Stephen Smith Jr.
@ 2009-01-10 4:46 ` 4jxDQ6FQee2H
2009-01-10 5:04 ` Boyd Stephen Smith Jr.
2009-01-10 5:58 ` david
1 sibling, 1 reply; 10+ messages in thread
From: 4jxDQ6FQee2H @ 2009-01-10 4:46 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Git - Pushing to a production website
2009-01-10 4:46 ` 4jxDQ6FQee2H
@ 2009-01-10 5:04 ` Boyd Stephen Smith Jr.
2009-01-10 5:30 ` 4jxDQ6FQee2H
0 siblings, 1 reply; 10+ messages in thread
From: Boyd Stephen Smith Jr. @ 2009-01-10 5:04 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Git - Pushing to a production website
2009-01-10 5:04 ` Boyd Stephen Smith Jr.
@ 2009-01-10 5:30 ` 4jxDQ6FQee2H
2009-01-10 5:54 ` Boyd Stephen Smith Jr.
0 siblings, 1 reply; 10+ messages in thread
From: 4jxDQ6FQee2H @ 2009-01-10 5:30 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
> > - 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Git - Pushing to a production website
2009-01-10 5:30 ` 4jxDQ6FQee2H
@ 2009-01-10 5:54 ` Boyd Stephen Smith Jr.
0 siblings, 0 replies; 10+ messages in thread
From: Boyd Stephen Smith Jr. @ 2009-01-10 5:54 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Git - Pushing to a production website
2009-01-10 4:38 ` Boyd Stephen Smith Jr.
2009-01-10 4:46 ` 4jxDQ6FQee2H
@ 2009-01-10 5:58 ` david
1 sibling, 0 replies; 10+ messages in thread
From: david @ 2009-01-10 5:58 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: 4jxDQ6FQee2H, git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Git - Pushing to a production website
2009-01-10 4:23 Git - Pushing to a production website 4jxDQ6FQee2H
2009-01-10 4:38 ` Boyd Stephen Smith Jr.
@ 2009-01-10 6:41 ` Jacob Helwig
2009-01-10 11:04 ` David Aguilar
2009-01-10 11:50 ` Sitaram Chamarty
3 siblings, 0 replies; 10+ messages in thread
From: Jacob Helwig @ 2009-01-10 6:41 UTC (permalink / raw)
To: Git; +Cc: 4jxDQ6FQee2H
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
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Git - Pushing to a production website
2009-01-10 4:23 Git - Pushing to a production website 4jxDQ6FQee2H
2009-01-10 4:38 ` Boyd Stephen Smith Jr.
2009-01-10 6:41 ` Jacob Helwig
@ 2009-01-10 11:04 ` David Aguilar
2009-01-10 11:50 ` Sitaram Chamarty
3 siblings, 0 replies; 10+ messages in thread
From: David Aguilar @ 2009-01-10 11:04 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Git - Pushing to a production website
2009-01-10 4:23 Git - Pushing to a production website 4jxDQ6FQee2H
` (2 preceding siblings ...)
2009-01-10 11:04 ` David Aguilar
@ 2009-01-10 11:50 ` Sitaram Chamarty
3 siblings, 0 replies; 10+ messages in thread
From: Sitaram Chamarty @ 2009-01-10 11:50 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-01-10 11:51 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-10 4:23 Git - Pushing to a production website 4jxDQ6FQee2H
2009-01-10 4:38 ` Boyd Stephen Smith Jr.
2009-01-10 4:46 ` 4jxDQ6FQee2H
2009-01-10 5:04 ` Boyd Stephen Smith Jr.
2009-01-10 5:30 ` 4jxDQ6FQee2H
2009-01-10 5:54 ` Boyd Stephen Smith Jr.
2009-01-10 5:58 ` david
2009-01-10 6:41 ` Jacob Helwig
2009-01-10 11:04 ` David Aguilar
2009-01-10 11:50 ` Sitaram Chamarty
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.