On Thu, Jul 30, 2015 at 11:06 AM, James Cummings wrote: But if we (as council members) adopt the distributed system (ie you fix the bug you're assigned to in your copy, then send a pull request), there
is a chance not just for human review (which might be superfluous at that
point), but also for automated testing. If an error occurs, fix it, push
again and it will get tested automatically etc. I think this is useful. If we have a continuous integration environment set up (whether external
like Jenkins or in-built like whatever it was called), then wouldn't that
happen on any git push? Sure, it just would keep the repository "clean" until the error is fixed.
Raff Regardless of what process we adopt, anyone will still be able to send pull requests and that's a good thing. More tech-savvy users (such as
former members of the council, among others) could send a feature request
or a but *and* a patch at the same time, saving us time and focusing our
work on review and approval. That sounds idea and the combined form that Hugh suggests seems to make
most sense to me. While you're on council (or some list of approved
committers working on a particular thing) then you can push directly. For
large but discrete changes that are likely to break a lot of things we use
branches for ease of review. For members of the public, they can either
submit issues directly, or as part of a pull request on a forked copy of
the repository. -James Raff On Thu, Jul 30, 2015 at 10:08 AM, James Cummings <
James.Cummings@it.ox.ac.uk mailto:James.Cummings@it.ox.ac.uk> 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
mailto:James.Cummings@it.ox.ac.uk
Academic IT Services, University of Oxford -- tei-council mailing list
tei-council@lists.tei-c.org
mailto: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 --
Dr James Cummings, James.Cummings@it.ox.ac.uk
Academic IT Services, University of Oxford