I don't want the .git directory next to my code.

I don't want the .git directory next to my code.

[Mike]

I'm learning git and I'm really annoyed that the .git directory lives in 
the same directory as my code.  I don't want it there for three reasons:

1. My code lives on a development web server docroot, and I don't want 
the .git repository to end up getting published to the live site by 
accident. (I would imagine this would be a common need.)

2. If I tar/gz my code and deliver it to a client, I don't want the .git 
dir slipping into the tarball, allowing my client to be able to peruse 
the history of what we did and when.

3. The .git respository will get big, especially with binary files in 
it, and I want it someplace with a lot of disk space. And I don't want 
it to get tarred up when we migrate the site to a different server. (And 
tar isn't aware of hard links is it? wonderful.)

How do I make the repository dir live somewhere else, the hell away from 
my code? Thanks

Re: I don't want the .git directory next to my code.

[Randal L. Schwartz]

>>>>> "Mike" == Mike  <fromlists@talkingspider.com> writes:

Mike> I'm learning git and I'm really annoyed that the .git directory lives in
Mike> the same directory as my code.  I don't want it there for three reasons:

Mike> 1. My code lives on a development web server docroot, and I don't want
Mike> the .git repository to end up getting published to the live site by
Mike> accident. (I would imagine this would be a common need.)

Sounds like you need an installer... something that copies your repo into the
live location with things you don't want included left out, and all the
permissions and ownership correct.

Mike> 2. If I tar/gz my code and deliver it to a client, I don't want the .git
Mike> dir slipping into the tarball, allowing my client to be able to peruse
Mike> the history of what we did and when.

git archive --help

Mike> 3. The .git respository will get big, especially with binary files in
Mike> it, and I want it someplace with a lot of disk space. And I don't want
Mike> it to get tarred up when we migrate the site to a different server. (And
Mike> tar isn't aware of hard links is it? wonderful.)

An installer helps here too.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: I don't want the .git directory next to my code.

[Mike]

Randal L. Schwartz wrote:
>>>>>> "Mike" == Mike  <fromlists@talkingspider.com> writes:
> 
> 
> Sounds like you need an installer... something that copies your repo into the
> live location with things you don't want included left out, and all the
> permissions and ownership correct.

If you mean copying files from the development webserver to the live 
server, then the only reason we'd need an installer is because of the 
.git directory, it's the only thing we "don't want included".  And as 
for permissions and ownership, rsync takes care of that.

> 
> git archive --help
>

I got:

$ git archive --help
No manual entry for git-archive

Did I install it wrong?  I have CentOS 5, and I did:

su
yum install git

thanks,
m

Re: I don't want the .git directory next to my code.

[David Symonds]

On Jan 16, 2008 3:07 PM, Mike <fromlists@talkingspider.com> wrote:
>
>
> I got:
>
> $ git archive --help
> No manual entry for git-archive

What's your git version ("git version")? Try just "man git-archive".


Dave.

Re: I don't want the .git directory next to my code.

[Mike]

$ man git-archive
No manual entry for git-archive

David Symonds wrote:
> 
> What's your git version ("git version")? Try just "man git-archive".

Mike wrote at 10:13PM:
 >
 > git version 1.5.2.1

thanks

Re: I don't want the .git directory next to my code.

[Sean]

On Tue, 15 Jan 2008 23:07:22 -0500
Mike <fromlists@talkingspider.com> wrote:


> > git archive --help
> >
> I got:
> 
> $ git archive --help
> No manual entry for git-archive
> 
> Did I install it wrong?  I have CentOS 5, and I did:
> 
> su
> yum install git
> 

Yes, on Centos you probably need "yum install git-core"  which installs all
the assorted pieces and dependencies of Git.

HTH,
Sean

Re: I don't want the .git directory next to my code.

[Mike]

Sean wrote:
> On Tue, 15 Jan 2008 23:07:22 -0500
> Mike <fromlists@talkingspider.com> wrote:
> 
> 
>>> git archive --help
>>>
>> I got:
>>
>> $ git archive --help
>> No manual entry for git-archive
>>
>> Did I install it wrong?  I have CentOS 5, and I did:
>>
>> su
>> yum install git
>>
> 
> Yes, on Centos you probably need "yum install git-core"  which installs all
> the assorted pieces and dependencies of Git.
> 

Thanks but didn't work-

# yum install git-core
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
rpmforge                  100% |=========================| 1.1 kB    00:00
base                      100% |=========================| 1.1 kB    00:00
updates                   100% |=========================|  951 B    00:00
addons                    100% |=========================|  951 B    00:00
extras                    100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
Parsing package install arguments
Nothing to do

Also if this helps, here's what I have for git:

$ rpm -qa | grep -i git
git-1.5.2.1-1.el5.rf
xorg-x11-drv-digitaledge-1.1.0-1.1
perl-Git-1.5.2.1-1.el5.rf

Re: I don't want the .git directory next to my code.

[Neil Macneale]

Mike wrote:
> ....  And as for permissions and ownership, rsync takes care of that.
Perhaps "rsync --exclude *.git"?

It seems to me that you are asking git to be your deployment software, 
which is a bad fit.

Cheers,
Neil

Re: I don't want the .git directory next to my code.

[Mike]

Neil Macneale wrote:
 > Mike wrote:
 >> ....  And as for permissions and ownership, rsync takes care of that.
 > Perhaps "rsync --exclude *.git"?
 >
 > It seems to me that you are asking git to be your deployment software,
 > which is a bad fit.

I'm asking git to get out of my deployment!

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Wed, 16 Jan 2008, Mike wrote:

> Neil Macneale wrote:
> > Mike wrote:
> >> ....  And as for permissions and ownership, rsync takes care of that.
> > Perhaps "rsync --exclude *.git"?
> >
> > It seems to me that you are asking git to be your deployment software,
> > which is a bad fit.
> 
> I'm asking git to get out of my deployment!

But that's easy: rm -rf /usr/bin/git* .git/ ;-)

Hth,
Dscho

Re: I don't want the .git directory next to my code.

[Linus Torvalds]

On Wed, 16 Jan 2008, Mike wrote:
>
> Neil Macneale wrote:
> >
> > It seems to me that you are asking git to be your deployment software,
> > which is a bad fit.
> 
> I'm asking git to get out of my deployment!

I think you mis-understood.

The normal way of handling this is to NOT DO DEVELOPMENT IN YOUR 
DEPLOYMENT TREE!

It's almost always a bad idea to develop in the tree that is also where 
you "export" things, and if you find git annoying in this respect, ask 
yourself why pretty much *every*single*scm*out*there* makes their 
infrastructure even more noticeable (eg CVS subdirectories in every single 
directory etc)

So while you can do various tricks (symlinking ".git", using GIT_DIR, etc 
etc) to get the .git contents out of your worktree, the thing is, the 
correct thing to do is almost always to simply re-think the whole problem, 
and come at it the other way: rather than getting .git out of your 
development tree, you should consider getting your development tree out of 
your deployment area!

Let me do a few examples of why this is a good idea:

 - the whole point of development trees and SCM's (and that's *especially* 
   true with git) is how you can try things out, go backwards in time, and 
   generally just do *development*.

   If you do that in what is your public deployment area, you're already 
   very limited. Not only may you not want to make that .git directory 
   accessible to others (while you *do* obviously want to make the 
   deployment itself), you also end up exposing things like your 
   management scripts and source code along with "generated files" etc 
   that are the things you actually want to deploy.

   Yes, it's certainly quite possible that you simply don't have any 
   management scripts etc, and that you don't generate any files, and you 
   simply want to just deploy the exact files that you also want to track. 
   But that really is a fairly unusual thing to do.

 - with git in particular, you lose a lot of the capabilities if you are 
   forcing yourself to have "deployment == development tree". Things like 
   switching branches for managing different versions suddenly are 
   painful, because you're artificially forcing a 1:1 relationship between 
   "development" and "deployment".

 - Most sane people want to deploy and test separately. In particular, you 
   want to test *before* you deploy. People make mistakes, they don't want 
   to show them. Or there are consistency requirements, and/or you simply 
   want to deploy to multiple sites simultaneously. All of which really 
   re-inforces the "develop separately" mentality, where the actual 
   deployment is then a separate "now I'm ready, let's push out the 
   result".

Now, maybe none of these things are issues at all for you. Good for you. 
But hopefully this explains why most people don't have your issues, and 
why people try to tell you that "deployment software" is a separate thing 
from "source control management", and you often want both, and _want_ to 
keep them separate.

		Linus

Re: I don't want the .git directory next to my code.

[Linus Torvalds]

On Wed, 16 Jan 2008, Linus Torvalds wrote:
> 
>    Yes, it's certainly quite possible that you simply don't have any 
>    management scripts etc, and that you don't generate any files, and you 
>    simply want to just deploy the exact files that you also want to track. 
>    But that really is a fairly unusual thing to do.

Example management scripts: let's say that you have a logo that shows up 
in multiple different sizes. You can just have it as <n> number of 
different files that you check in and update separately, or you can have 
it as *one* scalable master file, and then the deployment script will 
create all the generated files and put them in the deployment area.

So the common issue with SCM's is that you want to share two totally 
different things:

 - the actual "source" (which obviously doesn't have to be source code per 
   se), which is the thing you want to have for yourself and people you 
   work with, and which you want the history of.

 - the "output" for external entities, which may often contain a lot of 
   the "source" verbatim, but quite often doesn't contain it all (some of 
   the stuff you need to manage things may be rather private and purely 
   for *your* management info), and almost invariably contains some 
   post-processing.

