thanks. My rebranding as mbtaylor is done and seemed reasonably painless.
On Fri, 26 Apr 2013, Tim Jenness wrote:
> The repository doesn't know anything about your github user name. Github
> relies on the email address attached to the github account to work out who
> you are in the repository (hence my comment about the mcneves email
> address).
>
>
> On Fri, Apr 26, 2013 at 4:51 AM, Mark Taylor <[log in to unmask]>wrote:
>
> > Tim,
> >
> > looks pretty good, thanks a lot.
> >
> > One minor complication: I was going to change my github user id
> > from MarkTaylor to mbtaylor since I seem to be the only kid in
> > school using CamelCase and I don't want everyone else to laugh
> > at me in the playground.
> >
> > I can see how to do this (Account Settings/Change Username);
> > the warning says:
> >
> > Changing your username can have unintended side effects.
> > Really change your username?
> > Unexpected bad things will happen if you don't read this
> > We will not set up redirects for your old username.
> > https://github.com/MarkTaylor will 404.
> > You will need to update your local repositories to point to the new
> > location.
> > Renaming may take a few minutes to complete.
> >
> > All of the things it mentions I can cope with, so it looks to me like
> > it will update relevant things elsewhere on github, but I can't tell
> > for sure without doing it. Do you think my place in starjava history
> > would survive this change, or could relatively easily be reinstated
> > if it doesn't?
> >
> > Clearly this isn't #1 priority, if you think it's likely to cause trouble
> > I can just not do it. Or I could try it and see what happens;
> > probably it's reversible by just changing it back again.
> >
> > I'll check with Margarida and see if she is github/mcneves.
> >
> > Mark
> >
> > On Thu, 25 Apr 2013, Tim Jenness wrote:
> >
> > > Mark,
> > >
> > > Take a gander at
> > >
> > > https://github.com/Starlink/starjava
> > >
> > > It might be a couple of patches out of date.
> > >
> > > I've created a "Java developers" team in Starlink and added your account
> > as
> > > a general admin. I wasn't sure if the "mcneves" user is the same mcneves
> > > that has been committing to the starjava repository. I replaced "mcneves"
> > > with the email address that I got from some correspondence with you. If
> > > that is the same person then we need to add them to the Java developers
> > > group and ideally they need to register the email address that I used so
> > > that github picks them up as the same person.
> > >
> > >
> > >
> > > On Wed, Apr 24, 2013 at 1:02 PM, Mark Taylor <[log in to unmask]
> > >wrote:
> > >
> > > > single repository sounds good to me.
> > > >
> > > > I did see the ant question - I was hoping Peter would tackle that one
> > too,
> > > > since he set up the build system, and I'm not sure without looking into
> > > > it what the modified ant does which is not offered by a 'standard' ant.
> > > > Probably it would be possible to make some simplifications to the build
> > > > system, since I suspect there is some complexity in there which is not
> > > > much used, though I'm not sure. However, it's probably a somewhat
> > > > fiddly job, and I don't think(?) there is a compelling reason to
> > > > synchronise it with repository changes.
> > > >
> > > > On Wed, 24 Apr 2013, Tim Jenness wrote:
> > > >
> > > > > Peter seems to be off air so I'm guessing we'll stick with the single
> > > > > repository model.
> > > > >
> > > > > PS did you see my ant question?
> > > > >
> > > > >
> > > > > On Sun, Apr 21, 2013 at 2:51 PM, Mark Taylor <
> > [log in to unmask]
> > > > >wrote:
> > > > >
> > > > > > Hmm. The situation is certainly not as extreme as for classic
> > > > starlink,
> > > > > > in that the whole thing is much smaller, and there are considerably
> > > > > > fewer items that people might want to work on independently.
> > > > > > SPLAT, TOPCAT, and STILTS all require pretty large chunks of the
> > > > > > rest of the tree to work, and I can't see many other top-level
> > > > > > components that people are likely to want to work on (pal maybe).
> > > > > >
> > > > > > So I'm a bit resistant to the multi-repository model since it seems
> > > > > > to entail more complexity, though I fully admit that's largely
> > > > > > fear from not understanding how submodules work.
> > > > > >
> > > > > > Since Peter understands both starjava and git, I'd welcome his
> > views.
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > > On Sat, 20 Apr 2013, Tim Jenness wrote:
> > > > > >
> > > > > > > Yes. I would edge towards having separate topcat, splat etc git
> > > > > > > repositories and a top-level repository with submodules. The
> > > > requirement
> > > > > > > for the custom ant is a bit of a pain but it's also the case that
> > > > splat
> > > > > > > depends on many other starjava components to build. It's always
> > > > possible
> > > > > > to
> > > > > > > extract directory trees later on into separate repositories as I
> > did
> > > > for
> > > > > > > PAL in the Starlink tree when people wanted access to PAL without
> > > > getting
> > > > > > > the whole of starlink (although to retain sanity you really have
> > to
> > > > put
> > > > > > the
> > > > > > > new submodule in a different part of the tree otherwise doing
> > > > checkouts
> > > > > > > across the boundary when the code was inside and then outside is
> > > > > > painful).
> > > > > > > I don't know what the market is for people wanting to do forks of
> > > > splat
> > > > > > > without also wanting to take on the rest of starjava.
> > > > > > >
> > > > > > > The main problem with the thin repository + submodules approach
> > is
> > > > > > getting
> > > > > > > the history correct in the top-level repository so that you can
> > > > checkout
> > > > > > a
> > > > > > > complete version from one year ago (say). It may be that a "git
> > > > submodule
> > > > > > > foreach" call is the easiest way to get everything at a
> > particular
> > > > tag.
> > > > > > For
> > > > > > > Mark it's probably simplest to do starjava monolithically.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 19, 2013 at 12:44 PM, Graham Bell <
> > > > [log in to unmask]
> > > > > > >wrote:
> > > > > > >
> > > > > > > > I had in mind one single repository, in github. Under
> > Starlink/
> > > > sounds
> > > > > > > >> reasonable. If anybody else has opinions, by all means speak
> > up.
> > > > > > > >>
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I once saw a talk online by Linus Torvalds about git where he
> > was
> > > > > > > > recommending not putting everything in a single repository.
> > The
> > > > reason
> > > > > > > > being, if I remember correctly, that -- unlike CVS and
> > Subversion
> > > > --
> > > > > > git
> > > > > > > > doesn't let you check out a subdirectory of your repository.
> > So
> > > > the
> > > > > > > > advantage of splitting the repository up would be to allow
> > people
> > > > to
> > > > > > check
> > > > > > > > out individual components. (And git should run faster on
> > smaller
> > > > > > > > repositories.)
> > > > > > > >
> > > > > > > > For example if someone wanted to contribute to an application
> > via
> > > > > > GitHub
> > > > > > > > they would only need to fork and issue a pull request on that
> > > > part. It
> > > > > > > > might also help anyone who wanted to package the software --
> > for
> > > > > > example on
> > > > > > > > ArchLinux you can now contribute PKGBUILD files giving a Git
> > URL
> > > > > > (including
> > > > > > > > branch or commit) as the source for a package. (Although
> > there are
> > > > > > already
> > > > > > > > TOPCAT and STILTS packages and building might be awkward if
> > all the
> > > > > > > > components really need a custom ant.) There could be a
> > top-level
> > > > > > > > repository which includes the components as submodules -- that
> > > > seems to
> > > > > > > > work fairly well for the main Starlink repository.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Graham
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Mark Taylor Astronomical Programmer Physics, Bristol
> > University, UK
> > > > > > [log in to unmask] +44-117-9288776
> > > > http://www.star.bris.ac.uk/~mbt/
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> > > > [log in to unmask] +44-117-9288776
> > http://www.star.bris.ac.uk/~mbt/
> > > >
> > >
> >
> > --
> > Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> > [log in to unmask] +44-117-9288776 http://www.star.bris.ac.uk/~mbt/
> >
>
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-9288776 http://www.star.bris.ac.uk/~mbt/
|
