Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Exactly. So the remaining piece is really PAW adopting the same source-control model rather than treating Git primarily as an object-movement target.

If that happens, the TM1 selective-push work and the preservation of non-TM1 files should fit together naturally.

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

TM1 is quite different from a traditional programming project, where developers work directly with files and Git tracks those file changes. In TM1, the objects live inside a running multidimensional database and are highly interconnected, so the real challenge is often not just making a selective Git commit, but deciding exactly which TM1 changes should be promoted together.

That is where the SPACE TM1 Lifecycle Manager becomes particularly useful.

You can compare two TM1 environments side by side, see exactly what is different, selectively choose the objects you want to promote, package those changes into a release, review the release and then either deploy them to your target evironment or Publish to Git, without leaving IBM Planning Analytics Workspace.

For me, this is a more natural way to approach "selective commits" in TM1. Instead of starting with Git files and deciding what to stage, you start with the actual TM1 environments, understand the delta, select the required TM1 objects, and let that selection become the release/deployment unit.

Before syncing anything into the target environment, SPACE also provides a preview of the changes, so you can review what will be created, updated or changed before applying the sync.

We also use our own text-based representation of TM1 objects. JSON is excellent as a machine-readable format, but it is not always ideal for Git review - nested structures, ordering and metadata can make relatively small TM1 changes produce noisy diffs. The SPACE format is designed specifically so changes to cubes, dimensions, hierarchies, attributes, views, subsets, processes and chores are easier for a TM1 developer to read and compare in Git.

Another important part is traceability. Everything in SPACE is logged, so the Lifecycle Manager also gives you a clear history of who deployed what, where and when. Combined with Git history, that makes it much easier to understand both the source-control history and the actual TM1 deployment history.

The goal was therefore to keep Git underneath as the source-control mechanism, but make the workflow much more natural for TM1:

Compare environments → select the required changes → create a release → review/preview → Publish or Sync → retain the full deployment history.

That gives users selective source control together with the broader TM1 lifecycle, without requiring every TM1 developer to work directly with Git concepts such as push, pull and merge.

And this is also where SPACE AI becomes particularly interesting. The next step is not simply "AI for Git", but AI-assisted TM1 lifecycle management - for example:

"Show me what changed in DEV since the last production release."

"Which of these changes belong to the new forecasting model?"

"Create a release with everything required for this cube."

"Am I missing any dependent dimensions, subsets or processes?"

"Review this release and tell me what could be risky before I deploy it."

"Who deployed this object, when, and what changed?"

So instead of AI trying to understand Git files in isolation, it can work with the TM1 environment comparison, object relationships, releases, Git history and SPACE deployment logs to help users understand, package and safely promote changes.

The direction we are working towards is:

AI analyzes the TM1 delta → groups related changes → suggests the release → explains dependencies and risks → user reviews → SPACE deploys/syncs → the full action history remains auditable.

Git stays underneath, but the user works at the TM1 lifecycle level.

Exactly. So the remaining piece is really PAW adopting the same source-control model rather than treating Git primarily as an object-movement target.

If that happens, the TM1 selective-push work and the preservation of non-TM1 files should fit together naturally.

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

I don't mind you plugging SPACE every so often, Vlad ;-), and I'm sure there are as many different ways people want to do things, have different needs for ultimately the same capabilities and, perhaps most importantly, their own preferences as to how and with what they want to do them. And I get it, SPACE serves one of those ways nicely and without ever leaving PA.

Thing is, I'm first and foremost a TM1-er, and there are many different kinds of TM1-ers out there - I'm probably of the more exotic kind (read: I might be rare ;-)). I'm one of those that would happily live in VSCode, never touch a modelling UI, and build an entire model from code and use the occasional transient TI process.

PA is obviously the prime, and by far the most important, consumer of TM1, but PA isn't TM1. My job is to make sure TM1 provides the capabilities for PA, SPACE, and other tools, CI/CD pipeline, as well as that slightly odd developer living in VSCode to build whatever workflow works for them.

So yes, what you're describing with SPACE is a perfectly valid workflow on top of this. I'm just looking at it one level lower.

For me the native TM1 Git integration should make TM1 a proper participant in Git source control. tm1project.json defines what constitutes the project; pull lets me build/update TM1 from that source; push lets me commit changes made in TM1 back to it; and selective push should allow a client to decide what belongs in a particular commit without disturbing everything else in the repository.

What happens on top of that is deliberately somebody else's choice. We all know the experience PAW put around it, SPACE may use it to provide a complete lifecycle experience (do you - or did you roll your own source definition?), somebody else may build something entirely different and I may just sit in VSCode and use any and all GIT tooling at my disposal and use the occasional call to the REST API.

If we've made the Git integration sufficiently clean and complete that all of those are possible, then, from a TM1 perspective, I think we've done our job.

TM1 is quite different from a traditional programming project, where developers work directly with files and Git tracks those file changes. In TM1, the objects live inside a running multidimensional database and are highly interconnected, so the real challenge is often not just making a selective Git commit, but deciding exactly which TM1 changes should be promoted together.

That is where the SPACE TM1 Lifecycle Manager becomes particularly useful.

You can compare two TM1 environments side by side, see exactly what is different, selectively choose the objects you want to promote, package those changes into a release, review the release and then either deploy them to your target evironment or Publish to Git, without leaving IBM Planning Analytics Workspace.

For me, this is a more natural way to approach "selective commits" in TM1. Instead of starting with Git files and deciding what to stage, you start with the actual TM1 environments, understand the delta, select the required TM1 objects, and let that selection become the release/deployment unit.

