hi @joshbuhler,
related to your topic, I published this one : A git extension to manage .gitignore files
I've just shared another CLI to manage .gitignore files that provides more features. You can take a look if you are interested : gitignore-cli
best regards
Eric
Both GIT_DIR
and GIT_WORK_DIR
are on different servers, simply because for now, I have got a server dedicated to the development part which hosts the bare shared repo and a public production one which hosts websites.
In that case I can clone the dev bare to a prod bare, but it adds a layer of complexity for no real gain.
The question was essentially for my own culture ;)
I will give a look anyway
here another link on Using git to deploy a website
@jwebcat thanks for all ;)
I think the subject is not closed at all.
Your way of using git has opened new perspectives for me.
I'll keep you informed if I find something interesting.
all the best
Eric
@jwebcat
I realized just one thing, but maybe I'm wrong.
The method described above implies to get the bare repo and the website working tree on the same server, isn't it ?
If not, how could you set your post-receive hook to be able to push from the bare repo to the website one, laid out on a different server ?
Any idea ?
@jwebcat
Gosh, I've completly missed the meaning of GIT_WORK_TREE
!
Thanks to have opened my mind ;)
@jwebcat thanks for all your tips.
The remote repo is non bare so has been initialized using git init
.
The reason is simple : this folder contains the web site tree and yes a .git directory. This is the root folder of the web site in a production context.
Not a working directory at all.
It has only one branch.
Git is only used here to update the web site tree. That's all.
It is important not to do any modifications in that directory, otherwise they would be overwritten on the next update.
And as I explained before you can update this repo from your local working dir or from a shared bare repo after a build succeed for example.
Regarding git config receive.denycurrentbranch ignore
, this config setting is mandatory in this case to prevent reject on pushing.
I didn't find another manner to get around this issue, but it is not really a problem.
The main reason I shared the code of the post-receive hook, is that it is generic enough to allow a simple duplication in another web sites without any other kind of customization.
On your side, how is organized your working architecture ?
Eric
@jwebcat thanks for the link.
I've just found it this afternoon ;) and I agree with this article.
But my case is a little bit different, as I don't want to keep changes in the remote repo of my web site.
In fact this repo is not a collaborative working tree.
As I said before, all integrations are made in a local working dir.
These are pushed to a bare remote repository for collaborative work.
Changes are kept here.
But it is very usefull to update your website directly from your computer or directly from the bare repo, once all tests succeed.
You don't need another tool or using a different protocol.
Only git and ssh.
Please, could you keep me informed of your tip ?
I'm very interested.
Eric
@jwebcat
thanks for your comment.
For sure, I'm really interested to see how you can manage a working tree with no .git inside.
Regarding the method described by Abhijit (follow the link above), I use the remote repository in a kind of passive mode. Nothing is made directly in this working tree.
All integrations are made on my local desktop and are only pushed to the remote server.
Then I can't see what kind of problem could happened.
Regards
Eric
Hi,
another subtle alternative : https://gist.github.com/victorbstan/744478