On May 20, 2017, at 8:03 PM, Quincey Morris < email@hidden> wrote:
On May 20, 2017, at 15:57 , Bryce Glover < email@hidden> wrote:
Hmm, that doesn’t exactly mesh with the mental model I tend to use for this kind of directory tree structure.
I don’t disagree with anything you said. I don’t really use “project” in a technical way. The enclosing folder is the “project folder”, so calling it the “project” is informal, …
Ah, all right. I usually just lean towards keeping the formalities somewhat more explicit for the sake of workflow, documentation, and increased ease of collaboration myself. …but in fact it *is* the project because it may contain multiple Xcode project files, and multiple repositories (at different levels or locations, of course).
Right, Git submodules could exist within your repository as copies of other repositories upon which the one you’re working with depends.
…
The important factor is that everything in the Xcode project is relative to the project file (i.e. package), and everything in the repository is relative to the .git subfolder. (Assuming there’s only one of each and they’re both at the top level.) …
Yup, gotta have everything ship-shape. Otherwise, things might start going awry… …That makes the project folder self-contained, hence moveable and duplicatable.
Modularity is always good.
… …The only thing you really need to do is to fix the .gitignore file before you commit anything, since Xcode’s standard one is inadequate.
How so, exactly?
It depends what you’re doing, but from time to time files appear that you know you don’t want to commit. You see them in the commit sheet, and they mean the commit sheet isn’t “clean” just after a commit. …
It’s probably a good thing I’m such a fan of `git status`, then, as that command’s output can be easier to parse than a diff, thus allowing one to catch on to these kinds of things earlier and take care of them before that happens. …In those cases, you might want to add specific items to .gitignore.
I usually add “xcuserdata/” to .gitignore, to prevent user-specific settings (e.g. breakpoints and non-shared schemes) to the repository, since they aren’t useful to anyone else. If you don’t do that, then any action that creates a new file inside xcuserdata introduces something untracked into the commit sheet, as above.
OTOH, if you’re working on a project alone, I guess it might be useful to have personal settings backed up in a remote repository.
It’s not really crucial, though. At worst, it commits a few extra small files to the repo.
OK, good to know.
Thanks for all your help, Bryce Glover |