Before syncing anything into the target environment, SPACE also provides a preview of the changes, so you can review what will be created, updated or changed before applying the sync.

We also use our own text-based representation of TM1 objects. JSON is excellent as a machine-readable format, but it is not always ideal for Git review - nested structures, ordering and metadata can make relatively small TM1 changes produce noisy diffs. The SPACE format is designed specifically so changes to cubes, dimensions, hierarchies, attributes, views, subsets, processes and chores are easier for a TM1 developer to read and compare in Git.

Another important part is traceability. Everything in SPACE is logged, so the Lifecycle Manager also gives you a clear history of who deployed what, where and when. Combined with Git history, that makes it much easier to understand both the source-control history and the actual TM1 deployment history.

The goal was therefore to keep Git underneath as the source-control mechanism, but make the workflow much more natural for TM1:

Compare environments → select the required changes → create a release → review/preview → Publish or Sync → retain the full deployment history.

That gives users selective source control together with the broader TM1 lifecycle, without requiring every TM1 developer to work directly with Git concepts such as push, pull and merge.

And this is also where SPACE AI becomes particularly interesting. The next step is not simply "AI for Git", but AI-assisted TM1 lifecycle management - for example:

"Show me what changed in DEV since the last production release."

"Which of these changes belong to the new forecasting model?"

"Create a release with everything required for this cube."

"Am I missing any dependent dimensions, subsets or processes?"

"Review this release and tell me what could be risky before I deploy it."

"Who deployed this object, when, and what changed?"

So instead of AI trying to understand Git files in isolation, it can work with the TM1 environment comparison, object relationships, releases, Git history and SPACE deployment logs to help users understand, package and safely promote changes.

The direction we are working towards is:

AI analyzes the TM1 delta → groups related changes → suggests the release → explains dependencies and risks → user reviews → SPACE deploys/syncs → the full action history remains auditable.

Git stays underneath, but the user works at the TM1 lifecycle level.

Exactly. So the remaining piece is really PAW adopting the same source-control model rather than treating Git primarily as an object-movement target.

If that happens, the TM1 selective-push work and the preservation of non-TM1 files should fit together naturally.

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Yes we rolled our own source definition and that was a deliberate choice.

For me, the important question was not only whether TM1 objects could be stored in Git, but whether the source representation made the actual TM1 change easy to understand.

Because TM1 is quite different from a classical source-code project, the meaningful unit is often not the file itself, but a small semantic change inside a TM1 object.

That is why SPACE uses its own text-based representation for cubes, dimensions, hierarchies, attributes, views, subsets, rules, processes and chores. It is designed to produce clean, meaningful Git diffs, we wanted the source itself to be both TM1-friendly and Git-friendly.

For example, if someone changes a single attribute value, you can see that individual change directly in the diff rather than inspecting a much larger serialized JSON structure.

I don't mind you plugging SPACE every so often, Vlad ;-), and I'm sure there are as many different ways people want to do things, have different needs for ultimately the same capabilities and, perhaps most importantly, their own preferences as to how and with what they want to do them. And I get it, SPACE serves one of those ways nicely and without ever leaving PA.

Thing is, I'm first and foremost a TM1-er, and there are many different kinds of TM1-ers out there - I'm probably of the more exotic kind (read: I might be rare ;-)). I'm one of those that would happily live in VSCode, never touch a modelling UI, and build an entire model from code and use the occasional transient TI process.

PA is obviously the prime, and by far the most important, consumer of TM1, but PA isn't TM1. My job is to make sure TM1 provides the capabilities for PA, SPACE, and other tools, CI/CD pipeline, as well as that slightly odd developer living in VSCode to build whatever workflow works for them.

So yes, what you're describing with SPACE is a perfectly valid workflow on top of this. I'm just looking at it one level lower.

For me the native TM1 Git integration should make TM1 a proper participant in Git source control. tm1project.json defines what constitutes the project; pull lets me build/update TM1 from that source; push lets me commit changes made in TM1 back to it; and selective push should allow a client to decide what belongs in a particular commit without disturbing everything else in the repository.

What happens on top of that is deliberately somebody else's choice. We all know the experience PAW put around it, SPACE may use it to provide a complete lifecycle experience (do you - or did you roll your own source definition?), somebody else may build something entirely different and I may just sit in VSCode and use any and all GIT tooling at my disposal and use the occasional call to the REST API.

If we've made the Git integration sufficiently clean and complete that all of those are possible, then, from a TM1 perspective, I think we've done our job.

TM1 is quite different from a traditional programming project, where developers work directly with files and Git tracks those file changes. In TM1, the objects live inside a running multidimensional database and are highly interconnected, so the real challenge is often not just making a selective Git commit, but deciding exactly which TM1 changes should be promoted together.

That is where the SPACE TM1 Lifecycle Manager becomes particularly useful.

You can compare two TM1 environments side by side, see exactly what is different, selectively choose the objects you want to promote, package those changes into a release, review the release and then either deploy them to your target evironment or Publish to Git, without leaving IBM Planning Analytics Workspace.

For me, this is a more natural way to approach "selective commits" in TM1. Instead of starting with Git files and deciding what to stage, you start with the actual TM1 environments, understand the delta, select the required TM1 objects, and let that selection become the release/deployment unit.

Before syncing anything into the target environment, SPACE also provides a preview of the changes, so you can review what will be created, updated or changed before applying the sync.

We also use our own text-based representation of TM1 objects. JSON is excellent as a machine-readable format, but it is not always ideal for Git review - nested structures, ordering and metadata can make relatively small TM1 changes produce noisy diffs. The SPACE format is designed specifically so changes to cubes, dimensions, hierarchies, attributes, views, subsets, processes and chores are easier for a TM1 developer to read and compare in Git.

