Symphony.

In managing Symphony via git and submodules do people generally keep the link to the official symphony remote repo or remove this once they setup their own private remote repository?

I always add an extra remote for my private repo but when staging and committing changes I'm always warned about updates to submodules which are modified and ahead of the remote master branch:

#   modified:   extensions/debugdevkit (modified content)
#   modified:   extensions/export_ensemble (modified content)
#   modified:   extensions/jit_image_manipulation (modified content)
#   modified:   extensions/maintenance_mode (modified content)
#   modified:   extensions/markdown (modified content)
#   modified:   extensions/profiledevkit (modified content)
#   modified:   extensions/selectbox_link_field (modified content)

This is understandable because I've updated them since installing but is it general practice to ignore these or remove the remote to the public Symphony repo (which removes the above notifications)?

I have a branch just for keeping track of official Symphony, and a branch specific to the project which has my added extensions submodules at particular commits in it.

Unless there's a particular problem with one, I don't update included-by-default extensions until I update Symphony itself, choosing instead to remain with whatever versions of extensions the particular release of Symphony was released with. But if you want to keep your included-extension updates, you could do:

git checkout -b project-name
git add extensions
git commit -m 'Update extensions from what Symphony was tracking to what I chose.'

Then when you want to update Symphony in the future, assuming master is a branch that tracks official Symphony's master branch and that origin is a remote that refers to the official Symphony Github repository, you could do:

git checkout master
git pull origin master
git checkout project-name
git merge master
git submodule update --init --recursive

See "Welterweight: using a complete site repository" at Getting Git for Symphony Development . I also like to keep the workspace as a submodule my the Symphony repo's own-project branch.

Thanks David, that's extremely helpful. I found a few threads and articles on setting up a git workflow with Symphony but there's always a few grey spots. That helps to clear it up and provides a nice way to keep a link to the original Symphony repository whilst maintaining your own private repo.

I'm only just trying out Symphony 2.3.3 so whilst pulling from remote I updated the submodules at the same time as recommended and that's why the modification messages came about.

The Welterweight approach sounds ideal so I'll look to roll with that one. Thanks for the tips. Much appreciated.

I've had the chance to revisit git workflow with Symphony and have followed @designermonkey's excellent article on the subject. I've setup 3 branches:

1) master (main branch)
2) develop (for all development work)
3) symphony (for keeping track of the symphony-2 repo and merging in as required)

I switch to 'develop' and then install my desired extensions as git submodules. I also run git submodule update --init --recursive at the same time as instructed in the installation docs. I then stage the changes and commit:

git add .
git commit -m "Updated default extensions & installed additional"

However I still seem to be getting notification that the submodules have been "changed but unstaged". In the terminal I see this:

→ gs
## develop
 M extensions/debugdevkit
 M extensions/export_ensemble
 M extensions/jit_image_manipulation
 M extensions/maintenance_mode
 M extensions/markdown
 M extensions/profiledevkit
 M extensions/selectbox_link_field
 M extensions/xmlimporter

And the diff file shows only the following change for each submodule:

Subproject commit 3e73f0e145f6f4b9e05a9063fad2aaa0a41dd5f2  
Subproject commit 3e73f0e145f6f4b9e05a9063fad2aaa0a41dd5f2-dirty

Should this still be displaying like this? I've kept branches separate, I've setup a remote for my repo and a remote for Symphony but I still get this notification which is a little annoying.

Any ideas what I've left out or am doing wrong in terms of being able to see a clean working directory?

That is strange that you are still seeing modified submodules for each extension. I would expect to see that if I have updated extensions but have not committed the modified submodule references yet. I would also expect to see that if I switched to the master branch after modifying the submodules.

The only other thing that I can think of is that the permissions on the files might be different than what each extension repository is expecting. So, the difference would not be seen in the content of the files but in the permissions.

Maybe someone else has some other ideas.

Each time you change branches, you need to run git submodule update --init to ensure that the branch's extensions are brought back in line with the branch.

It's a downside to submodules. Luckily Git Tower does this automatically for you, but on the command line it doesn't.

When you change branch, it checks the commit hash listed in the current branch, but doesn't physically run any changes, as submodules are separate repositories, so branch changes need the submodules re-aligning to the stored commit hash.

The only other thing that I can think of is that the permissions on the files might be different than what each extension repository is expecting. So, the difference would not be seen in the content of the files but in the permissions.

This was my first thought as well. To test this theory, cd into an extension directory and tell Git to ignore permissions:

cd extensions/debugdevkit

git config core.filemode false

If that extension no longer shows up as modified (dirty), then that was the issue.

Aha! It seems like it is the file permissions causing the problem. I followed your instructions @briandrum and yes, that extension no longer shows up as modified (dirty) in the list whereas the others still do. Can I run:

