Re: I don't want the .git directory next to my code.
- From
Jeff King <peff@peff.net>
- Date
- Jan 17, 2008, 15:17 UTC
- Message-ID
- <20080117151725.GC2816@coredump.intra.peff.net>
- In-Reply-To
- <478EEAC4.2010006@talkingspider.com>
On Thu, Jan 17, 2008 at 12:42:28AM -0500, Mike wrote:
Show 7 quoted lines
> 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