Some people don't split this up, and they tend to make horrible horrible 
mistakes, like checking in the *results* of the post-processing too (ie 
binary result blobs that can be regenerated from the other files), because 
they don't make a clear separation between the parts they do development 
on, and the end result.

			Linus

Re: I don't want the .git directory next to my code.

[Mike]

Linus Torvalds wrote:

> Some people don't split this up, and they tend to make horrible horrible 
> mistakes, like checking in the *results* of the post-processing too (ie 
> binary result blobs that can be regenerated from the other files), because 
> they don't make a clear separation between the parts they do development 
> on, and the end result.

Honestly, I think your mode of thinking is centered around compiled 
languages and linux app(/kernel) development.  The web app 
development/deployment model is very different.

With PHP, Python, and Ruby, the development is the deployment.  The 
source is the output.  You can't develop web apps in those languages 
unless the source files you're working on are under the doc root of your 
development server.   "the parts they do development on" and "the end 
result" *are* the same files.

The "development server -> staging server -> live
server" model has been around in common use for as long as web
applications have. In fact, the term "deployment" falls apart here. 
 From my web app developer perspective, the deployment is what lands on 
the live server.  For your git perspective, the "deployment" may mean 
the .../docroot/php directory for the development server (where our app 
code lives).

There's a fundamental "best practice" of web development being violated 
here- keep your docroots clean, only put stuff in them that should go 
live (or should eventually go live when ready).  Other files should not 
live under docroot.

Among the reasons for that is security.  If one of those .git dirs does 
slip out and go live, it's a *huge* *gaping* *security* *hole*.  You 
could download the repository because those files don't have extensions, 
so the browser would just download them. I could write a spider that 
crawls around the web appending /.git to urls.

If we end up having to write a special "publisher" app to move files 
from dev to live, then it will only be because of those damn .git 
directories.  More likely we'd add some exclusions into an rsync 
wrapper, I guess. And then still worry about tarring up the docroot (not 
all of which is gitted).  And then worry that some young developer on 
the team might SCP a directory's contents and he didn't notice that .git 
dir because it doesn't show up under "ls" or the "ll" alias.

Maybe git just isn't intended to be used for anything besides compiled
languages like c?  Or maybe just not for web app development?

Finally, to this statement:

> It's almost always a bad idea to develop in the tree that is also where
> you "export" things, and if you find git annoying in this respect, ask
> yourself why pretty much *every*single*scm*out*there* makes their
> infrastructure even more noticeable (eg CVS subdirectories in every 
single
> directory etc)

I don't think that pointing at other SCM's practices as the authority is 
the stance you really want to take. I can direct you to a video of a 
speech by a brilliant guy, in front of some googlers, where he explains 
that the entire reason he started the git project is because of the 
problems with "*every*single*scm*out*there*".

Mike

Re: I don't want the .git directory next to my code.

[Kris Shannon]

Mike wrote:
> 
> 
> Linus Torvalds wrote:
> 
>> Some people don't split this up, and they tend to make horrible 
>> horrible mistakes, like checking in the *results* of the 
>> post-processing too (ie binary result blobs that can be regenerated 
>> from the other files), because they don't make a clear separation 
>> between the parts they do development on, and the end result.
> 
> Honestly, I think your mode of thinking is centered around compiled 
> languages and linux app(/kernel) development.  The web app 
> development/deployment model is very different.
> 
> With PHP, Python, and Ruby, the development is the deployment.  The 
> source is the output.  You can't develop web apps in those languages 
> unless the source files you're working on are under the doc root of your 
> development server.   "the parts they do development on" and "the end 
> result" *are* the same files.

Not for me.  I've always had my source separate from development docroot
even before I was using proper SCM's.  I've written stuff in all three
languages you mention where deployment to the docroot (development or not)
was more than a simple copy.

Re: I don't want the .git directory next to my code.

[Wincent Colaiuta]

El 17/1/2008, a las 6:42, Mike escribió:

> Linus Torvalds wrote:
>
>> Some people don't split this up, and they tend to make horrible  
>> horrible mistakes, like checking in the *results* of the post- 
>> processing too (ie binary result blobs that can be regenerated from  
>> the other files), because they don't make a clear separation  
>> between the parts they do development on, and the end result.
>
> Honestly, I think your mode of thinking is centered around compiled  
> languages and linux app(/kernel) development.  The web app  
> development/deployment model is very different.
>
> With PHP, Python, and Ruby, the development is the deployment.  The  
> source is the output.  You can't develop web apps in those languages  
> unless the source files you're working on are under the doc root of  
> your development server.   "the parts they do development on" and  
> "the end result" *are* the same files.
>
> The "development server -> staging server -> live
> server" model has been around in common use for as long as web
> applications have. In fact, the term "deployment" falls apart here.  
> From my web app developer perspective, the deployment is what lands  
> on the live server.  For your git perspective, the "deployment" may  
> mean the .../docroot/php directory for the development server (where  
> our app code lives).

I don't think so. Most people I speak with doing web app development  
develop locally and deploy remotely.

> There's a fundamental "best practice" of web development being  
> violated here- keep your docroots clean, only put stuff in them that  
> should go live (or should eventually go live when ready).  Other  
> files should not live under docroot.

Assuming you're using Apache, why don't you just add an .htaccess file  
to your repo at the top level which instructs Apache to forbid all  
access to .git and its contents? If Apache is so broken that you can't  
trust Apache to forbid access in those circumstances, then you can't  
trust it to not allow access to arbitrary paths on your filesystem  
outside of your doc root anyway.

Cheers,
Wincent

Re: I don't want the .git directory next to my code.

[Jeff King]

On Thu, Jan 17, 2008 at 12:42:28AM -0500, Mike wrote:

> If we end up having to write a special "publisher" app to move files from 
> dev to live, then it will only be because of those damn .git directories.  
> More likely we'd add some exclusions into an rsync wrapper, I guess. And 
> then still worry about tarring up the docroot (not all of which is 
> gitted).  And then worry that some young developer on the team might SCP a 
> directory's contents and he didn't notice that .git dir because it doesn't 
> show up under "ls" or the "ll" alias.

What is it that you want? You're worried about .git directories. Fine.
There have been _many_ responses suggesting solutions, including:

  - having a deployment step which does the right thing
  - moving .git away, and using --git-dir or GIT_DIR to specify it
    manually
  - moving .git away, using core.worktree, and doing git operations from
    the repo directory
  - moving .git away, and having your shell automagically update GIT_DIR
    based on your current directory
  - moving .git away, wrapping 'git' with a script that sets GIT_DIR
    according to some mapping (I think somebody mentioning just mapping
    /path/to/tree to /var/git/path/to/tree or similar, but obviously you
    could make a custom mapping in a hard-coded file).