Another important part is traceability. Everything in SPACE is logged, so the Lifecycle Manager also gives you a clear history of who deployed what, where and when. Combined with Git history, that makes it much easier to understand both the source-control history and the actual TM1 deployment history.

The goal was therefore to keep Git underneath as the source-control mechanism, but make the workflow much more natural for TM1:

Compare environments → select the required changes → create a release → review/preview → Publish or Sync → retain the full deployment history.

That gives users selective source control together with the broader TM1 lifecycle, without requiring every TM1 developer to work directly with Git concepts such as push, pull and merge.

And this is also where SPACE AI becomes particularly interesting. The next step is not simply "AI for Git", but AI-assisted TM1 lifecycle management - for example:

"Show me what changed in DEV since the last production release."

"Which of these changes belong to the new forecasting model?"

"Create a release with everything required for this cube."

"Am I missing any dependent dimensions, subsets or processes?"

"Review this release and tell me what could be risky before I deploy it."

"Who deployed this object, when, and what changed?"

So instead of AI trying to understand Git files in isolation, it can work with the TM1 environment comparison, object relationships, releases, Git history and SPACE deployment logs to help users understand, package and safely promote changes.

The direction we are working towards is:

AI analyzes the TM1 delta → groups related changes → suggests the release → explains dependencies and risks → user reviews → SPACE deploys/syncs → the full action history remains auditable.

Git stays underneath, but the user works at the TM1 lifecycle level.

Exactly. So the remaining piece is really PAW adopting the same source-control model rather than treating Git primarily as an object-movement target.

If that happens, the TM1 selective-push work and the preservation of non-TM1 files should fit together naturally.

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

I don't mind you plugging SPACE every so often, Vlad ;-), and I'm sure there are as many different ways people want to do things, have different needs for ultimately the same capabilities and, perhaps most importantly, their own preferences as to how and with what they want to do them. And I get it, SPACE serves one of those ways nicely and without ever leaving PA.

Thing is, I'm first and foremost a TM1-er, and there are many different kinds of TM1-ers out there - I'm probably of the more exotic kind (read: I might be rare ;-)). I'm one of those that would happily live in VSCode, never touch a modelling UI, and build an entire model from code and use the occasional transient TI process.

PA is obviously the prime, and by far the most important, consumer of TM1, but PA isn't TM1. My job is to make sure TM1 provides the capabilities for PA, SPACE, and other tools, CI/CD pipeline, as well as that slightly odd developer living in VSCode to build whatever workflow works for them.

So yes, what you're describing with SPACE is a perfectly valid workflow on top of this. I'm just looking at it one level lower.

For me the native TM1 Git integration should make TM1 a proper participant in Git source control. tm1project.json defines what constitutes the project; pull lets me build/update TM1 from that source; push lets me commit changes made in TM1 back to it; and selective push should allow a client to decide what belongs in a particular commit without disturbing everything else in the repository.

What happens on top of that is deliberately somebody else's choice. We all know the experience PAW put around it, SPACE may use it to provide a complete lifecycle experience (do you - or did you roll your own source definition?), somebody else may build something entirely different and I may just sit in VSCode and use any and all GIT tooling at my disposal and use the occasional call to the REST API.

If we've made the Git integration sufficiently clean and complete that all of those are possible, then, from a TM1 perspective, I think we've done our job.

TM1 is quite different from a traditional programming project, where developers work directly with files and Git tracks those file changes. In TM1, the objects live inside a running multidimensional database and are highly interconnected, so the real challenge is often not just making a selective Git commit, but deciding exactly which TM1 changes should be promoted together.

That is where the SPACE TM1 Lifecycle Manager becomes particularly useful.

You can compare two TM1 environments side by side, see exactly what is different, selectively choose the objects you want to promote, package those changes into a release, review the release and then either deploy them to your target evironment or Publish to Git, without leaving IBM Planning Analytics Workspace.

For me, this is a more natural way to approach "selective commits" in TM1. Instead of starting with Git files and deciding what to stage, you start with the actual TM1 environments, understand the delta, select the required TM1 objects, and let that selection become the release/deployment unit.

Before syncing anything into the target environment, SPACE also provides a preview of the changes, so you can review what will be created, updated or changed before applying the sync.

We also use our own text-based representation of TM1 objects. JSON is excellent as a machine-readable format, but it is not always ideal for Git review - nested structures, ordering and metadata can make relatively small TM1 changes produce noisy diffs. The SPACE format is designed specifically so changes to cubes, dimensions, hierarchies, attributes, views, subsets, processes and chores are easier for a TM1 developer to read and compare in Git.

Another important part is traceability. Everything in SPACE is logged, so the Lifecycle Manager also gives you a clear history of who deployed what, where and when. Combined with Git history, that makes it much easier to understand both the source-control history and the actual TM1 deployment history.

The goal was therefore to keep Git underneath as the source-control mechanism, but make the workflow much more natural for TM1:

Compare environments → select the required changes → create a release → review/preview → Publish or Sync → retain the full deployment history.

That gives users selective source control together with the broader TM1 lifecycle, without requiring every TM1 developer to work directly with Git concepts such as push, pull and merge.

And this is also where SPACE AI becomes particularly interesting. The next step is not simply "AI for Git", but AI-assisted TM1 lifecycle management - for example:

"Show me what changed in DEV since the last production release."

"Which of these changes belong to the new forecasting model?"

"Create a release with everything required for this cube."

