Thanks Lou. I'm still confused about the being ahead/behind thing... I thought it was straightforward but the att.global.source branch had things which the compare said were ahead of dev that were added to the branch long before it was merged into dev, and are in the release we just did so..... how can it be ahead? Surely when that merge happens it is no longer ahead by those many...right? So if you can let me know whether those 25 were added before or after procmod was merged in I'd appreciate it just for my own understanding. -James On 16/12/16 11:20, Lou Burnard wrote:
Lb42procmod was me testing the processing model. I will have a look to see if any of the extra stuff I added should move to test and move it if so.
Sent from my Huawei Mobile
-------- Original Message -------- Subject: [tei-council] TEI branches From: James Cummings To: TEI Council CC:
Hi all,
What is our policy on keeping old branches around? I suppose it makes sense to keep the release ones (for awhile at least), but I've just gone and deleted the att.global.source one since I believe that all got merged in. Why do some branches that have been merged in seem to still be X number of commits ahead of dev?
I notice that we have 23 branches so wondered if we shouldn't be getting rid of some of those. The current list of branches is at:
https://github.com/TEIC/TEI/branches/all
Ones that I'd probably assume should be deleted include:
lb42-procmod (I assume this is all merged in though it says 498/25 (that is 498 behind dev, 25 ahead) .. that 25 makes me nervous.
msFrag (517 behind)
hcayless-appcrit (674/32)
sydb-xenodata (691/65)
peterstadler-antify (13560/12861 !) Not sure what this was for? Peter?
P5 (13566/56) Might be a confusing branch name? Was this an archival one? Rename if keeping?
P5-Council (last updated 8 years ago? Is this a historical one? Does it have anything interesting?)
P5-selections (updated 10 years ago by sydb)
Just thought I'd mention it since I think we should have branches for dev, master, release-X.Y.Z, gh-pages, and $anythingWeAreCurrentlyWorkingOn (Plus maybe a couple historical ones like sf/trunk?)
What do others think?
-James
-- 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
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
Well, having looked at it, I cannot see why it's a branch of P5 at all. It should be a separate repo all of its own. It has a copy of four XSLT scripts which were originally in the TEI-Simple repo (I think) but the rest of it is self contained : to quote the README ====== #TEI Processing Model Test suite# **Warning:** *work in progress* File testprocmod.odd contains an odd which should include a processing model that exercises all the behaviours listed in the spec for <model> To compile the corresponding XSLT, use oXyGen to define a validation scenario that uses the file XSL/pm_oddtoxsl.xsl (other XSLT files in the same directory are included by this one) The result is file testprocmod.xsl which should convert a TEI-XML file conforming to the testprocmod.rnc schema into HTML. testprocmod.xml is a silly test file; associate it with testprocmod.xsl to see if anything works. ----------------- It would be nice if someone who actually understands the processing model could take a look at it, if only to check that it's still syntactically correct. On 16/12/16 12:36, James Cummings wrote:
Thanks Lou. I'm still confused about the being ahead/behind thing... I thought it was straightforward but the att.global.source branch had things which the compare said were ahead of dev that were added to the branch long before it was merged into dev, and are in the release we just did so..... how can it be ahead?
Surely when that merge happens it is no longer ahead by those many...right? So if you can let me know whether those 25 were added before or after procmod was merged in I'd appreciate it just for my own understanding.
-James
On 16/12/16 11:20, Lou Burnard wrote:
Lb42procmod was me testing the processing model. I will have a look to see if any of the extra stuff I added should move to test and move it if so.
Sent from my Huawei Mobile
-------- Original Message -------- Subject: [tei-council] TEI branches From: James Cummings To: TEI Council CC:
Hi all,
What is our policy on keeping old branches around? I suppose it makes sense to keep the release ones (for awhile at least), but I've just gone and deleted the att.global.source one since I believe that all got merged in. Why do some branches that have been merged in seem to still be X number of commits ahead of dev?
I notice that we have 23 branches so wondered if we shouldn't be getting rid of some of those. The current list of branches is at:
https://github.com/TEIC/TEI/branches/all
Ones that I'd probably assume should be deleted include:
lb42-procmod (I assume this is all merged in though it says 498/25 (that is 498 behind dev, 25 ahead) .. that 25 makes me nervous.
msFrag (517 behind)
hcayless-appcrit (674/32)
sydb-xenodata (691/65)
peterstadler-antify (13560/12861 !) Not sure what this was for? Peter?
P5 (13566/56) Might be a confusing branch name? Was this an archival one? Rename if keeping?
P5-Council (last updated 8 years ago? Is this a historical one? Does it have anything interesting?)
P5-selections (updated 10 years ago by sydb)
Just thought I'd mention it since I think we should have branches for dev, master, release-X.Y.Z, gh-pages, and $anythingWeAreCurrentlyWorkingOn (Plus maybe a couple historical ones like sf/trunk?)
What do others think?
-James
-- 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
I don't get the behind/ahead bit entirely, either. I had not deleted some of my earlier branches as I thought someone had said we should hang on to them for historical purposes. In Subversion you could just leave them tucked into the /branches/ directory, and they didn't get in anyone's way. Is there any way to sequester them like that in git? If not, I agree we should go through and trim those we can. But we (or at least I, for one) would like a recipe for how to go about asking "what is in this branch that is not in dev/?".
"Behind" indicates how many commits are in the dev that are not in the
current branch, and "ahead" indicates how many commits are in the current
branch that are not in dev.
I think the best way of figuring out whether a branch is worth
investigating more, is to try and merge dev into it. If there are no
conflicts, or they are simple to fix, then the branch can still be safely
merged into dev if that's the desired goal. If not, it's best to lose it as
it will hardly ever be useful.
I'm in favor of eliminating obsolete branches; they just create confusion.
In an ideal world branches should be created to work safely on something;
when it's done merge back into master (or dev in our case) and remove the
branch.
Raff
On Fri, Dec 16, 2016 at 9:19 AM, Syd Bauman
I don't get the behind/ahead bit entirely, either. I had not deleted some of my earlier branches as I thought someone had said we should hang on to them for historical purposes. In Subversion you could just leave them tucked into the /branches/ directory, and they didn't get in anyone's way. Is there any way to sequester them like that in git?
If not, I agree we should go through and trim those we can. But we (or at least I, for one) would like a recipe for how to go about asking "what is in this branch that is not in dev/?". -- 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
On 16/12/16 15:24, Raffaele Viglianti wrote:
"Behind" indicates how many commits are in the dev that are not in the current branch, and "ahead" indicates how many commits are in the current branch that are not in dev.
Hi Raff, That was my understanding but for some reason the att.global.source branch, that I've now deleted and so can't show you, was saying it was 5 commits ahead of dev, but those commits were all the work that I'd done on it including the last one where I'd forgotten to put predeclare="true" on the classSpec. But when I look at dev all of those changes were merged in perfectly fine. i.e. https://github.com/TEIC/TEI/blob/dev/P5/Source/Specs/att.global.source.xml#L... has the predeclare="true" in it. But it was still saying it was 5 commits ahead because of these. You see why I'm confused, right? -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
Hmm. Is it possible that those changes were made directly in dev? I think
the behind/ahead count is based on commit SHA numbers as opposed to the
actual content of commits.
I'm too lazy to test this, but I think if you make a change in branch A (0
behind, 1 ahead) and then make the same change in Master, branch A will be
1 behind, 1 ahead.
If those corrections you mentioned were indeed merged, then I have no idea
what's going on :)
Raff
On Fri, Dec 16, 2016 at 11:31 AM, James Cummings wrote: On 16/12/16 15:24, Raffaele Viglianti wrote: "Behind" indicates how many commits are in the dev that are not in the
current branch, and "ahead" indicates how many commits are in the current
branch that are not in dev. Hi Raff, That was my understanding but for some reason the att.global.source
branch, that I've now deleted and so can't show you, was saying it was 5
commits ahead of dev, but those commits were all the work that I'd done on
it including the last one where I'd forgotten to put predeclare="true" on
the classSpec. But when I look at dev all of those changes were merged in
perfectly fine. i.e.
https://github.com/TEIC/TEI/blob/dev/P5/Source/Specs/att.glo
bal.source.xml#L9
has the predeclare="true" in it. But it was still saying it was 5 commits ahead because of these. You see why I'm confused, right? -James --
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
Lots of things could have happened, including the branch commits being "squashed" when they were merged into dev or further playing around on the branch after it was merged (pretty sure both of those happened with hcayless-appcrit). I wouldn't worry about it too much. Also entirely possible someone "merged" by copying one or more files from a branch to dev and committing them. As Raff points out, it's looking strictly at commit hashes, not at the content of file changes, so merge commits might be part of the reason too. On Fri, Dec 16, 2016 at 11:37 AM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:
Hmm. Is it possible that those changes were made directly in dev? I think the behind/ahead count is based on commit SHA numbers as opposed to the actual content of commits.
I'm too lazy to test this, but I think if you make a change in branch A (0 behind, 1 ahead) and then make the same change in Master, branch A will be 1 behind, 1 ahead.
If those corrections you mentioned were indeed merged, then I have no idea what's going on :)
Raff
On Fri, Dec 16, 2016 at 11:31 AM, James Cummings < James.Cummings@it.ox.ac.uk
wrote:
On 16/12/16 15:24, Raffaele Viglianti wrote:
"Behind" indicates how many commits are in the dev that are not in the current branch, and "ahead" indicates how many commits are in the current branch that are not in dev.
Hi Raff,
That was my understanding but for some reason the att.global.source branch, that I've now deleted and so can't show you, was saying it was 5 commits ahead of dev, but those commits were all the work that I'd done on it including the last one where I'd forgotten to put predeclare="true" on the classSpec. But when I look at dev all of those changes were merged in perfectly fine. i.e. https://github.com/TEIC/TEI/blob/dev/P5/Source/Specs/att.glo bal.source.xml#L9 has the predeclare="true" in it.
But it was still saying it was 5 commits ahead because of these.
You see why I'm confused, right?
-James
-- 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
-- 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
participants (5)
-
Hugh Cayless -
James Cummings -
Lou Burnard -
Raffaele Viglianti -
Syd Bauman