git config core.filemode false

On the extensions directory to have them ignore them all rather than doing that individually?

Also out of interest, what should the file permissions be on the extensions directory and and it's contents?

It's a downside to submodules. Luckily Git Tower does this automatically for you, but on the command line it doesn't.

So if I switch branches via Tower it automatically runs the submodule update? That's useful to know. I have Git Tower but usually do the majority via the command line.

Apparently performing the same steps on the other extensions have no effect. (???)

Also, for some strange reason my workspace directory isn't being included in my repo at all. It's in the project root, there's nothing in .gitignore to tell it not to add it, and I run:

git add workspace

or

git add .

No errors are thrown but workspace isn't added to the repo.

Any ideas?

Check your gitignore file. We ignore the workspace by default.

@ily out of curiosity does git add workspace -f help?

I've nuked things and re-installed 3 or 4 times now and unfortunately I'm still no further forward. Here's a snapshot showing how it looks including filesystem, the files in the repo, and the gitignore file.

Workspace

Unfortunately git add workspace -f doesn't make any difference.

I definitely removed /workspace from the gitignore file. even before making my first commit. I don't understand how it can't be adding a directory which I'm telling it to with nothing saying not to(?)

Submodules

Exactly the same problem. I run git config core.filemode false but it makes no difference. On the latest install I didn't even run git submodule update --init --recursive to tell it to clone the submodules.

Screenshot

I've followed along with @designermonkey's process exactly. I've understood each bit along the way but I have these issues remaining.

Other Notes

Following along with that guide I also notice that if I only fetch the most recent commit from the symphony repository I get an error when pushing to remote. i.e. this:

git fetch --depth 1 symphonycms

Results in:

error: Could not read 67964f9c56af3eb61ef0b0b77b7fb02400467349  
fatal: Failed to traverse parents of commit 

And several other similar errors. I found this thread which highlights the problem. When I pull with a full history I can push without error. Any ideas on this one?

Also git branch --set-upstream is deprecated so it needs to be changed to --track or equivalent. i.e.:

git branch --set-upstream master mywebsite/master

to

git branch --track master mywebsite/master

With regards to the issues with Submodules and non-tracking of the Workspace directory I could really do with getting these ironed out.

Take a look here for some further advice:

http://stackoverflow.com/questions/4873980/git-tells-me-my-subproject-is-dirty-what-does-this-mean

Thanks John. That's actually very useful to know that you can ignore dirty submodules using:

git status --ignore-submodules=dirty

Or by adding:

ignore = dirty

to your .gitmodules file. I'll probably be using that for the default extensions from now on. :)

I've also managed to resolve the above issues.

Workspace

Annoyingly this turned out to be something quite simple in that when you install with a blank slate your workspace is empty. Git doesn't recognise empty directories (or directories at all) so you have to place a file in them for them to be tracked in the repository. Bah!

Submodules

Prior to John's tip I was able to try again with a clean install and this time cd into each extension and then run:

git config core.filemode false

As @briandrum recommended above. This silences the false warnings of dirty submodules and results in a clean working repository once again. The only slightly annoying thing was that I had to cd into each extension directory one at a time and run that command. Out of interest for another time does anyone know how I can set that recursively to apply to ALL extension directories in one fell swoop? I'll definitely make a note of that next time.

Thanks for all the tips @designermonkey. Your article is a big help in setting up a nice git workflow with a solid branching model. It should hopefully make for pain-free upgrades to the core and extensions in the future.

@designermonkey. One other thing. You mentioned in your notes "install Symphony on our dev server...". But if you export your local database and push all the files on the development server is installation still necessary via the installer? If you're running with the multiple manifest setup as described could you not just add the connection details manually in the config file, import the database, deploy the files and have things up and running on the remote dev server?

But if you export your local database and push all the files on the development server is installation still necessary via the installer

No it's not necessary to run the installer; I usually dump the database & upload the files; works like a charm. Obviously make sure you take care of any config alterations that you would want to do.

@ijy - To do the git config command to all submodules in one command I believe you can just run: -

git submodule foreach --recursive git config core.filemode false

Also, if you need to 'shim' open an empty directory, a good tip is just put an empty .gitignore file in there and add that to your git index - better than having a doorstop.txt file or whatever and will mean your empty directory is tracked.

Thanks for the confirmation. I just tested it out via deploy and dump and that seemed to work fine. I'm following along with John's recommendations of multiple manifests so I just need to setup the symlink on each environment and so far so good.

@firegoby Aha! Thanks. I wasn't quite sure on the syntax but I knew it had to be possible. :) I'll give that a try.

And yes, I ended up including a .gitignore file in each directory I needed to keep in the repo with just the following inside:

# Don't ignore this file
!.gitignore

It's always the simplest things...