"Am I missing any dependent dimensions, subsets or processes?"

"Review this release and tell me what could be risky before I deploy it."

"Who deployed this object, when, and what changed?"

So instead of AI trying to understand Git files in isolation, it can work with the TM1 environment comparison, object relationships, releases, Git history and SPACE deployment logs to help users understand, package and safely promote changes.

The direction we are working towards is:

AI analyzes the TM1 delta → groups related changes → suggests the release → explains dependencies and risks → user reviews → SPACE deploys/syncs → the full action history remains auditable.

Git stays underneath, but the user works at the TM1 lifecycle level.

Exactly. So the remaining piece is really PAW adopting the same source-control model rather than treating Git primarily as an object-movement target.

If that happens, the TM1 selective-push work and the preservation of non-TM1 files should fit together naturally.

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Hi Hubert,

Thanks for sharing your notes.

I have also used VS Code to leverage Git features such as version control. However, from a TM1 developer's perspective, using Git through VS Code can be a relatively lengthy process, as TM1 developers may not regularly work with VS Code or Git commands.

It would be very helpful if we could perform full or selective Push/Pull operations directly from PAW. This would make Git integration much more user-friendly and efficient for TM1 developers.

Regarding SPACE, I am not yet familiar with how we can utilize it or what its specific purpose is in this context. It would be helpful if you could provide some guidance or additional information on how SPACE could support this workflow.

Thanks,
Ajit

I don't mind you plugging SPACE every so often, Vlad ;-), and I'm sure there are as many different ways people want to do things, have different needs for ultimately the same capabilities and, perhaps most importantly, their own preferences as to how and with what they want to do them. And I get it, SPACE serves one of those ways nicely and without ever leaving PA.

Thing is, I'm first and foremost a TM1-er, and there are many different kinds of TM1-ers out there - I'm probably of the more exotic kind (read: I might be rare ;-)). I'm one of those that would happily live in VSCode, never touch a modelling UI, and build an entire model from code and use the occasional transient TI process.

PA is obviously the prime, and by far the most important, consumer of TM1, but PA isn't TM1. My job is to make sure TM1 provides the capabilities for PA, SPACE, and other tools, CI/CD pipeline, as well as that slightly odd developer living in VSCode to build whatever workflow works for them.

So yes, what you're describing with SPACE is a perfectly valid workflow on top of this. I'm just looking at it one level lower.

For me the native TM1 Git integration should make TM1 a proper participant in Git source control. tm1project.json defines what constitutes the project; pull lets me build/update TM1 from that source; push lets me commit changes made in TM1 back to it; and selective push should allow a client to decide what belongs in a particular commit without disturbing everything else in the repository.

What happens on top of that is deliberately somebody else's choice. We all know the experience PAW put around it, SPACE may use it to provide a complete lifecycle experience (do you - or did you roll your own source definition?), somebody else may build something entirely different and I may just sit in VSCode and use any and all GIT tooling at my disposal and use the occasional call to the REST API.

If we've made the Git integration sufficiently clean and complete that all of those are possible, then, from a TM1 perspective, I think we've done our job.

TM1 is quite different from a traditional programming project, where developers work directly with files and Git tracks those file changes. In TM1, the objects live inside a running multidimensional database and are highly interconnected, so the real challenge is often not just making a selective Git commit, but deciding exactly which TM1 changes should be promoted together.

That is where the SPACE TM1 Lifecycle Manager becomes particularly useful.

You can compare two TM1 environments side by side, see exactly what is different, selectively choose the objects you want to promote, package those changes into a release, review the release and then either deploy them to your target evironment or Publish to Git, without leaving IBM Planning Analytics Workspace.

For me, this is a more natural way to approach "selective commits" in TM1. Instead of starting with Git files and deciding what to stage, you start with the actual TM1 environments, understand the delta, select the required TM1 objects, and let that selection become the release/deployment unit.

Before syncing anything into the target environment, SPACE also provides a preview of the changes, so you can review what will be created, updated or changed before applying the sync.

We also use our own text-based representation of TM1 objects. JSON is excellent as a machine-readable format, but it is not always ideal for Git review - nested structures, ordering and metadata can make relatively small TM1 changes produce noisy diffs. The SPACE format is designed specifically so changes to cubes, dimensions, hierarchies, attributes, views, subsets, processes and chores are easier for a TM1 developer to read and compare in Git.

Another important part is traceability. Everything in SPACE is logged, so the Lifecycle Manager also gives you a clear history of who deployed what, where and when. Combined with Git history, that makes it much easier to understand both the source-control history and the actual TM1 deployment history.

The goal was therefore to keep Git underneath as the source-control mechanism, but make the workflow much more natural for TM1:

Compare environments → select the required changes → create a release → review/preview → Publish or Sync → retain the full deployment history.

That gives users selective source control together with the broader TM1 lifecycle, without requiring every TM1 developer to work directly with Git concepts such as push, pull and merge.

And this is also where SPACE AI becomes particularly interesting. The next step is not simply "AI for Git", but AI-assisted TM1 lifecycle management - for example:

"Show me what changed in DEV since the last production release."

"Which of these changes belong to the new forecasting model?"

"Create a release with everything required for this cube."

"Am I missing any dependent dimensions, subsets or processes?"

"Review this release and tell me what could be risky before I deploy it."

"Who deployed this object, when, and what changed?"

So instead of AI trying to understand Git files in isolation, it can work with the TM1 environment comparison, object relationships, releases, Git history and SPACE deployment logs to help users understand, package and safely promote changes.

The direction we are working towards is:

