corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: [6/6] incubator-corinthia git commit: Don't store bin/lib/include dirs in repository
Date Tue, 30 Dec 2014 23:27:13 GMT
> On 31 Dec 2014, at 12:44 am, jan i <> wrote:
> On Tuesday, December 30, 2014, jan i <> 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

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message