You don't seem happy with any of those. But the fact remains that the
git repo has to be stored _somewhere_, and when you run git, there needs
to be some mapping telling it which git repo matches your working
directory. So how _do_ you want to specify that mapping? 

-Peff

Re: I don't want the .git directory next to my code.

[Linus Torvalds]

On Thu, 17 Jan 2008, Jeff King wrote:
> 
> You don't seem happy with any of those. But the fact remains that the
> git repo has to be stored _somewhere_, and when you run git, there needs
> to be some mapping telling it which git repo matches your working
> directory. So how _do_ you want to specify that mapping? 

Ok, here's the ugliest idea *ever*:

We could actually use POSIX extended attributes (or whatever 
system-specific version of it a particular filesystem supports) for people 
who *really* don't want to pollute their file structure.

I know, I know, it's horrible. It's one of those things that would 
actually be reqlly convenient (and probably even pretty easy to 
implement), but is also going to be *really* subtle when it breaks.

But I bet some people would like it. I personally tend to hate extended 
attributes (they tend to have serious problems with anything that moves 
things around or backs them up - especially across filesystem boundaries), 
but there is no question that they can't be convenient to hide 
information.

Anyway, here's a really stupid patch. It kind of works, but it has no way 
to turn this off.

On at least Linux, with this you can do something like

	.. start off with a git directory ..
	mv .git /external/git/location
	setfattr -n user.git-dir -v /external/git/location .

and now that "user.git-dir" thing acts as a kind of invisible "symlink" to 
the external git directory.

Not exactly heavily tested, and I don't know how portable the whole xattr 
thing is (ie I know OS X has file attributes, I just don't know if the 
interface is at all similar).

I don't like extended attributes myself, but this patch really is pretty 
simple and perhaps useful.

			Linus

---
 setup.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/setup.c b/setup.c
index adede16..97865f4 100644
--- a/setup.c
+++ b/setup.c
@@ -1,5 +1,6 @@
 #include "cache.h"
 #include "dir.h"
+#include <attr/xattr.h>
 
 static int inside_git_dir = -1;
 static int inside_work_tree = -1;
@@ -302,6 +303,9 @@ const char *setup_git_directory_gently(int *nongit_ok)
 	 */
 	offset = len = strlen(cwd);
 	for (;;) {
+		int attr_len;
+		static char git_dir[PATH_MAX];
+
 		if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))
 			break;
 		if (is_git_directory(".")) {
@@ -312,6 +316,14 @@ const char *setup_git_directory_gently(int *nongit_ok)
 			check_repository_format_gently(nongit_ok);
 			return NULL;
 		}