AI analyzes the TM1 delta → groups related changes → suggests the release → explains dependencies and risks → user reviews → SPACE deploys/syncs → the full action history remains auditable.

Git stays underneath, but the user works at the TM1 lifecycle level.

Exactly. So the remaining piece is really PAW adopting the same source-control model rather than treating Git primarily as an object-movement target.

If that happens, the TM1 selective-push work and the preservation of non-TM1 files should fit together naturally.

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Hi Ajit,

As I wrote already "I might be rare", I kind of hope I am actually especially as I'm not your typical TM1 developer and the last thing I want to do is trying to advocate that 'ordinary' TM1 developers should start leveraging VSCode for their day to day TM1 development, au-contrair!

And I'm with you, it would be great if PA(W) would 1) embrace the 'TM1 as code' model (for which TM1's GIT integration was created) and, once we have it in TM1, 2) add support for selective push. Selective pull on the other hand... that's not really something that in an "as code" model exist and something, from a source control and CI/CD point of view, be impossible to govern. 

Again, if "TM1 as code", and any CI/CD or other GIT based tooling/testing/pipelining that might go with it, is not for you then TM1's GIT integration might not be what you are looking for (and that's perfectly fine and probably still true for more then 95+% of the TM1 users.

As for SPACE, I'll leave that to Vlad to answer, but it, as per Vlad's response above, is not using TM1's GIT integration or it's standard's based 'source' specification.

Hi Hubert,

Thanks for sharing your notes.

I have also used VS Code to leverage Git features such as version control. However, from a TM1 developer's perspective, using Git through VS Code can be a relatively lengthy process, as TM1 developers may not regularly work with VS Code or Git commands.

It would be very helpful if we could perform full or selective Push/Pull operations directly from PAW. This would make Git integration much more user-friendly and efficient for TM1 developers.

Regarding SPACE, I am not yet familiar with how we can utilize it or what its specific purpose is in this context. It would be helpful if you could provide some guidance or additional information on how SPACE could support this workflow.

Thanks,
Ajit

I don't mind you plugging SPACE every so often, Vlad ;-), and I'm sure there are as many different ways people want to do things, have different needs for ultimately the same capabilities and, perhaps most importantly, their own preferences as to how and with what they want to do them. And I get it, SPACE serves one of those ways nicely and without ever leaving PA.

Thing is, I'm first and foremost a TM1-er, and there are many different kinds of TM1-ers out there - I'm probably of the more exotic kind (read: I might be rare ;-)). I'm one of those that would happily live in VSCode, never touch a modelling UI, and build an entire model from code and use the occasional transient TI process.

PA is obviously the prime, and by far the most important, consumer of TM1, but PA isn't TM1. My job is to make sure TM1 provides the capabilities for PA, SPACE, and other tools, CI/CD pipeline, as well as that slightly odd developer living in VSCode to build whatever workflow works for them.

So yes, what you're describing with SPACE is a perfectly valid workflow on top of this. I'm just looking at it one level lower.

For me the native TM1 Git integration should make TM1 a proper participant in Git source control. tm1project.json defines what constitutes the project; pull lets me build/update TM1 from that source; push lets me commit changes made in TM1 back to it; and selective push should allow a client to decide what belongs in a particular commit without disturbing everything else in the repository.

What happens on top of that is deliberately somebody else's choice. We all know the experience PAW put around it, SPACE may use it to provide a complete lifecycle experience (do you - or did you roll your own source definition?), somebody else may build something entirely different and I may just sit in VSCode and use any and all GIT tooling at my disposal and use the occasional call to the REST API.

If we've made the Git integration sufficiently clean and complete that all of those are possible, then, from a TM1 perspective, I think we've done our job.

TM1 is quite different from a traditional programming project, where developers work directly with files and Git tracks those file changes. In TM1, the objects live inside a running multidimensional database and are highly interconnected, so the real challenge is often not just making a selective Git commit, but deciding exactly which TM1 changes should be promoted together.

That is where the SPACE TM1 Lifecycle Manager becomes particularly useful.

You can compare two TM1 environments side by side, see exactly what is different, selectively choose the objects you want to promote, package those changes into a release, review the release and then either deploy them to your target evironment or Publish to Git, without leaving IBM Planning Analytics Workspace.

For me, this is a more natural way to approach "selective commits" in TM1. Instead of starting with Git files and deciding what to stage, you start with the actual TM1 environments, understand the delta, select the required TM1 objects, and let that selection become the release/deployment unit.

Before syncing anything into the target environment, SPACE also provides a preview of the changes, so you can review what will be created, updated or changed before applying the sync.

We also use our own text-based representation of TM1 objects. JSON is excellent as a machine-readable format, but it is not always ideal for Git review - nested structures, ordering and metadata can make relatively small TM1 changes produce noisy diffs. The SPACE format is designed specifically so changes to cubes, dimensions, hierarchies, attributes, views, subsets, processes and chores are easier for a TM1 developer to read and compare in Git.

Another important part is traceability. Everything in SPACE is logged, so the Lifecycle Manager also gives you a clear history of who deployed what, where and when. Combined with Git history, that makes it much easier to understand both the source-control history and the actual TM1 deployment history.

The goal was therefore to keep Git underneath as the source-control mechanism, but make the workflow much more natural for TM1:

Compare environments → select the required changes → create a release → review/preview → Publish or Sync → retain the full deployment history.

That gives users selective source control together with the broader TM1 lifecycle, without requiring every TM1 developer to work directly with Git concepts such as push, pull and merge.

And this is also where SPACE AI becomes particularly interesting. The next step is not simply "AI for Git", but AI-assisted TM1 lifecycle management - for example:

