> 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. — 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)
