On Wednesday, December 31, 2014, Peter Kelly <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
> > On 31 Dec 2014, at 12:44 am, jan i <[email protected]> wrote: > > > > On Tuesday, December 30, 2014, jan i <[email protected]> wrote: > > > >> Hi Peter > >> > >> Seems your commit, destroyed some of the files I had made like > NamesTest.c > >> and OStest.c > >> > > > > think I got it covered, at least my branch can merge with master again. > > > > you deleted namestest.c with an explanation, and it seems ostest.c was > not > > added, my fault, due to a git problem I have......earlier removed > > non-committed files when I changed branch. > > The way we’re dealing with names needs to change; ideally each filter > should have a separate set of enum definitions for the XML names. Currently > every element name from every possible filter is included in the one place, > which isn’t scalable, and mixes in details from the various filters into > core. > > The main reason I removed it though was it was defining a duplicate symbol > called LibTests, which was causing problems. I can easily enough add it > back with the symbol NameTests, though until we have some tests there it > probably doesn’t make a difference. > > > can we agree that updates to stable is done with --squash so it is not a > > repeat of master but a line of points in time where our project was > stable. > > > > I would like to be able to checkout any commit in stable and know its a > > stable version. > > I’m not keen on the squash idea, for three reasons: > > 1. We “lose” history in the stable branch (that is, a git log shows less > detail, and we can’t narrow things down to individual commits). Of course > we still have all this information in master, so it’s not necessarily so > bad, but my opinion is it would be nice to have all this information > present in master. > > 2. With squash commits, there’s absolutely nothing to formally relate > commits in the stable branch to those in the master branch. The only way to > get a correspondence between the two is to look for similar times and > compare the commit messages/content, to match up a given commit in stable > and a given commit in master. If you see some change that has crept into > stable, and you want to find out the full history of how that happened, you > would have to first figure out which master commit it corresponded to, and > then look at the history for master to see the individual commits which > made up the corresponding squash commit in master. > > 3. With squash commits, we get multiple commit messages in one, meaning > that each commit in stable could contain a series of multiple unrelated > changes. > > If we want to make sure that every commit to stable is a line of points at > which the code was actually stable (that is, *not* containing commits that > don’t compile or pass the tests), then I recommend we go for a normal merge > instead. This avoids the problems above, while also giving us a set of > known stable points. I am not sure I understand the difference between a normal merge and --squash, but if you tell me it does the job then it is fine with me. I like to think of "master" having all details, and "stable" being an index over points where we potentially could do a release. I do agree that the connection is important, so maybe the commit in stable should always contain the GIT Id of HEAD. Having all detail in master makes the 2 branches historical identical, meaning finding a historical stable point becomes complicated. I would really prefer a "clean" stable, provided we can have a simple connection to "master" using e.g. GIT commit Id. We have unique chance to make it right, not like other projects who have a long version history ..... but it is important that we agree on the output (less the method, for me at least). > > — rgds jan i > Dr Peter M. Kelly > [email protected] > > PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > > -- Sent from My iPad, sorry for any misspellings.