"Show me what changed in DEV since the last production release."

"Which of these changes belong to the new forecasting model?"

"Create a release with everything required for this cube."

"Am I missing any dependent dimensions, subsets or processes?"

"Review this release and tell me what could be risky before I deploy it."

"Who deployed this object, when, and what changed?"

So instead of AI trying to understand Git files in isolation, it can work with the TM1 environment comparison, object relationships, releases, Git history and SPACE deployment logs to help users understand, package and safely promote changes.

The direction we are working towards is:

AI analyzes the TM1 delta → groups related changes → suggests the release → explains dependencies and risks → user reviews → SPACE deploys/syncs → the full action history remains auditable.

Git stays underneath, but the user works at the TM1 lifecycle level.

Exactly. So the remaining piece is really PAW adopting the same source-control model rather than treating Git primarily as an object-movement target.

If that happens, the TM1 selective-push work and the preservation of non-TM1 files should fit together naturally.

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

Hi Ajit,

As I wrote already "I might be rare", I kind of hope I am actually especially as I'm not your typical TM1 developer and the last thing I want to do is trying to advocate that 'ordinary' TM1 developers should start leveraging VSCode for their day to day TM1 development, au-contrair!

And I'm with you, it would be great if PA(W) would 1) embrace the 'TM1 as code' model (for which TM1's GIT integration was created) and, once we have it in TM1, 2) add support for selective push. Selective pull on the other hand... that's not really something that in an "as code" model exist and something, from a source control and CI/CD point of view, be impossible to govern. 

Again, if "TM1 as code", and any CI/CD or other GIT based tooling/testing/pipelining that might go with it, is not for you then TM1's GIT integration might not be what you are looking for (and that's perfectly fine and probably still true for more then 95+% of the TM1 users.

As for SPACE, I'll leave that to Vlad to answer, but it, as per Vlad's response above, is not using TM1's GIT integration or it's standard's based 'source' specification.

Hi Hubert,

Thanks for sharing your notes.

I have also used VS Code to leverage Git features such as version control. However, from a TM1 developer's perspective, using Git through VS Code can be a relatively lengthy process, as TM1 developers may not regularly work with VS Code or Git commands.

It would be very helpful if we could perform full or selective Push/Pull operations directly from PAW. This would make Git integration much more user-friendly and efficient for TM1 developers.

Regarding SPACE, I am not yet familiar with how we can utilize it or what its specific purpose is in this context. It would be helpful if you could provide some guidance or additional information on how SPACE could support this workflow.

Thanks,
Ajit

I don't mind you plugging SPACE every so often, Vlad ;-), and I'm sure there are as many different ways people want to do things, have different needs for ultimately the same capabilities and, perhaps most importantly, their own preferences as to how and with what they want to do them. And I get it, SPACE serves one of those ways nicely and without ever leaving PA.

Thing is, I'm first and foremost a TM1-er, and there are many different kinds of TM1-ers out there - I'm probably of the more exotic kind (read: I might be rare ;-)). I'm one of those that would happily live in VSCode, never touch a modelling UI, and build an entire model from code and use the occasional transient TI process.

PA is obviously the prime, and by far the most important, consumer of TM1, but PA isn't TM1. My job is to make sure TM1 provides the capabilities for PA, SPACE, and other tools, CI/CD pipeline, as well as that slightly odd developer living in VSCode to build whatever workflow works for them.

So yes, what you're describing with SPACE is a perfectly valid workflow on top of this. I'm just looking at it one level lower.

For me the native TM1 Git integration should make TM1 a proper participant in Git source control. tm1project.json defines what constitutes the project; pull lets me build/update TM1 from that source; push lets me commit changes made in TM1 back to it; and selective push should allow a client to decide what belongs in a particular commit without disturbing everything else in the repository.

What happens on top of that is deliberately somebody else's choice. We all know the experience PAW put around it, SPACE may use it to provide a complete lifecycle experience (do you - or did you roll your own source definition?), somebody else may build something entirely different and I may just sit in VSCode and use any and all GIT tooling at my disposal and use the occasional call to the REST API.

If we've made the Git integration sufficiently clean and complete that all of those are possible, then, from a TM1 perspective, I think we've done our job.

TM1 is quite different from a traditional programming project, where developers work directly with files and Git tracks those file changes. In TM1, the objects live inside a running multidimensional database and are highly interconnected, so the real challenge is often not just making a selective Git commit, but deciding exactly which TM1 changes should be promoted together.

That is where the SPACE TM1 Lifecycle Manager becomes particularly useful.

You can compare two TM1 environments side by side, see exactly what is different, selectively choose the objects you want to promote, package those changes into a release, review the release and then either deploy them to your target evironment or Publish to Git, without leaving IBM Planning Analytics Workspace.

For me, this is a more natural way to approach "selective commits" in TM1. Instead of starting with Git files and deciding what to stage, you start with the actual TM1 environments, understand the delta, select the required TM1 objects, and let that selection become the release/deployment unit.

Before syncing anything into the target environment, SPACE also provides a preview of the changes, so you can review what will be created, updated or changed before applying the sync.

We also use our own text-based representation of TM1 objects. JSON is excellent as a machine-readable format, but it is not always ideal for Git review - nested structures, ordering and metadata can make relatively small TM1 changes produce noisy diffs. The SPACE format is designed specifically so changes to cubes, dimensions, hierarchies, attributes, views, subsets, processes and chores are easier for a TM1 developer to read and compare in Git.

