0

Im trying to change my deployment workflow from sending files over FTP to git deployment. I'm following this post.

git --work-tree=/var/www/domain.com --git-dir=/var/repo/site.git checkout -f

The problem is that command above copies content of entire repo to another directory. I need to copy only contents of dist directory. How can I achieve this?

sajran
  • 317
  • 4
  • 15

2 Answers2

1

As you know a bare repository does not have working directory.

The easiest way to do it is to clone the repository to a new location and copy the content of the folder.

# clone the repo
git clone <url>

# Grab the desired folder from the desired branch and that it.

Another option is to clone the repo and then split out the desired folder

subtree split

git subtree git-subtree - Merge subtrees together or split repository into subtrees

git subtree split -P <name-of-folder> -b <name-of-new-branch>

enter image description here

CodeWizard
  • 128,036
  • 21
  • 144
  • 167
  • I was hoping for more straightforward way, why something so simple isn't possible? – sajran Apr 24 '16 at 14:47
  • You can still do it but the problem is that bare repo doesn't have any content (working directory). Is only storing all the content in the pack files. – CodeWizard Apr 24 '16 at 14:48
  • Yeah, but if it's possible to copy entire `dist` directory (I managed to do this) then why it's not possible to copy only its content? I'm sorry I'm insisting so much but I don't understand git very well and it's just weird to me. – sajran Apr 24 '16 at 14:53
  • On the bare server you don't have any content. You can check it out as you did by supplying the desired folders. In order to "split" a certain folder you need to use the split command. Updating the answer accordinally, wait few minutes – CodeWizard Apr 24 '16 at 15:03
  • Read this answer i gave a while ago on how to do it. Feel free to vote for it if you like it :-) http://stackoverflow.com/questions/36184532/make-new-git-branch-containing-full-history-of-only-some-files/36185063#36185063 – CodeWizard Apr 24 '16 at 15:07
  • I think I will stick to the first option since I understand it better. Thank you for your patience! – sajran Apr 24 '16 at 15:19
1

that command above copies content of entire repo to another directory

In git terminology, what it's doing is checking out a commit. To check out just part of a commit you have to tell it to read out just some of the committed tree.

As a side note, git's not built to be a deployment server. That said, it's simple and flexible enough that using it as you want here is fairly popular and works pretty well.

Git maintains an index file that relates what's in the work tree to what's in the repo. So if you want to use git to manage what's in an arbitrary worktree, you have to keep an index file for that worktree.

(
  # git ordinarily finds these for itself, but we're not using default behavior:
  export GIT_DIR=/var/repo/site.git
  export GIT_INDEX_FILE=$GIT_DIR/domain.com.index
  export GIT_WORK_TREE=/var/www/domain.com

  git read-tree -um `git write-tree` HEAD:dist     # or master:dist, or any tree reference
)

The git write-tree gets you the tree for whatever content is currently listed in the index (an empty or nonexistent file works just fine as a "nothing's here yet" index). git read-tree -um with two trees is what underlies checkout, it doesn't care about refs at all, not even HEAD; it's concerned solely with trees and the index.

jthill
  • 55,082
  • 5
  • 77
  • 137
  • I ran your code and it worked like charm but since I messed something up with repo earlier I removed this directory and when I run `git init --bare` I get: `fatal: GIT_WORK_TREE (or --work-tree=) not allowed without specifying GIT_DIR (or --git-dir=)`. Can you help me? – sajran Apr 24 '16 at 18:00
  • Nevermind, I rebooted machine and everything is working but I have another question. I thought git will be good for deployment since it's recommended as simple and convenient across the internet. But it looks like in my case it's not simple and I don't like using things I don't understand so maybe you could recommend tool that is _actually_ simple and will work for _not very experienced_ person like me? – sajran Apr 24 '16 at 18:21
  • No, as you've seen it does work well. It's popular for good reason. You've got nothing to lose by sticking with this, for simple deployment tasks it's about as simple as possible already. – jthill Apr 24 '16 at 19:18
  • Ok, one more question. In your code you are using `export` and AFAIK it has something to do with environmental variables which are global. Will it work with more than one repo on the same server? Of course it means also different deployment path for every repo. – sajran Apr 24 '16 at 19:28
  • That's what the parens are for, stuff inside parens runs in a subshell with its own environment. You don't need multiple repos, one index file per worktree and you're good to go. – jthill Apr 24 '16 at 19:54
  • I don't understand, same repo but different index files? I meant completely unrelated, different projects. Since it's post-receive hook how could it choose right paths to index file and prod dir? – sajran Apr 24 '16 at 20:09
  • Ah. Okay, yes, I was thinking you had one of those branch-per-site histories. You can associate worktree and index file with refname in the config, `git config branch.xyz.x-domain domain.com` and then look that up in the post-receive, or you could do it in the committed history itself, or you could just use the domain name as the branch name and incorporate that as the deployment path and index file name uniquifier. It's all very concrete, "does it work?" is the criterion here. – jthill Apr 24 '16 at 20:16
  • I'm sorry I'm such pain in the ass but could you elaborate? It would be great if I could push all my projects to `git@project.server` and server would take care about everything else. – sajran Apr 24 '16 at 20:37
  • I'm afraid I wouldn't even know where to start with "everything else". For the basics, you're already there, and your one-repo-per does have the keep-it-simple advantage. Git and the shell are very fundamental tools. To learn more about the shell you could do lots worse than start with [the standard](http://pubs.opengroup.org/onlinepubs/9699919799/), it's a usable least-common-denominator. (edit: you want the shell and utilities section) – jthill Apr 24 '16 at 21:03
  • Thank you so much for all your help! – sajran Apr 24 '16 at 21:07