corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject [6/6] incubator-corinthia git commit: Don't store bin/lib/include dirs in repository
Date Wed, 31 Dec 2014 07:11:11 GMT
On Wednesday, December 31, 2014, Peter Kelly <
<javascript:_e(%7B%7D,'cvml','');>> wrote:

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

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

> —

jan i

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

Sent from My iPad, sorry for any misspellings.

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