+		attr_len = getxattr(".", "user.git-dir", git_dir, sizeof(git_dir)-1);
+		if (attr_len > 0) {
+			git_dir[attr_len] = 0;
+			if (is_git_directory(git_dir)) {
+				setenv(GIT_DIR_ENVIRONMENT, git_dir, 1);
+				break;
+			}
+		}
 		chdir("..");
 		do {
 			if (!offset) {

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Thu, 17 Jan 2008, Linus Torvalds wrote:

> Ok, here's the ugliest idea *ever*:

Okay, you won.

> diff --git a/setup.c b/setup.c
> index adede16..97865f4 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -1,5 +1,6 @@
>  #include "cache.h"
>  #include "dir.h"
> +#include <attr/xattr.h>
>  
>  static int inside_git_dir = -1;
>  static int inside_work_tree = -1;
> @@ -302,6 +303,9 @@ const char *setup_git_directory_gently(int *nongit_ok)
>  	 */
>  	offset = len = strlen(cwd);
>  	for (;;) {
> +		int attr_len;
> +		static char git_dir[PATH_MAX];
> +
>  		if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))
>  			break;
>  		if (is_git_directory(".")) {
> @@ -312,6 +316,14 @@ const char *setup_git_directory_gently(int *nongit_ok)
>  			check_repository_format_gently(nongit_ok);
>  			return NULL;
>  		}
> +		attr_len = getxattr(".", "user.git-dir", git_dir, sizeof(git_dir)-1);
> +		if (attr_len > 0) {
> +			git_dir[attr_len] = 0;
> +			if (is_git_directory(git_dir)) {
> +				setenv(GIT_DIR_ENVIRONMENT, git_dir, 1);
> +				break;

What's this break all about?

> +			}
> +		}
>  		chdir("..");
>  		do {
>  			if (!offset) {

Ciao,
Dscho

Re: I don't want the .git directory next to my code.

[Linus Torvalds]

On Thu, 17 Jan 2008, Johannes Schindelin wrote:
>
> > Ok, here's the ugliest idea *ever*:
> 
> Okay, you won.

"I would like to thank the Academy for giving me this honor. I couldn't 
 have done this without my parents, my teachers in high school, and the 
 girl next-door.."

> > +		attr_len = getxattr(".", "user.git-dir", git_dir, sizeof(git_dir)-1);
> > +		if (attr_len > 0) {
> > +			git_dir[attr_len] = 0;
> > +			if (is_git_directory(git_dir)) {
> > +				setenv(GIT_DIR_ENVIRONMENT, git_dir, 1);
> > +				break;
> 
> What's this break all about?

Without the break, it will consider it a failure, and try to go up the 
directory structure ("..") to find the next thing.

In other words, that "break" is exactly the same break as the one just a 
few lines earlier:

                if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))
                        break;

ie if we found a good git directory, we want to use it.

		Linus

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Thu, 17 Jan 2008, Linus Torvalds wrote:

> On Thu, 17 Jan 2008, Johannes Schindelin wrote:
> >
> > > Ok, here's the ugliest idea *ever*:
> > 
> > Okay, you won.
> 
> "I would like to thank the Academy for giving me this honor. I couldn't
>  have done this without my parents, my teachers in high school, and the 
>  girl next-door.."

You forgot the tears.

> > > +		attr_len = getxattr(".", "user.git-dir", git_dir, sizeof(git_dir)-1);
> > > +		if (attr_len > 0) {
> > > +			git_dir[attr_len] = 0;
> > > +			if (is_git_directory(git_dir)) {
> > > +				setenv(GIT_DIR_ENVIRONMENT, git_dir, 1);
> > > +				break;
> > 
> > What's this break all about?
> 
> Without the break, it will consider it a failure, and try to go up the 
> directory structure ("..") to find the next thing.

Ah, but of course.  For some reason I expected this code outside of the 
loop, but it _has_ to be inside.

Thanks for enlightening a poor schmock,
Dscho

Re: I don't want the .git directory next to my code.

[Mike]

Jeff King wrote:
>   - moving .git away, and using --git-dir or GIT_DIR to specify it
>     manually

Actually, git-dir is sufficient for our needs, thanks.  I haven't been 
able to get my hands on man pages for git until this morning.  (If you 
look near the top of this thread you see that I don't have the git man 
pages because apparently CentOS (and probably RHEL too), doesn't include 
them when you "yum install git").

Linus posted a response about deployment and development being 
separated, so I had to point out why that doesn't work for web apps in 
interpreted languages.

You guys might want to complain to the CentOS (and/or RHEL) maintainers 
to have them put the man pages into the yum rpm. Er or whoever maintains 
that (they maintain that rpm, right? I don't know).

Thanks, Jeff,

mike

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Thu, 17 Jan 2008, Mike wrote:

> I haven't been able to get my hands on man pages for git until this 
> morning.

Googling for "git man pages" gives you 

http://www.kernel.org/pub/software/scm/git/docs/

as first hit.  That should work even on a bare-bones CentOS.

Hth,
Dscho

Re: I don't want the .git directory next to my code.

[Mike]

Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 17 Jan 2008, Mike wrote:
> 
>> I haven't been able to get my hands on man pages for git until this 
>> morning.
> 
> Googling for "git man pages" gives you 
> 
> http://www.kernel.org/pub/software/scm/git/docs/
> 
> as first hit.  That should work even on a bare-bones CentOS.

Yea, I had googled for "git manpages". Which doesn't.

mike

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Thu, 17 Jan 2008, Mike wrote:

> Johannes Schindelin wrote:
> 
> > On Thu, 17 Jan 2008, Mike wrote:
> > 
> > > I haven't been able to get my hands on man pages for git until this 
> > > morning.
> > 
> > Googling for "git man pages" gives you 
> > http://www.kernel.org/pub/software/scm/git/docs/
> > as first hit.  That should work even on a bare-bones CentOS.
> 
> Yea, I had googled for "git manpages". Which doesn't.

It does here.  Just checked.

Ciao,
Dscho

Re: I don't want the .git directory next to my code.

[Mike]

Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 17 Jan 2008, Mike wrote:
> 
>> Johannes Schindelin wrote:
>>
>>> On Thu, 17 Jan 2008, Mike wrote:
>>>
>>>> I haven't been able to get my hands on man pages for git until this 
>>>> morning.
>>> Googling for "git man pages" gives you 
>>> http://www.kernel.org/pub/software/scm/git/docs/
>>> as first hit.  That should work even on a bare-bones CentOS.
>> Yea, I had googled for "git manpages". Which doesn't.
> 
> It does here.  Just checked.


http://www.google.com/search?hl=en&q=%22git+manpages%22&btnG=Google+Search

The first result I get is :

http://www.cygwin.com/ml/cygwin/2008-01/msg00101.html

And nothing on the first or second page seems to point to git manpages.

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Thu, 17 Jan 2008, Mike wrote:

> Johannes Schindelin wrote:
> 
> > On Thu, 17 Jan 2008, Mike wrote:
> > 
> > > Johannes Schindelin wrote:
> > > 
> > > > On Thu, 17 Jan 2008, Mike wrote:
> > > > 
> > > > > I haven't been able to get my hands on man pages for git until 
> > > > > this morning.
> > > > Googling for "git man pages" gives you 
> > > > http://www.kernel.org/pub/software/scm/git/docs/ as first hit.  
> > > > That should work even on a bare-bones CentOS.
> > > Yea, I had googled for "git manpages". Which doesn't.
> > 
> > It does here.  Just checked.
> 
> http://www.google.com/search?hl=en&q=%22git+manpages%22&btnG=Google+Search
> 
> The first result I get is :
> 
> http://www.cygwin.com/ml/cygwin/2008-01/msg00101.html
> 
> And nothing on the first or second page seems to point to git manpages.

http://www.google.co.uk/search?q=git+manpages&ie=utf-8&oe=utf-8&rls=org.mozilla:de:official&client=firefox-a

And the first hit is what I said.

Hth,
Dscho

Re: I don't want the .git directory next to my code.

[Mike]

Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 17 Jan 2008, Mike wrote:
> 
>> Johannes Schindelin wrote:
>>
>>> On Thu, 17 Jan 2008, Mike wrote:
>>>
>>>> Johannes Schindelin wrote:
>>>>
>>>>> On Thu, 17 Jan 2008, Mike wrote:
>>>>>
>>>>>> I haven't been able to get my hands on man pages for git until 
>>>>>> this morning.
>>>>> Googling for "git man pages" gives you 
>>>>> http://www.kernel.org/pub/software/scm/git/docs/ as first hit.  
>>>>> That should work even on a bare-bones CentOS.
>>>> Yea, I had googled for "git manpages". Which doesn't.
>>> It does here.  Just checked.
>> http://www.google.com/search?hl=en&q=%22git+manpages%22&btnG=Google+Search
>>
>> The first result I get is :
>>
>> http://www.cygwin.com/ml/cygwin/2008-01/msg00101.html
>>
>> And nothing on the first or second page seems to point to git manpages.
> 
> http://www.google.co.uk/search?q=git+manpages&ie=utf-8&oe=utf-8&rls=org.mozilla:de:official&client=firefox-a
> 
> And the first hit is what I said.
> 
> Hth,
> Dscho
> 


You didn't try my url, did you.

I had put "git manpages" in quotes.  Google searches differently with 
quotes and without.

Try my url next time. That's why I provide it.

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Thu, 17 Jan 2008, Mike wrote:

> I had put "git manpages" in quotes.

Why on earth?

> Try my url next time. That's why I provide it.

Try a better url next time.  Some url like mine.  A url which works.

Have a nice life,
Dscho

Re: I don't want the .git directory next to my code.

[David Symonds]

On Jan 18, 2008 6:12 AM, Mike <fromlists@talkingspider.com> wrote:
>
> You guys might want to complain to the CentOS (and/or RHEL) maintainers
> to have them put the man pages into the yum rpm. Er or whoever maintains
> that (they maintain that rpm, right? I don't know).

Maybe *you* might want to, since you were the one affected, and
everyone else here is busy doing other things.


Dave.

Re: I don't want the .git directory next to my code.

[Russ Dill]

> Linus posted a response about deployment and development being
> separated, so I had to point out why that doesn't work for web apps in
> interpreted languages.
>

If your primary concern is preventing information leakage, then a
publish model is absolutely what you want. You definetely don't want
some random intermediary file out on the server, or some file that was
never checked into source control.

By publish, I don't just mean to the public server, I also mean to
whatever development roots you have.

With a good publishing model and a good SCM, you also get
reproducibility and testability as well. Its easy to ensure that what
is checked into source control is what you are testing, and its easy
to rollback production servers to a different version.

Re: I don't want the .git directory next to my code.

[Martin Langhoff]

On Jan 17, 2008 6:42 PM, Mike <fromlists@talkingspider.com> wrote:
> With PHP, Python, and Ruby, the development is the deployment.  The

Plenty here use git for web apps.

> There's a fundamental "best practice" of web development being violated
> here- keep your docroots clean, only put stuff in them that should go
> live (or should eventually go live when ready).  Other files should not
> live under docroot.

*First* - people here have pointed out various ways of doing this with
the GIT_DIR env variable. Nothing is being violated.

In terms of the best-practice you mention of publishing only the
reachable files, your checkout is one directory higher. The top-level
dir of your checkout should look like:

  .git
  htdocs # this is published
  conf # configuration files
  lib # libraries

if you publish the top of your checkout, your libraries sit in there.
Along your .git and your config files.

> Among the reasons for that is security.  If one of those .git dirs does
> slip out and go live, it's a *huge* *gaping* *security* *hole*.  You

Well -- I routinely add .git CVS and .svn to http.conf with a
directorymatch clause to prevent access to them. Just in case,
belts-and-suspenders.

> If we end up having to write a special "publisher" app to move files
> from dev to live, then it will only be because of those damn .git
> directories.

Nah! It'll be because of a long list of things, including temp files,
backup files that developers make, all sorts of things in your *work*
dir that you really need there and you really should _not_ have in the
production checkout.

BTW, I also add common patterns for those temp files to httpd.conf to
restrict access to them.

> Maybe git just isn't intended to be used for anything besides compiled
> languages like c?  Or maybe just not for web app development?

C produces a ton of intermediary files that git never commits, and C
projects usually get an "installer" too (debian's apt/dpkg, rpm, etc).
Writing PHP/Ruby/Python produces less "intermediary" files, but it
still creates some, so there's plenty of good reasons to have an
"installer".

GIT does the SCM thing, but for handling your deployment you need
something else. I normally use scripts that use git internally,
written in make, perl or shell.

cheers,



martin

Re: I don't want the .git directory next to my code.

[Andreas Ericsson]

Mike wrote:
> 
> 
> Linus Torvalds wrote:
> 
>> Some people don't split this up, and they tend to make horrible 
>> horrible mistakes, like checking in the *results* of the 
>> post-processing too (ie binary result blobs that can be regenerated 
>> from the other files), because they don't make a clear separation 
>> between the parts they do development on, and the end result.
> 
> Honestly, I think your mode of thinking is centered around compiled 
> languages and linux app(/kernel) development.  The web app 
> development/deployment model is very different.
> 
> With PHP, Python, and Ruby, the development is the deployment.  The 
> source is the output.  You can't develop web apps in those languages 
> unless the source files you're working on are under the doc root of your 
> development server.   "the parts they do development on" and "the end 
> result" *are* the same files.
> 

We develop several different PHP packages. We have a test-server where
pandemonium reings with regards to .git directories and which branches
are checked out where. We also have a release process, and .git dirs
*never* end up on production servers.

The release-process is this: "git tag -s $tag_name; git push $tag_name".
The update-hook then marks the repo as having a new release and a cron-
job, running every 5 minutes, takes care of updating our production
servers. It took me all of 30 minutes to hack up, and not only does it
make sure we never publish the .git directory, it also makes it really,
really easy for <insert-non-git-savvy-customer-X> to report a version in
which he or she has spotted a bug.

> 
> There's a fundamental "best practice" of web development being violated 
> here- keep your docroots clean, only put stuff in them that should go 
> live (or should eventually go live when ready).  Other files should not 
> live under docroot.
> 

You accomplish that by making sure only stable and signed versions hit
the deployment server(s). Manual scp/rsync/ftp-mirroring of the testing
server's docroot is just plain stupid.

> 
> Maybe git just isn't intended to be used for anything besides compiled
> languages like c?  Or maybe just not for web app development?
> 

Well, it was originally intended to manage the Linux kernel, but it's
written in such a way as to be capable of competently manage just about
anything.


> Finally, to this statement:
> 
>> It's almost always a bad idea to develop in the tree that is also where
>> you "export" things, and if you find git annoying in this respect, ask
>> yourself why pretty much *every*single*scm*out*there* makes their
>> infrastructure even more noticeable (eg CVS subdirectories in every 
> single
>> directory etc)
> 
> I don't think that pointing at other SCM's practices as the authority is 
> the stance you really want to take. I can direct you to a video of a 
> speech by a brilliant guy, in front of some googlers, where he explains 
> that the entire reason he started the git project is because of the 
> problems with "*every*single*scm*out*there*".
> 

Those problems aren't "all the scm's in the world store their meta-data
somewhere!" though, and the ability to tar up a working-tree and get the
git-directory too is not always a bad thing. It's just your release
process that needs to eliminate the manual step there so you never copy
it by accident. That's why people write small and simple scripts though.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: I don't want the .git directory next to my code.

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Let me do a few examples of why this is a good idea:
>
>  - the whole point of development trees and SCM's (and that's *especially* 
>    true with git) is how you can try things out, go backwards in time, and 
>    generally just do *development*.
>
>    If you do that in what is your public deployment area, you're already 
>    very limited. Not only may you not want to make that .git directory 
>    accessible to others (while you *do* obviously want to make the 
>    deployment itself), you also end up exposing things like your 
>    management scripts and source code along with "generated files" etc 
>    that are the things you actually want to deploy.
>
>    Yes, it's certainly quite possible that you simply don't have any 
>    management scripts etc, and that you don't generate any files, and you 
>    simply want to just deploy the exact files that you also want to track. 

Even without any management script, you cannot do any _development_
in such a tree.  By definition, mucking with the files in the
deployment area means all of your changes are immediately visible by
the clients.

One reason (admittedly misguided) people mentioned why they want
to do this is because they want to be able to "git-add" files
generated on the deployed server by client actions (think of a
Wiki that drops new contents in an area writable by the
webserver).  If your deployment area is _not_ managed by git,
they instead need to write a Makefile target in their
development area that takes new/modified files back to the
development tree and "git-add" those copies.

The right way to manage these client-generated contents would of
course be to commit them to a branch separate from the sources
you develop (otherwise your history will be a mixed mess between
the true development and client content changes), so the
argument is very weak and is not a good justification for
wanting to have deployment and development tree as one.

But I can well imagine that it is a tempting way to work for
people who have not thought about the reason why history
matters, especially for the ones who still suffer from CVS
braindamage that makes separate branches inpractical.

Re: I don't want the .git directory next to my code.

[Ping Yin]

On Jan 17, 2008 2:15 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
>

>
>  - Most sane people want to deploy and test separately. In particular, you
>   want to test *before* you deploy. People make mistakes, they don't want
>   to show them. Or there are consistency requirements, and/or you simply
>   want to deploy to multiple sites simultaneously. All of which really
>   re-inforces the "develop separately" mentality, where the actual
>   deployment is then a separate "now I'm ready, let's push out the
>   result".
>
Using git to manage deployment environment and even as deployment
tools is not always a bad idea.

1. In case where development and deployment environment are almost the
same, such as html files, js files, binding the two environments as
one is convenient.

2. Event In the case where the two environement are different very
much, managing deployment environment in git sometimes still seems
good, since we can easily back to any earlier version or fix some
urgent bug ASAP (surely for the non-generated files).

3. Use 'git pull' as deploy command seems simple enough.

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



-- 
Ping Yin

Re: I don't want the .git directory next to my code.

[Linus Torvalds]

On Thu, 17 Jan 2008, Ping Yin wrote:
>
> Using git to manage deployment environment and even as deployment
> tools is not always a bad idea.

I don't think it's alway sa bad idea, no. But it's a good idea only if you 
then accept things like ".git" subdirectories lying around in your 
deployment area (or you accept the use of tricks like GIT_DIR).

> 1. In case where development and deployment environment are almost the
> same, such as html files, js files, binding the two environments as
> one is convenient.
> 
> 2. Event In the case where the two environement are different very
> much, managing deployment environment in git sometimes still seems
> good, since we can easily back to any earlier version or fix some
> urgent bug ASAP (surely for the non-generated files).
> 
> 3. Use 'git pull' as deploy command seems simple enough.

Hey, I do it for all my kernels ("git pull" + "make" is just simpler than 
pushing tar-balls around), so I'm not entirely disagreeing. I *like* 
having the entire development environment around everywhere.

But it does seem like a lot of Mike's problems basically boil down to the 
fact that he doesn't really want to use it as a deployment tool.

		Linus

Re: I don't want the .git directory next to my code.

[Dan McGee]

On 01/15/2008 09:27 PM, Mike wrote:
> 
> How do I make the repository dir live somewhere else, the hell away from
> my code? Thanks

mv .git <location to move to>
ln -s <location moved to> .git

Did you try this before you sent your email?

-Dan

Re: I don't want the .git directory next to my code.

[Mike]

Dan McGee wrote:
> On 01/15/2008 09:27 PM, Mike wrote:
>> How do I make the repository dir live somewhere else, the hell away from
>> my code? Thanks
> 
> mv .git <location to move to>
> ln -s <location moved to> .git
> 
> Did you try this before you sent your email?

No, good idea. But it didn't work.  When I git commit -a, I get "fatal: 
Not a git repository"

(And also even if that worked, it wouldn't work on an NTFS partiton, 
right...)

Re: I don't want the .git directory next to my code.

[Mike Krier]

Mike wrote:
> 
> No, good idea. But it didn't work.  When I git commit -a, I get "fatal: 
> Not a git repository"
> 
> (And also even if that worked, it wouldn't work on an NTFS partiton, 
> right...)

Wait, it worked!  thanks!

Hmm although some of our code is (necessarily) on an NTFS partition... hmm..

Re: I don't want the .git directory next to my code.

[Mike]

Mike wrote:
> 
> No, good idea. But it didn't work.  When I git commit -a, I get "fatal: 
> Not a git repository"
> 
> (And also even if that worked, it wouldn't work on an NTFS partiton, 
> right...)

Wait, it worked!  thanks!

Hmm although some of our code is (necessarily) on an NTFS partition... hmm..

Re: I don't want the .git directory next to my code.

[Nguyen Thai Ngoc Duy]

On Jan 16, 2008 10:27 AM, Mike <fromlists@talkingspider.com> wrote:
>
> I'm learning git and I'm really annoyed that the .git directory lives in
> the same directory as my code.  I don't want it there for three reasons:
>
> 1. My code lives on a development web server docroot, and I don't want
> the .git repository to end up getting published to the live site by
> accident. (I would imagine this would be a common need.)
>
> 2. If I tar/gz my code and deliver it to a client, I don't want the .git
> dir slipping into the tarball, allowing my client to be able to peruse
> the history of what we did and when.
>
> 3. The .git respository will get big, especially with binary files in
> it, and I want it someplace with a lot of disk space. And I don't want
> it to get tarred up when we migrate the site to a different server. (And
> tar isn't aware of hard links is it? wonderful.)
>
> How do I make the repository dir live somewhere else, the hell away from
> my code? Thanks

Setup GIT_WORK_TREE and GIT_DIR env variables or use --git-dir and
--work-tree together. See "man git" for more detail.
-- 
Duy

Re: I don't want the .git directory next to my code.

[David Symonds]

On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
>
> 2. If I tar/gz my code and deliver it to a client, I don't want the .git
> dir slipping into the tarball, allowing my client to be able to peruse
> the history of what we did and when.

Use git-archive.


Dave.

Re: I don't want the .git directory next to my code.

[Mike]

David Symonds wrote:
> On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
>> 2. If I tar/gz my code and deliver it to a client, I don't want the .git
>> dir slipping into the tarball, allowing my client to be able to peruse
>> the history of what we did and when.
> 
> Use git-archive.
> 

Thanks but this isn't sufficient. If we have one directory of our web 
root in a git repository, say docroot/php, and we tar up docroot, it 
will include php/.git.  We don't want that.  We would have to go out of 
our way to avoid the .git directory.  The point is, we don't want 
anything in docroot that shouldn't be made live.

Re: I don't want the .git directory next to my code.

[Daniel Barkalow]

On Tue, 15 Jan 2008, Mike wrote:

> David Symonds wrote:
> > On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
> > > 2. If I tar/gz my code and deliver it to a client, I don't want the .git
> > > dir slipping into the tarball, allowing my client to be able to peruse
> > > the history of what we did and when.
> > 
> > Use git-archive.
> > 
> 
> Thanks but this isn't sufficient. If we have one directory of our web root in
> a git repository, say docroot/php, and we tar up docroot, it will include
> php/.git.  We don't want that.  We would have to go out of our way to avoid
> the .git directory.  The point is, we don't want anything in docroot that
> shouldn't be made live.

I don't know about you, but my source directories get lots of other 
junk: editor backup files, half-written scripts, debugging output, etc. 
Furthermore, there's the issue of whether you can accidentally distribute 
something you haven't added to your version control yet and therefore 
can't reproduce. It's just a lot cleaner to deploy and distribute out of 
the version control system instead of out of a working directory.

I don't know why you don't seem to have git-archive (or its manpage); it's 
in the version you have. Maybe it didn't get into the deb-generation files 
at the time? You might have git-tar-tree instead, though.

	-Daniel
*This .sig left intentionally blank*

Re: I don't want the .git directory next to my code.

[Luke Lu]

On Jan 15, 2008, at 8:18 PM, Mike wrote:

>
> David Symonds wrote:
>> On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
>>> 2. If I tar/gz my code and deliver it to a client, I don't want  
>>> the .git
>>> dir slipping into the tarball, allowing my client to be able to  
>>> peruse
>>> the history of what we did and when.
>> Use git-archive.
>
> Thanks but this isn't sufficient. If we have one directory of our  
> web root in a git repository, say docroot/php, and we tar up  
> docroot, it will include php/.git.  We don't want that.  We would  
> have to go out of our way to avoid the .git directory.  The point  
> is, we don't want anything in docroot that shouldn't be made live.

git-archive generates an archive file *without* the .git directory.  
 From git-archive(1):

   git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ &&  
tar xf -)
               Create a tar archive that contains the contents of the  
latest
               commit on the current branch, and extracts it in /var/ 
tmp/junk
               directory.

   git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >  
git-1.4.0.tar.gz
               Create a compressed tarball for v1.4.0 release.

   git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip  
 >git-1.4.0.tar.gz
               Create a compressed tarball for v1.4.0 release, but  
without a
               global extended pax header.

   git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ >  
git-1.4.0-docs.zip
               Put everything in the current head's Documentation/  
directory
               into git-1.4.0-docs.zip, with the prefix git-docs/.

IMHO, git export is probably a better name for the command. git- 
archive sounds like backup everything associated with git.

__Luke

Re: I don't want the .git directory next to my code.

[Mike]

Luke Lu wrote:
> 
> On Jan 15, 2008, at 8:18 PM, Mike wrote:
> 
>>
>> David Symonds wrote:
>>> On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
>>>> 2. If I tar/gz my code and deliver it to a client, I don't want the 
>>>> .git
>>>> dir slipping into the tarball, allowing my client to be able to peruse
>>>> the history of what we did and when.
>>> Use git-archive.
>>
>> Thanks but this isn't sufficient. If we have one directory of our web 
>> root in a git repository, say docroot/php, and we tar up docroot, it 
>> will include php/.git.  We don't want that.  We would have to go out 
>> of our way to avoid the .git directory.  The point is, we don't want 
>> anything in docroot that shouldn't be made live.
> 
> git-archive generates an archive file *without* the .git directory. From 
> git-archive(1):
> 
>   git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)
>               Create a tar archive that contains the contents of the latest
>               commit on the current branch, and extracts it in 
> /var/tmp/junk
>               directory.
> 
>   git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip > 
> git-1.4.0.tar.gz
>               Create a compressed tarball for v1.4.0 release.
> 
>   git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip 
>  >git-1.4.0.tar.gz
>               Create a compressed tarball for v1.4.0 release, but without a
>               global extended pax header.
> 
>   git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > 
> git-1.4.0-docs.zip
>               Put everything in the current head's Documentation/ directory
>               into git-1.4.0-docs.zip, with the prefix git-docs/.
> 
> IMHO, git export is probably a better name for the command. git-archive 
> sounds like backup everything associated with git.
> 
> __Luke
> -

OK I don't think you read my response closely.  I wasn't going to 
respond except I see Johannes missed the point too.

I completely understand that git archive will not inlcude the .git dir. 
What you missed in my response is the case where someone tars up a 
directory above the .git directory. Not all of the content under doc 
root is in a git archive.

Re: I don't want the .git directory next to my code.

[Sam Vilain]

Mike wrote:
> Thanks but this isn't sufficient. If we have one directory of our web 
> root in a git repository, say docroot/php, and we tar up docroot, it 
> will include php/.git.  We don't want that.  We would have to go out of 
> our way to avoid the .git directory.  The point is, we don't want 
> anything in docroot that shouldn't be made live.

It sounds like you want a tool more like Capistrano, which can use git,
rather than just pushing files around with git.

Sam.

Re: I don't want the .git directory next to my code.

[Daniel Barkalow]

On Tue, 15 Jan 2008, Mike wrote:

> I'm learning git and I'm really annoyed that the .git directory lives in the
> same directory as my code.  I don't want it there for three reasons:
> 
> 1. My code lives on a development web server docroot, and I don't want the
> .git repository to end up getting published to the live site by accident. (I
> would imagine this would be a common need.)
> 
> 2. If I tar/gz my code and deliver it to a client, I don't want the .git dir
> slipping into the tarball, allowing my client to be able to peruse the history
> of what we did and when.

Generate your tarballs with "git archive", which will also make sure that 
you don't accidentally include anything else that's not committed. 
Likewise for sending to the live site, probably.

> 3. The .git respository will get big, especially with binary files in it, and
> I want it someplace with a lot of disk space. And I don't want it to get
> tarred up when we migrate the site to a different server. (And tar isn't aware
> of hard links is it? wonderful.)

You'll probably want to keep your history, which is what's in .git, when 
you migrate to a different server; that's kind of the point of using 
version control...

> How do I make the repository dir live somewhere else, the hell away from my
> code? Thanks

export GIT_DIR=/somewhere-else.git

Note that this only really works if you've only got one repository; 
there's no good way to have the repository information outside of the 
working directory and still have which repository you're using depend on 
which directory you're working in.

	-Daniel
*This .sig left intentionally blank*

Re: I don't want the .git directory next to my code.

[Mike]

Daniel Barkalow wrote:
 > On Tue, 15 Jan 2008, Mike wrote:
 >
 >
 > Generate your tarballs with "git archive", which will also make sure 
that
 > you don't accidentally include anything else that's not committed.
 > Likewise for sending to the live site, probably.

Thanks please see my response to David about why this isn't good.

 >
 > You'll probably want to keep your history, which is what's in .git, when
 > you migrate to a different server; that's kind of the point of using
 > version control...

The git repositories should be on the development server, but should 
*never* be on the live server.  Anywhere, ever.

 > export GIT_DIR=/somewhere-else.git
 >
 > Note that this only really works if you've only got one repository;
 > there's no good way to have the repository information outside of the
 > working directory and still have which repository you're using depend on
 > which directory you're working in.
 >

Thanks. Damn. We do have several repositories, (several sites).  I'll 
try Dan's soft link suggestion.

thanks
m

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Tue, 15 Jan 2008, Mike wrote:

> Daniel Barkalow wrote:
> > On Tue, 15 Jan 2008, Mike wrote:
> >
> > Generate your tarballs with "git archive", which will also make sure 
> > that you don't accidentally include anything else that's not 
> > committed. Likewise for sending to the live site, probably.
> 
> Thanks please see my response to David about why this isn't good.

See Luke Lu's answer to your response about why you're wrong.  It's even 
in the man page of git-archive.

Hth,
Dscho

Re: I don't want the .git directory next to my code.

[Bert Wesarg]

On Jan 16, 2008 5:13 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 15 Jan 2008, Mike wrote:
>
> > How do I make the repository dir live somewhere else, the hell away from my
> > code? Thanks
>
> export GIT_DIR=/somewhere-else.git
>
> Note that this only really works if you've only got one repository;
> there's no good way to have the repository information outside of the
> working directory and still have which repository you're using depend on
> which directory you're working in.
This project may solve this problem:

http://swapoff.org/OnDir

Bert

>
>         -Daniel

Re: I don't want the .git directory next to my code.

[Wayne Davison]

On Tue, Jan 15, 2008 at 11:13:58PM -0500, Daniel Barkalow wrote:
> export GIT_DIR=/somewhere-else.git
> 
> Note that this only really works if you've only got one repository; 
> there's no good way to have the repository information outside of the 
> working directory and still have which repository you're using depend on 
> which directory you're working in.

If you use zsh as your shell, put this chpwd function in .zprofile or
.zshrc:

chpwd() {
    local gitbasedir=/var/local/git
    local subdir=$gitbasedir$PWD
    while [[ ! -d $subdir ]]; do
	subdir=${subdir:h}
    done
    if [[ -d $subdir/.git ]]; then
	export GIT_DIR=$subdir/.git
	export GIT_WORK_TREE=${subdir/$gitbasedir/}
    else
	unset GIT_DIR GIT_WORK_TREE
    fi
}

Then, for each /path/.git dir, move it to /var/local/git/path/.git
(creating any needed parent dirs).  On every change of directory in
the shell, the variables GIT_DIR and GIT_WORK_TREE will be either
updated or cleared.  If you ever move a work-tree dir, you'll need
to remember to move the .git dir in the /var/local/git hierarchy.

..wayne..

Re: I don't want the .git directory next to my code.

[Matthieu Moy]

Mike <fromlists@talkingspider.com> writes:

> I'm learning git and I'm really annoyed that the .git directory lives
> in the same directory as my code.  I don't want it there for three
> reasons:

The idea was discussed here, mostly under the name "gitlink". I'd like
it for another reason :

* Have my tree on a fast, unrelialbe local disk, and have my .git on a
  slower, but safe and backed-up NFS partition.

But up to now, AFAIK, no one (including myself ;-) ) stepped-in to
implement it.

-- 
Matthieu

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Wed, 16 Jan 2008, Matthieu Moy wrote:

> Mike <fromlists@talkingspider.com> writes:
> 
> > I'm learning git and I'm really annoyed that the .git directory lives 
> > in the same directory as my code.  I don't want it there for three 
> > reasons:
> 
> The idea was discussed here, mostly under the name "gitlink".

It goes by "git worktree"; has nothing to do with gitlink (which has 
something to do with submodules).

> But up to now, AFAIK, no one (including myself ;-) ) stepped-in to 
> implement it.

It has been implemented, and it works.

Ciao,
Dscho

Re: I don't want the .git directory next to my code.

[Bill Lear]

On Wednesday, January 16, 2008 at 10:36:34 (+0000) Johannes Schindelin writes:
>Hi,
>
>On Wed, 16 Jan 2008, Matthieu Moy wrote:
>
>> Mike <fromlists@talkingspider.com> writes:
>> 
>> > I'm learning git and I'm really annoyed that the .git directory lives 
>> > in the same directory as my code.  I don't want it there for three 
>> > reasons:
>> 
>> The idea was discussed here, mostly under the name "gitlink".
>
>It goes by "git worktree"; has nothing to do with gitlink (which has 
>something to do with submodules).

I think you mean to say there is a variable 'worktree' variable
available via the config variable 'core.worktree' or environment
variable GIT_WORK_TREE, or command-line option --work-tree that should
do the trick (no 'git worktree' command exists as far as I can see):

% man git-config
[...]
       core.worktree
           Set the path to the working tree. The value will not be used in
           combination with repositories found automatically in a .git
           directory (i.e. $GIT_DIR is not set). This can be overriden by the
           GIT_WORK_TREE environment variable and the --work-tree command line
           option.
[...]

% man git
[...]
       --work-tree=<path>
           Set the path to the working tree. The value will not be used in
           combination with repositories found automatically in a .git
           directory (i.e. $GIT_DIR is not set). This can also be controlled
           by setting the GIT_WORK_TREE environment variable and the
           core.worktree configuration variable.
[...]


Bill

Re: I don't want the .git directory next to my code.

[Matthieu Moy]

Bill Lear <rael@zopyra.com> writes:

> On Wednesday, January 16, 2008 at 10:36:34 (+0000) Johannes Schindelin writes:
>>Hi,
>>
>>On Wed, 16 Jan 2008, Matthieu Moy wrote:
>>
>>> Mike <fromlists@talkingspider.com> writes:
>>> 
>>> > I'm learning git and I'm really annoyed that the .git directory lives 
>>> > in the same directory as my code.  I don't want it there for three 
>>> > reasons:
>>> 
>>> The idea was discussed here, mostly under the name "gitlink".
>>
>>It goes by "git worktree"; has nothing to do with gitlink (which has 
>>something to do with submodules).
>
> I think you mean to say there is a variable 'worktree' variable
> available via the config variable 'core.worktree' or environment
> variable GIT_WORK_TREE, or command-line option --work-tree that should
> do the trick (no 'git worktree' command exists as far as I can see):

Yes, so you can use

$ git --work-tree . --git-dir /some/other/place <some-command>

But it's far from the user-friendlyness of a real lightweight
checkout: you need to provide the --work-tree and --git-dir options
each time you run git. And making an alias or using the environment
variables are not really an option if you have more than one
repository or working tree to deal with.

-- 
Matthieu

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Wed, 16 Jan 2008, Matthieu Moy wrote:

> Bill Lear <rael@zopyra.com> writes:
> 
> > On Wednesday, January 16, 2008 at 10:36:34 (+0000) Johannes Schindelin writes:
> >>Hi,
> >>
> >>On Wed, 16 Jan 2008, Matthieu Moy wrote:
> >>
> >>> Mike <fromlists@talkingspider.com> writes:
> >>> 
> >>> > I'm learning git and I'm really annoyed that the .git directory lives 
> >>> > in the same directory as my code.  I don't want it there for three 
> >>> > reasons:
> >>> 
> >>> The idea was discussed here, mostly under the name "gitlink".
> >>
> >>It goes by "git worktree"; has nothing to do with gitlink (which has 
> >>something to do with submodules).
> >
> > I think you mean to say there is a variable 'worktree' variable
> > available via the config variable 'core.worktree' or environment
> > variable GIT_WORK_TREE, or command-line option --work-tree that should
> > do the trick (no 'git worktree' command exists as far as I can see):
> 
> Yes, so you can use
> 
> $ git --work-tree . --git-dir /some/other/place <some-command>
> 
> But it's far from the user-friendlyness of a real lightweight checkout: 
> you need to provide the --work-tree and --git-dir options each time you 
> run git. And making an alias or using the environment variables are not 
> really an option if you have more than one repository or working tree to 
> deal with.

Well, the OP said he did not want _any_ file in the worktree.  So there's 
no way around specifying by hand everytime where the git directory should 
be.

I'm not saying I find the OP's restrictions sensible, but that's what he 
said.

Ciao,
Dscho

Re: I don't want the .git directory next to my code.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> Yes, so you can use
>> 
>> $ git --work-tree . --git-dir /some/other/place <some-command>
>> 
>> But it's far from the user-friendlyness of a real lightweight checkout: 
>> you need to provide the --work-tree and --git-dir options each time you 
>> run git. And making an alias or using the environment variables are not 
>> really an option if you have more than one repository or working tree to 
>> deal with.
>
> Well, the OP said he did not want _any_ file in the worktree.  So there's 
> no way around specifying by hand everytime where the git directory should 
> be.

Export GIT_DIR and GIT_WORKTREE and you are free to go, right?

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Wed, 16 Jan 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> Yes, so you can use
> >> 
> >> $ git --work-tree . --git-dir /some/other/place <some-command>
> >> 
> >> But it's far from the user-friendlyness of a real lightweight 
> >> checkout: you need to provide the --work-tree and --git-dir options 
> >> each time you run git. And making an alias or using the environment 
> >> variables are not really an option if you have more than one 
> >> repository or working tree to deal with.
> >
> > Well, the OP said he did not want _any_ file in the worktree.  So 
> > there's no way around specifying by hand everytime where the git 
> > directory should be.
> 
> Export GIT_DIR and GIT_WORKTREE and you are free to go, right?

Yep.

Ciao,
Dscho

Re: I don't want the .git directory next to my code.

[Matthieu Moy]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Wed, 16 Jan 2008, Matthieu Moy wrote:
>
>> Mike <fromlists@talkingspider.com> writes:
>> 
>> > I'm learning git and I'm really annoyed that the .git directory lives 
>> > in the same directory as my code.  I don't want it there for three 
>> > reasons:
>> 
>> The idea was discussed here, mostly under the name "gitlink".
>
> It goes by "git worktree";

Any pointer to some doc? My git doesn't have a "worktree" command.

> has nothing to do with gitlink (which has something to do with
> submodules).

We may not be talking about the same gitlink then.

The one I'm refering to is "Lightweight Checkout
Otherwise known as the .gitlink idea." on
http://git.or.cz/gitwiki/SoC2007Ideas for example.

-- 
Matthieu

Re: I don't want the .git directory next to my code.

[Johannes Schindelin]

Hi,

On Wed, 16 Jan 2008, Matthieu Moy wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Wed, 16 Jan 2008, Matthieu Moy wrote:
> >
> >> Mike <fromlists@talkingspider.com> writes:
> >> 
> >> > I'm learning git and I'm really annoyed that the .git directory 
> >> > lives in the same directory as my code.  I don't want it there for 
> >> > three reasons:
> >> 
> >> The idea was discussed here, mostly under the name "gitlink".
> >
> > It goes by "git worktree";
> 
> Any pointer to some doc? My git doesn't have a "worktree" command.

I was not talking about a command.  I prepended "git" only to stress that 
this worktree is not any worktree, but integrated into git.  I believe 
Bill has already given all necessary pointers.

> > has nothing to do with gitlink (which has something to do with 
> > submodules).
> 
> We may not be talking about the same gitlink then.

Indeed.

Ciao,
Dscho

Re: I don't want the .git directory next to my code.

[Jakub Narebski]

Mike <fromlists@talkingspider.com> writes:

> I'm learning git and I'm really annoyed that the .git directory lives
> in the same directory as my code.  I don't want it there for three
> reasons:
> 
> 1. My code lives on a development web server docroot, and I don't want
> the .git repository to end up getting published to the live site by
> accident. (I would imagine this would be a common need.)

Use git-archive (or, in older releases, git-tar-tree) and perhaps
post-update / post-recieve hook to publish latest version.

I think best layout would be: 
 (1) your private copy (clone) of repository, with working directory
 (2) bare (without working directory) publishing repository,
     with post-update hook
 (3) published last version of your files

You can check 'todo' branch of git.git repository for scripts which
Junio uses to automatically update git HTML documentation at
kernel.org
 
> 2. If I tar/gz my code and deliver it to a client, I don't want the
> .git dir slipping into the tarball, allowing my client to be able to
> peruse the history of what we did and when.

Use git-archive / git-tar-tree to tar.gz or zip code to send to client.
This has the advantage of not packing generated code, backup files,
etc., not only .git. Besides there is --exclude option to tar ;-)
 
(For RPM based distributions git-archive is usually in git-core;
I don't know what package you have to install on Debian based distro).

> 3. The .git respository will get big, especially with binary files in
> it, and I want it someplace with a lot of disk space. And I don't want
> it to get tarred up when we migrate the site to a different
> server. (And tar isn't aware of hard links is it? wonderful.)
> 
> How do I make the repository dir live somewhere else, the hell away
> from my code? Thanks

If you are inside repo, configuration variable core.worktree,
environmental variable GIT_WORK_DIR, or '--work-tree' command line
option (git --work-tree=/path/to/working/dir <cmd>) can be used to
point to working tree.

If you are in working area, environmental variable GIT_DIR, or
'--git-dir' command line option can be used to point to the
repository. You can also symlink .git in working directory.
There was an idea of '.gitlink' file, similar to CVS/Root file
in CVS, or core.gitdir configuration variable which points to
base GIT_DIR in unionfs / shadow like way, but neither got
implemented. You are welcome to it... of course after release :-)

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: I don't want the .git directory next to my code.

[Brian Downing]

On Wed, Jan 16, 2008 at 05:13:47AM -0800, Jakub Narebski wrote:
> > 2. If I tar/gz my code and deliver it to a client, I don't want the
> > .git dir slipping into the tarball, allowing my client to be able to
> > peruse the history of what we did and when.
> 
> Use git-archive / git-tar-tree to tar.gz or zip code to send to client.
> This has the advantage of not packing generated code, backup files,
> etc., not only .git. Besides there is --exclude option to tar ;-)

I realize that this is not directly what's being talked about here, but
one advantage to using "full Git" for deployment rather than something
like "git archive" is that Git has already implemented an
optimized-to-within-an-inch-of-its-life incremental filesystem updater -
namely, "git checkout-index".  If you always deploy with "git archive",
it could take a very long time to update a large web site even if only a
tiny change has taken place.

Yes, you could use rsync or some other tool, but Git already has the
tools available, so why not take advantage of them?

(Now, maybe some custom scripting to call plumbing like "git
checkout-index" would be more appropriate that using a "normal" working
directory, but I think the advantages of using Git's optimized WD update
tools here should be obvious for large sites...)

-bcd

Re: I don't want the .git directory next to my code.

[Randal L. Schwartz]

>>>>> "Brian" == Brian Downing <bdowning@lavos.net> writes:

Brian> Yes, you could use rsync or some other tool, but Git already has the
Brian> tools available, so why not take advantage of them?

It's very likely that rsync will be faster/better/cheaper/more-flexible
than git.  "Yes, you could use git, but rsync already does the job
better, so why not take advantage of it?"  Back at ya.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: I don't want the .git directory next to my code.

[Martin Langhoff]

On Jan 17, 2008 2:35 PM, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Brian" == Brian Downing <bdowning@lavos.net> writes:
>
> Brian> Yes, you could use rsync or some other tool, but Git already has the
> Brian> tools available, so why not take advantage of them?
>
> It's very likely that rsync will be faster/better/cheaper/more-flexible
> than git.  "Yes, you could use git, but rsync already does the job
> better, so why not take advantage of it?"  Back at ya.

We do web development, and use various deployment tools, usually git,
git+rsync or git + debian packages.

I find the discussion of git-archive as a deployment tool a bit
worrying - remember that untarring a newer version of the tarball on
top of the old version does not remove old files. In web applications
(and I think the OP is talking about web development) often security
bugs come from sloppy inclusion of files (such as sample AdoDB code).
If you deploy your "security fix" by unpacking a tarball, chances are
you'll wake up to a p0wned server.

cheers,


martin

Re: I don't want the .git directory next to my code.

[Randal L. Schwartz]

>>>>> "Martin" == Martin Langhoff <martin.langhoff@gmail.com> writes:

Martin> I find the discussion of git-archive as a deployment tool a bit
Martin> worrying - remember that untarring a newer version of the tarball on
Martin> top of the old version does not remove old files.

"rsync --exclude [dangerous things} --delete --delete-excluded" is your friend.

They added --delete--excluded at my request, by the way.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!