Another important part is traceability. Everything in SPACE is logged, so the Lifecycle Manager also gives you a clear history of who deployed what, where and when. Combined with Git history, that makes it much easier to understand both the source-control history and the actual TM1 deployment history.

The goal was therefore to keep Git underneath as the source-control mechanism, but make the workflow much more natural for TM1:

Compare environments → select the required changes → create a release → review/preview → Publish or Sync → retain the full deployment history.

That gives users selective source control together with the broader TM1 lifecycle, without requiring every TM1 developer to work directly with Git concepts such as push, pull and merge.

And this is also where SPACE AI becomes particularly interesting. The next step is not simply "AI for Git", but AI-assisted TM1 lifecycle management - for example:

"Show me what changed in DEV since the last production release."

"Which of these changes belong to the new forecasting model?"

"Create a release with everything required for this cube."

"Am I missing any dependent dimensions, subsets or processes?"

"Review this release and tell me what could be risky before I deploy it."

"Who deployed this object, when, and what changed?"

So instead of AI trying to understand Git files in isolation, it can work with the TM1 environment comparison, object relationships, releases, Git history and SPACE deployment logs to help users understand, package and safely promote changes.

The direction we are working towards is:

AI analyzes the TM1 delta → groups related changes → suggests the release → explains dependencies and risks → user reviews → SPACE deploys/syncs → the full action history remains auditable.

Git stays underneath, but the user works at the TM1 lifecycle level.

Exactly. So the remaining piece is really PAW adopting the same source-control model rather than treating Git primarily as an object-movement target.

If that happens, the TM1 selective-push work and the preservation of non-TM1 files should fit together naturally.

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,

@Hubert Heijkers - Do you know if there has been any more focus on the TM1 git operations respecting native git functionality i.e. .gitignore and .github directories?  With more and more focus on building/deploying/maintaining TM1 as code, hoping a solution can be found as it's onerous to re-deploy those files manually on each push back to github.  I believe I heard there was something on the roadmap coming for v12 at some point, but not sure if there is any committed timeframes.

Hi Ajit,

As I wrote already "I might be rare", I kind of hope I am actually especially as I'm not your typical TM1 developer and the last thing I want to do is trying to advocate that 'ordinary' TM1 developers should start leveraging VSCode for their day to day TM1 development, au-contrair!

And I'm with you, it would be great if PA(W) would 1) embrace the 'TM1 as code' model (for which TM1's GIT integration was created) and, once we have it in TM1, 2) add support for selective push. Selective pull on the other hand... that's not really something that in an "as code" model exist and something, from a source control and CI/CD point of view, be impossible to govern. 

Again, if "TM1 as code", and any CI/CD or other GIT based tooling/testing/pipelining that might go with it, is not for you then TM1's GIT integration might not be what you are looking for (and that's perfectly fine and probably still true for more then 95+% of the TM1 users.

As for SPACE, I'll leave that to Vlad to answer, but it, as per Vlad's response above, is not using TM1's GIT integration or it's standard's based 'source' specification.

Hi Hubert,

Thanks for sharing your notes.

I have also used VS Code to leverage Git features such as version control. However, from a TM1 developer's perspective, using Git through VS Code can be a relatively lengthy process, as TM1 developers may not regularly work with VS Code or Git commands.

It would be very helpful if we could perform full or selective Push/Pull operations directly from PAW. This would make Git integration much more user-friendly and efficient for TM1 developers.

Regarding SPACE, I am not yet familiar with how we can utilize it or what its specific purpose is in this context. It would be helpful if you could provide some guidance or additional information on how SPACE could support this workflow.

Thanks,
Ajit

I don't mind you plugging SPACE every so often, Vlad ;-), and I'm sure there are as many different ways people want to do things, have different needs for ultimately the same capabilities and, perhaps most importantly, their own preferences as to how and with what they want to do them. And I get it, SPACE serves one of those ways nicely and without ever leaving PA.

Thing is, I'm first and foremost a TM1-er, and there are many different kinds of TM1-ers out there - I'm probably of the more exotic kind (read: I might be rare ;-)). I'm one of those that would happily live in VSCode, never touch a modelling UI, and build an entire model from code and use the occasional transient TI process.

PA is obviously the prime, and by far the most important, consumer of TM1, but PA isn't TM1. My job is to make sure TM1 provides the capabilities for PA, SPACE, and other tools, CI/CD pipeline, as well as that slightly odd developer living in VSCode to build whatever workflow works for them.

So yes, what you're describing with SPACE is a perfectly valid workflow on top of this. I'm just looking at it one level lower.

For me the native TM1 Git integration should make TM1 a proper participant in Git source control. tm1project.json defines what constitutes the project; pull lets me build/update TM1 from that source; push lets me commit changes made in TM1 back to it; and selective push should allow a client to decide what belongs in a particular commit without disturbing everything else in the repository.

What happens on top of that is deliberately somebody else's choice. We all know the experience PAW put around it, SPACE may use it to provide a complete lifecycle experience (do you - or did you roll your own source definition?), somebody else may build something entirely different and I may just sit in VSCode and use any and all GIT tooling at my disposal and use the occasional call to the REST API.

If we've made the Git integration sufficiently clean and complete that all of those are possible, then, from a TM1 perspective, I think we've done our job.

TM1 is quite different from a traditional programming project, where developers work directly with files and Git tracks those file changes. In TM1, the objects live inside a running multidimensional database and are highly interconnected, so the real challenge is often not just making a selective Git commit, but deciding exactly which TM1 changes should be promoted together.

That is where the SPACE TM1 Lifecycle Manager becomes particularly useful.

