146 lines
5.3 KiB
Markdown
146 lines
5.3 KiB
Markdown
# ifc-commit
|
|
|
|
> Git-native workflows for IFC
|
|
|
|
An experiment started at the [Porto OpenBIM Hackathon](https://www.buildingsmart.org/openbim-hackathon-porto-2026/). Live at [ifcc.gitaec.org](https://ifcc.gitaec.org).
|
|
|
|
---
|
|
|
|
## Background
|
|
|
|
IFC and the openBIM ecosystem have made significant progress in enabling data
|
|
exchange between the many disciplines involved in a construction project.
|
|
As workflows grow more complex — more actors, more iterations, more
|
|
concurrent modifications — a gap becomes apparent: there is no standard way
|
|
to track *who* changed *what*, *when*, and *why* across the lifetime of a model.
|
|
|
|
Git has answered this question for software development for decades, with a
|
|
mature model for branching, ownership, and modification history. ifc-commit
|
|
explores how that same paradigm can be applied to IFC, with the goal of
|
|
contributing a useful building block to the openBIM ecosystem.
|
|
|
|
---
|
|
|
|
## Overview
|
|
|
|
ifc-commit is a tool for working with IFC files in a git-based workflow.
|
|
It allows parts of a model to be extracted, modified, and merged back —
|
|
operations that can be declared in a configuration file, executed
|
|
automatically, and committed to a repository with a full trace of what
|
|
changed and who triggered the change.
|
|
|
|
The project covers three layers:
|
|
|
|
- **Command-line interface** — composable operations for extracting, merging,
|
|
splitting, moving, and removing IFC elements.
|
|
- **Pipeline system** — simple configuration files that chain operations
|
|
together and commit the results back to a git repository on every run.
|
|
- **Provenance inside the model** — git metadata embedded directly in the IFC
|
|
file using standard property sets, so every touched element carries a full
|
|
record of who changed it and why.
|
|
|
|
Built on [IfcOpenShell](https://ifcopenshell.org) and hosted on [gitaec.org](https://gitaec.org).
|
|
|
|
---
|
|
|
|
## Git Inside IFC
|
|
|
|
The central idea is to store git metadata directly inside the IFC file, using
|
|
mechanisms that already exist in the IFC specification. This way, any
|
|
IFC-aware tool — viewer, validator, or plugin — can read the provenance data
|
|
without any custom extension.
|
|
|
|
Two layers are used:
|
|
|
|
**File level.** `IfcApplication.Version` stores the current commit hash as a
|
|
lightweight stamp on the whole file. Every tool that reads `IfcOwnerHistory`
|
|
sees it automatically.
|
|
|
|
> **Example** — what this looks like in the IFC STEP file:
|
|
> ```
|
|
> #2=IFCAPPLICATION(#1,'a1b2c3d4','ifc-commit','ifc-commit');
|
|
> ```
|
|
|
|
**Element level.** A `Pset_GitCommit` property set is attached to every
|
|
element touched by an operation. It carries the full commit context: hash,
|
|
message, author, date, and branch.
|
|
|
|
> **Example** — reading the property set back in Python:
|
|
> ```python
|
|
> for rel in element.IsDefinedBy:
|
|
> if rel.is_a("IfcRelDefinesByProperties"):
|
|
> pset = rel.RelatingPropertyDefinition
|
|
> if pset.Name == "Pset_GitCommit":
|
|
> props = {p.Name: p.NominalValue.wrappedValue
|
|
> for p in pset.HasProperties}
|
|
> # props = {
|
|
> # "CommitHash": "a1b2c3d4f5e6c7b8",
|
|
> # "CommitMessage": "Fix wall thickness in level 2",
|
|
> # "CommitAuthor": "alice <***@***>",
|
|
> # "CommitDate": "2026-03-24T14:30:00Z",
|
|
> # "CommitBranch": "feature/level-2-walls",
|
|
> # }
|
|
> ```
|
|
|
|
Unknown property sets are silently preserved by Revit, ArchiCAD, and other
|
|
tools, so the metadata travels with the model through the full exchange chain.
|
|
|
|
This makes it possible to apply the full git workflow to BIM: **branches,
|
|
forks, hotfixes, pull requests, and merge reviews** — with every element
|
|
carrying a traceable record of who changed it and from which branch.
|
|
|
|
---
|
|
|
|
## Pipeline System
|
|
|
|
An `ifccommit.yaml` file in any repository declares which operations to run:
|
|
|
|
```yaml
|
|
operations:
|
|
- name: extract-structure
|
|
command: extract
|
|
input: models/full.ifc
|
|
output: dist/structure.ifc
|
|
types: [IfcWall, IfcSlab]
|
|
|
|
- name: split-by-storey
|
|
command: split
|
|
input: models/full.ifc
|
|
outdir: dist/storeys/
|
|
|
|
- name: apply-modification
|
|
command: replace
|
|
base: models/full.ifc
|
|
space: A102
|
|
part: dist/team_updates.ifc
|
|
output: dist/merged.ifc
|
|
```
|
|
|
|
The web app fetches this file from the forge, shows a preview of the
|
|
operations, and streams execution logs in real time while committing the
|
|
results back to the repository.
|
|
|
|
---
|
|
|
|
## IFC Compliance
|
|
|
|
A deliberate design constraint is that ifc-commit introduces no proprietary
|
|
extensions. Every mechanism it relies on is already part of the IFC
|
|
specification:
|
|
|
|
- **`IfcOwnerHistory`** — the native per-element change record, carrying
|
|
timestamps, authorship, and change action.
|
|
- **`Pset_GitCommit`** — a custom property set following the standard
|
|
extension pattern. Tools that do not recognise it silently preserve it;
|
|
tools that do can surface full git provenance per element.
|
|
- **`IfcApplication.Version`** — a zero-overhead file-level stamp holding
|
|
the current commit hash.
|
|
|
|
Because custom property sets survive round-trips through Revit, ArchiCAD, and
|
|
other tools, the metadata travels with the model through the full exchange
|
|
chain — without requiring any plugin or custom viewer.
|
|
|
|
For a detailed account of the research behind this approach — the IFC
|
|
mechanisms surveyed, the tradeoffs considered, and the implementation — see
|
|
the [research notes](/research).
|
|
|