0

In our project, we have a directory (let's just call it "/sw/") where we keep everything related to the project. Various scripts, templates, delivered files, git-repos, builds, etc are in subdirectories of /sw/.

This is an old project, and /sw/ have become quite a mess. A lot of it seems totally obsolete, and probably should be removed. It's hard to do this though, since there's always a small risk that it's actually used somewhere.

Things in Git repositories should remain, those are well documented and managed. However, there's a lot of subdirectories and files in /sw/ not under version control, and much of this seems like junk.

Edit to clarify: Any existing git repos under /sw/ would not be a part of the /sw/ repo. For example /sw/develop.git would never be added.

If we should do a cleanup of /sw/, we are considering two strategies for this:

1) Make a folder somewhere called "obsolete", and just move the (presumably) junk files there. We'd perhaps keep a textfile in that directory as a log of what has been moved, and why.

2) In /sw/, initialize a Git repository. Then, each time we do cleanup and something is removed, we would first add and commit it to the /sw/ repository, then remove the files, then commit that change. Then if we discover something should not have been removed, we can just revert that change.

Which one seems like the best/safest strategy? I sometimes hear "keep everything under version control". But is it just making things more complicated in this case? Or would it be a benefit?

Is there some other way than the two points listed above?

Martin
  • 97
  • 6
  • Second approach seems reasonable, just add the folders that are already git repositories to your `gitignore` so they aren't tracked twice and start cleaning stuff up. – Roman Aug 21 '14 at 11:13

1 Answers1

0

The second approach sounds good but having the git repos within a git repo sounds a bit indifferent. Instead you could maintian all of your junk in respective repositories and maintain it under /sw.

Something like this: Various scripts could go in scripts.git, templates in templates.git, delivered files in delivered_files.git,builds in builds.git.

This helps you to keep a check on size as you would not have to clone entire sw repository every time you clone to do some operation.

Mayur Nagekar
  • 813
  • 5
  • 13
  • "having the git repos within a git repo sounds a bit indifferent" I should clarify this - we don't intend to add any Git repo-subdirectories to the /sw/ repo. Everything that is already a Git repo we are already sure that we want to keep. "you could maintian all of your junk in respective repositories" That would defeat the purpose a bit. We would prefer to delete most of the directories themselves. – Martin Aug 21 '14 at 11:13
  • Do you mean that your existing git repos won't be a part of it ? – Mayur Nagekar Aug 21 '14 at 11:16
  • Any existing git repos would not be a part of the /sw/ repo. For example /sw/develop.git would never be added. – Martin Aug 21 '14 at 11:18
  • Then just add the others in one single git repo, call it as sw.git. – Mayur Nagekar Aug 21 '14 at 11:53