Re: [tei-council] Test GLs repo on GitHub

I just tested the following, and everything worked: - cloned the repo - created a no-pantor branch and switched to it - made changes in that branch and committed them - switched back to the master branch - merged the no-pantor branch - pushed master to GitHub - deleted the no-pantor branch I did all this locally. Under what circumstances would it make sense to push a branch to the server so others can see and contribute to it? Cheers, Martin On 15-07-30 07:17 AM, Hugh Cayless wrote:

I've added a README to https://github.com/TEIC/Guidelines-TEST with some basic "getting started" advice. Feedback, additions, and corrections gratefully accepted.

We'll have to establish a workflow policy. Personally, I think that we should reserve the pull request approach for people outside the committers list. For big changes that we want reviewed before they are merged into the master branch I think we should just use branches. What I'd like to do is try to get people up to speed on using GitHub so that we're all in a position to comment and then we can establish a workflow. It sounds like James and I are in agreement about the basics.

On Thu, Jul 30, 2015 at 10:08 AM, James Cummings

...

wrote:

...

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

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived