Can I ask what the policy for workflow will be on this? In SVN we all have a copy of the repository, make changes and commit them back directly. I'm told that the "right" way to do this in git is for us each to fork the master repository, set this up as a named upstream branch, before working pull from upstream, do our work, commit back to our repository, push this to our repository, and then issue a pull request back to the main TEI-C repository for review before it gets added. Or, if we have rights to do so, could we just push directly back into the TEI-C repository. (i.e. I find the latter so much easier than the former, though understand why the former might be technically better if I was doing a huge set of changes. However, usually we aren't all touching the same set of files at the same times if my svn notifications are to be believed.) -James On 29/07/15 17:23, Hugh Cayless wrote:
All,
I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like.
Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard.
Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future.
GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford