1

I'm considering moving my Subversion website repositories to Git, but I'm not sure how to structure my new repositories. In svn, I structured my repos like this:

  • branches
  • tags
  • trunk
    • supportdocs
    • webdocs

Under my trunk I have a directory for any support documents (word docs, photoshop files, etc.) and a webdocs directory that houses the actual website.

I would then checkout only the webdocs directory for use in Eclipse. However, with git, if I make the existing trunk the root of my repo, a clone grabs the whole thing and it makes it difficult to work with just my webdocs files.

Should I create two repos, one for support docs and one for web files? Or is there a way that I can keep them both in the master branch, but only work with a subfolder?

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
user854567
  • 11
  • 1
  • Could you clarify the issue? "it makes it difficult to work with just my webdocs files" -- what would be an example of the difficulty you're dealing with? It would appear that supportdocs is just a folder and as long as you don't edit anything in it, it wouldn't even appear in a git status or commit. – Fernando Correia Jul 20 '11 at 20:28

4 Answers4

0

You would need two separate repos.

git does not have the ability to checkout separate subfolders of the repo and only work on those

edit: It looks like there is some ability with sparse checkouts, but your working directory still contains the path leading up to that subdirectory.

Community
  • 1
  • 1
Andy
  • 44,610
  • 13
  • 70
  • 69
0

You can accomplish this by using sparse checkouts. But note that the clone will still contain the other directories, you just won't have them in your working directory.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
0

Could I suggest that it would be worth reading a bit more around 'git' and the DVCS paradigm because it is so different to the 19th century version control processes that surround all the centralised control processes.

It takes a while to 'get it' to the level sufficient to see how best to re-partition the old store and create new repos, usually with more separate repos than before.

Philip Oakley
  • 13,333
  • 9
  • 48
  • 71
  • Your probably right Philip. I've been working with SVN for a number of years and haven't quite got my head around the Git paradigm yet. I've read some articles on sparse checkouts and it doesn't seem like there is still some issues with doing it this way. It might be just more work than creating two separate repos. – user854567 Jul 22 '11 at 15:08
  • Huh, what are 19th century version control processes? I thought the term didn't even exist then (at least not in the computer sence). Do you have more information? – Paŭlo Ebermann Aug 23 '11 at 21:44
  • 1
    @Paulo; When the Titanic was being built (1909) at Harland and Wolf they needed to source control their drawings. The established practice was based on the realisation that they needed to defend the (almost irreplacable) Kaolin & Linen master drawings from damage and mistakes, so all the change request, marked up copies and other source control methods were used. This continued even when computers could duplicate easily, and the issue is now verification (SHA1 hash..), not protection. Git works because it addresses today's issues. Unfortunately the rest of the world is still ignorant..(of git) – Philip Oakley Aug 24 '11 at 11:34
0

You could have separate (non-related) branches with the supporting documents, if these don't really relate to any concrete version of your main documents.

(This is in effect similar to having two separate repositories, but you have everything together. With git-new-workdir you can create a new working directory for the same repository.)

As an example, I'm using something similar in my jsch-documentation repository on Github. I have tree unrelated trees of commits (and branches):

  • the JSch-related ones: master, better-examples, directtcp-ip-bug, tarballs, hostbased-auth, swingworker-example
  • The JZlib-related ones: jzlib-tarballs, jzlib-source
  • The web pages (mostly autogenerated javadocs): gh-pages

In fact, these could have been three different repositories (apart from the fact that github generates the web sites from the gh-pages branch).

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210