You can compare two TM1 environments side by side, see exactly what is different, selectively choose the objects you want to promote, package those changes into a release, review the release and then either deploy them to your target evironment or Publish to Git, without leaving IBM Planning Analytics Workspace.

For me, this is a more natural way to approach "selective commits" in TM1. Instead of starting with Git files and deciding what to stage, you start with the actual TM1 environments, understand the delta, select the required TM1 objects, and let that selection become the release/deployment unit.

Before syncing anything into the target environment, SPACE also provides a preview of the changes, so you can review what will be created, updated or changed before applying the sync.

We also use our own text-based representation of TM1 objects. JSON is excellent as a machine-readable format, but it is not always ideal for Git review - nested structures, ordering and metadata can make relatively small TM1 changes produce noisy diffs. The SPACE format is designed specifically so changes to cubes, dimensions, hierarchies, attributes, views, subsets, processes and chores are easier for a TM1 developer to read and compare in Git.

Another important part is traceability. Everything in SPACE is logged, so the Lifecycle Manager also gives you a clear history of who deployed what, where and when. Combined with Git history, that makes it much easier to understand both the source-control history and the actual TM1 deployment history.

The goal was therefore to keep Git underneath as the source-control mechanism, but make the workflow much more natural for TM1:

Compare environments → select the required changes → create a release → review/preview → Publish or Sync → retain the full deployment history.

That gives users selective source control together with the broader TM1 lifecycle, without requiring every TM1 developer to work directly with Git concepts such as push, pull and merge.

And this is also where SPACE AI becomes particularly interesting. The next step is not simply "AI for Git", but AI-assisted TM1 lifecycle management - for example:

"Show me what changed in DEV since the last production release."

"Which of these changes belong to the new forecasting model?"

"Create a release with everything required for this cube."

"Am I missing any dependent dimensions, subsets or processes?"

"Review this release and tell me what could be risky before I deploy it."

"Who deployed this object, when, and what changed?"

So instead of AI trying to understand Git files in isolation, it can work with the TM1 environment comparison, object relationships, releases, Git history and SPACE deployment logs to help users understand, package and safely promote changes.

The direction we are working towards is:

AI analyzes the TM1 delta → groups related changes → suggests the release → explains dependencies and risks → user reviews → SPACE deploys/syncs → the full action history remains auditable.

Git stays underneath, but the user works at the TM1 lifecycle level.

Exactly. So the remaining piece is really PAW adopting the same source-control model rather than treating Git primarily as an object-movement target.

If that happens, the TM1 selective-push work and the preservation of non-TM1 files should fit together naturally.

IF, and mentioning this only as this started out as a "with PAW" topic, PAW decides to start supporting "source control" thinking and not sticks with "object movement" as they do today. Only good news presumably, since the tm1project file would still not control files that "TM1 does not own" as you say, those would remain either way.

Thanks Hubert - that is exactly the behaviour that was missing.

Selective push as a real commit of a subset, with the rest of the tree left alone - including files that TM1 does not own - is what turns this from object transport into source control.

But obviously Vitalij, you know me long enough to know that;-!

Think of 'selective push' as you having a bunch of files changed in a Git repo but you are only adding a subset of those changed files to your commit whilst everything else keeps unchanged (your other changes you did locally remain whilst your repo only gets updated with what you put in the commit).

The tm1project (.json) file continues to drive what's included (and remains) whilst selective push will allow you to push (read: commit) only a part the changes you might have done without impacting anything else.

The other thing we are trying to tackle, next to selective push, is you being allowed to have files in your repo that are not of interest to TM1 itself (for example, github action definitions, a .vscode folder for your favorite editor, perhaps even some doc content for your static web site for the database etc.) which would leave untouched as well (currently a push from TM1 results in those being removed, very annoying I found out the hard way as well;-). 

Thanks for the update, Hubert.

Good to know that selective push is still actively being worked on. The distinction between selective object movement and actual Git-based source control is important here.

I think the interesting question for 12.7 will therefore be whether selective push also preserves the existing Git tree/branch state and creates a delta against it, rather than simply reducing the set of objects being pushed.

That would be the point where the integration starts behaving more like actual source control rather than object transport via Git.

Just letting you know selective push in TM1 is still being actively worked on and therefore did not make it into TM1 v12.6. Hopefully 12.7, fingers crossed ;-)

Hubert's distinction is the one that matters for Ajit's case.

If the branch is treated as "whatever PAW just pushed," then pushing 2 of 10 TIs should leave 8 files behind. Git already works that way. Replacing the branch contents with the selected objects is snapshot/promote behaviour, not a commit.

Selective push in 12.6 may shrink the set you send. It does not fix the model if unselected, already-tracked files are still dropped. The test is simple: after a push of two changed processes, do the other eight blobs still have their previous commits on that branch?

Until the integration commits a delta against the existing tree, this stays a packaged object move that happens to use Git as the transport. Fine for promote. Not source control - and on v11 it will stay that way even after 12.6.

Hi Roman,

It's for v12 only. PAW should be able to pick it up quickly, but no version yet.

Best regards,

Hi Svetlana,

Is that tied to v11 or v12 only?  Any expectation on the PAW version as well?

Hi Ajit,

Expecting 12.6 or later,

Best regards,

Hi Svetlana,

Thanks for the update.

Could you please share the expected timeline for this? Also, in which version will this enhancement be supported?

Thanks,
Ajit

Hi Ajit,

You are correct.

You can either push all to keep everything in Git but you cannot select some of changes in given objects.

Any changes to any objects would be pushed, or push selected objects but the rest won't be in Git.

We have plans to implement selective push later this year.

Best regards,