Let's say you have two seperate IFC files in one git repository.. Is it possible to cherry pick one commit to the other branch and will it update the IFC?
@Coen there is some documentation but this is all generic concepts and doesn't go into detail about buttons etc..
Basically, the 'working branch' tells you what branch you have open in blenderbim.
The list of revisions is a browser that you can use to explore branches and their revisions, but your model open in blenderbim stays the same unless you switch revision (the ? button), or merge branches (the ⚗️ button below that).
The solid diamond ? (and [HEAD] prefix) on a list item tells you which revision from this branch is open in blenderbim.
If you 'switch' to the top (most recent) revision of a branch then the BlenderBIM model changes accordingly, and your 'working branch' is now this branch. Edit and commit and you are extending this branch.
If you switch to any other revision (ie not at the top), then you have what Git calls a 'detached HEAD'. Edit and commit and you are forced to create a new branch. Currently this is the only way to create a branch in blenderbim since I'm trying to avoid adding too many buttons.
Please do ask questions, although I have been using git since forever, I never really understood it. I'm not sure I entirely understand it now, but I do know it is really weird.
@Coen said:
Let's say you have two seperate IFC files in one git repository.. Is it possible to cherry pick one commit to the other branch and will it update the IFC?
I'm not sure what you mean. You can have two unrelated IFC files in a single repository, their history is tracked separately but there is no mechanism other than blender copy/paste for moving stuff between them.
Otherwise, in Git a revision is a snapshot of the data, a three-way-merge looks at differences between the branches you are merging, against the fork point when they split. There is no way I can think-of to isolate a single change, as it may depend on the previous changes going all the way back to the fork.
@Coen said: @brunopostle Thanks for the answer, is it possible to create a branch through the Blender UI? Or do I need the terminal to create a branch?
Just switch to an earlier version and when you next commit you have to give it a branch name.
If you want to branch from the latest model, save it again, commit this (empty) change, and the point you wanted to branch from is no longer the latest revision.
Think of it as a superhero movie, if you go back in time and start changing history you are creating a new parallel universe with an alternate timeline (a branch).
Now BlenderBIM has a safety feature, when you change stuff in the past (commit a new revision on top of an older revision), you also have to give the branch a name or discard the change.
If you do accidentally create a branch and make changes in the past that should really have happened in the present day, you don't need Spiderman to find a mcguffin to restore order to the multiverse. Just switch back to the present day (the HEAD of the main branch), pick your forked universe (the branch you created) in the browser and click the 'merge' button.
That was a very wholesome explanation of git history :p
That gave me the urge to test out how chatGPT would explain git branches and forks as a stand-up comedian. Idk why it went rambling about television shows but I think it was funny.
Hey, hey, everybody! How you all doing tonight? Give it up for version control, am I right? Yeah! So, let me tell you about these two crazy things in the world of Git: branches and forks. It's like a sitcom up in here!
Alright, so imagine you're working on a project, and you're like, "I got all these cool ideas, but I don't wanna mess up the main code, you know? I gotta keep it clean." Well, that's where branches come in. It's like having your own little parallel universe of code. You can create a branch and start working on your ideas without affecting the main code. It's like a separate room in the code mansion. You can make changes, experiment, and if things go south, you just close the door and go back to the main party. No harm done! It's like having a safety net for your creativity.
But wait, there's more! Git branches are like a sitcom crossover episode. You can merge them back into the main code. It's like two storylines colliding, and you gotta make sure they play nice. If everything goes well, you get this epic moment where your changes become part of the main codebase. It's like your own little contribution to the show. And everyone claps, and you feel like a coding superstar. Yeah!
Now, let's talk about forks. Forks are like the rebellious cousin of branches. It's when you take the whole codebase and say, "I'm gonna do my own thing, baby!" It's like starting your own party from scratch. You take the code, make your own changes, and you're like, "This is MY version now." You become the master of your own destiny, just like in those reality TV shows.
But here's the twist: forks can actually be a good thing. They're like the rock stars who go solo but end up creating something amazing. You can take someone else's project, fork it, and make it your own. You add your own flavor, your own ideas, and if it turns out awesome, you can even contribute back to the original project. It's like saying, "Hey, I made something cool with your creation, and I want to share it with the world." It's like a remix that becomes a hit song. Everybody wins!
So, my friends, that's Git branches and forks for you. It's like having your own little code adventures, making changes, merging back, and even going off to start your own coding revolution. It's like a comedy show with twists and turns. Git, my friends, it's the sitcom of version control. Thank you, and goodnight!
I apoligize in advance for idiotic questions, but I am struggling to understand.
What I have done.
1) Initilized a git repo with ony one ifc file in the git repo, it gives me a master branch. Started a project, modelled two walls and saved it
2) Opened the folder/git repo in VS code to create a branch called adjust-wall-width and then set the wall width from 100 to 200mm
3) clicked the pencil button which says: Switches the repository to the selected revision and reloads the IFC file. As which I understand it does a git checkout so you're working in the branch you want to work in? Gave a concise commit message and pressed enter, after enter the Commit changes button ungreyed and I could press commit.
4) I see the latest commit message in the Blender UI
Now I wanted to go back to the master and switch between the branches, I have to select from the dropdown and click the pencil icon?
It works, but my question is.
Am I using the tool as intended?
Now I want to merge my branch adjust-wall-width into master.
But the button is still grey
@Coen this seems like a reasonable workflow, you can do git operations in visual studio and blenderbim should update fine.
The merge button is greyed-out because you are missing the ifcmerge mcguffin. download ifcmerge.exe here, you don't need to follow the instructions on that page, just put it in your PATH for BlenderBIM to find it.
Yes you should be able to merge a wall that has a layerset width modification in one branch and a pset in another. It will choke if you have modified the same attribute in both because it doesn't know which you prefer - in this case it will tell you the id of the offending element and you will need to find it and resolve the problem before merging again.
I've added the ifcmerge folder with the exectuable in it
The BlenderBIM add-on found the ifcmerge tool, because the button is not greyed out anymore:
Now the button says: Merges the selected branch into working branch
Now I made the added pset wall properties branch the active branch, I am a bit confused on how to merge the branch back to master. How do I know which branch is which?
I have it set like this
After clicking the merge button I get this message:
@Coen I fixed this one a couple.of days ago, so it won't do this if you install the latest BlenderBIM.
..but it is only a message saying that ifcmerge didn't have anything to do. Either you were merging a branch into itself, or you were merging a branch that was a direct descendant of another (ie. not a fork, but this is a valid use case anyway).
In general you stay in the 'working branch' after the merge, but you will see that the commit list for the working branch now has new entries for each of the merged revisions, and one for the merge itself.
Thanks for your answer, I am always pulling the latest ifcopenshell release from Githhub
I merged my adjust-wall-width branch back with the just the out of the box merge command from git.
However I made changes in my master branch. I added a window. It gave a merge conflict which I resolved by clicking away in VS code, then obviously my IFC was not there anymore, it wouldn't load into BlenderBIM because it was missing all kind of IFC relations.
I am going to try a second attempt with a clean repository.
How is ifcmerge different from the standard git merge? I was looking at the code in ifcmerge. Absolutely clueless on what's happening there exactly.
Would it be useful to add the git log history as an IfcPropertySet to the IFC when it's being 'released'. In other words. Ready for construction.
I found this SO post, where the command: git log --pretty="%C(Yellow)%h %C(reset)%ad (%C(Green)%cr%C(reset))%x09 %C(Cyan)%an: %C(reset)%s" --date=short -7
outputs:
@Coen A standard git merge always fails with forked IFC files because at the very least the FILE_NAME header line will be modified in both branches, even if nothing else has changed.
At this point Git throws you into a conflict resolution mode, marking up the file with lines from both versions (this marked up file definitely won't load in BlenderBIM).
You can resolve this by manually editing the file (and running git merge --continue), or you can run a mergetool that does a three-way merge. Ifcmerge is a mergetool specific to IFC files.
BlenderBIM has logic to deal with this IFC merging thing that visual studio doesn't have. You can use visual studio to do non merge functions, tagging, branching remote operations, visualising branch trees etc..
@Coen yes we could add a commit log to the IFC file, but this would be another commit, so it would immediately be out-of-date.
My plan was to make the Git tags available for insertion into drawing boxes as a revision list, this gives the author some control over what is visible to recipients.
Is it possible to create a git branch from the Blender UI? I thought there was a button in the standalone version, but with the integration in the BlenderBIM add-on I don't see the create branch menu anymore
@brunopostle said:
It will choke if you have modified the same attribute in both because it doesn't know which you prefer
This is quite an important sentence, I managed to get the ifc merge work each time as long as I don't start working in two branches back and forth. However now I am in search of a good workflow with git branching. Modelling a building is somewhat a different process than writing software. Feature branching workflow works, but I think a different type of workflow would better fit this certain scenarios. still an extremely useful tool when collaborating with other on a remote git server I would think. And I haven't tried reverting back to old commits yet, also really useful when you have done an oopsie.
I think @theoryshaw and @bruno_perdigao have experience with collaborating with this tool on a remote git sever, just curious to their experiences and if they have any insightful thoughts for workflows which worked for them.
@brunopostle
I asked chatGPT what the Perl script exactly does in ifcmerge-2022-06-20. Just out of curiosity, why was it written in Perl?
The code you provided appears to be a Perl script named ifcmerge. It seems to be a script for merging IFC (Industry Foundation Classes) files. Here's a breakdown of what the script does:
The script starts by defining the necessary modules and packages it will use.
It checks the command-line arguments to ensure that the script is executed with the correct number of arguments. It expects four arguments: base.ifc, local.ifc, remote.ifc, and merged.ifc.
It initializes the necessary objects for base, local, remote, and merged IFC files using the Ifc class.
The load method is used to read and load the contents of each IFC file into the corresponding object.
The script compares the local and remote files against the base file to identify added, modified, and deleted entities.
If both local and remote files have added entities, the script renumbers the local added entities to create space for them.
The script copies added entities from both local and remote files to the merged file.
Deleted entities from both local and remote files are removed from the merged file, unless they have been modified in the other file, in which case an error message is added to the @errors array.
Modified entities are updated in the merged file. If an entity has been modified in both local and remote files, the script attempts to merge the attributes. If conflicts arise, an error message is added to the @errors array.
If any errors occurred during the merging process, the script terminates and prints the errors.
If the merging process is successful, the write method is used to write the merged content to the merged.ifc file.
The script ends with a successful exit status.
Please note that this is just an overview of the script's functionality, and further analysis may be required to fully understand its behavior and the specific requirements of the IFC files it processes.
@Coen reconnecting the history when merging wasn't properly working until a few days ago due to a bug in GitPython. I think @theoryshaw and @bruno_perdigao found that they needed to coordinate work to avoid having to merge.
Merging, when it works, works very well, but there is a curious asymmetry in the process (because it is fundamentally a conflict resolution rather than a simple merge). There may have to be two merge buttons that appear to do the same thing, but which do slightly different stuff under the hood. Either that or there will need to be different behaviour if you are on a 'main' branch, or merging from a remote 'origin/main' branch vs any other branch.
Would it be possible to imagine similarly to how it's done in IDEs when merging two branches of a program, when appropriate, to display only the two elements that have a conflict in the 3D viewport (maybe using different colors ?), and query the user to choose which version they want to keep and which version they want to discard (or keep both). Iteratively for each conflict, until all conflicts have been resolved.
Or more realistically a UI list of all conflicts with the name of the conflictual element and the property that is overwritten, with 3 buttons : keep incoming, discard incoming, keep both (when applicable) ?
@Gorgious at the moment ifcmerge reports a list of conflicts with the step ids (and the index of any conflicting attributes), this appears in a blender pop-up error message which vanishes as soon as you move the mouse.
This could be used to highlight the conflicting elements, though if the conflict is in a non-rooted element there would be nothing to see.
It would be easy enough to modify ifcmerge so that a conflicting attribute is always resolved in favour of one or the other version. This would result in orphaned data in the IFC, probably not a big deal as purging orphaned data seems like a core feature for BlenderBIM.
It's actually quite difficult to generate a genuine merge conflict, you really have to try, IFC is considerably more structured than programming languages so we can merge things that wouldn't be possible with source code.
What does generate unresolvable conflicts is that the merge resolution necessarily rewrites step IDs of conflicting entities in one or other of the two branches, so breaking the Native IFC principle that step IDs never change. This is fine if that branch is going to be discarded, but if you inadvertently carry on working on an older revision within that branch it won't be mergeable.
Comments
Let's say you have two seperate IFC files in one git repository.. Is it possible to cherry pick one commit to the other branch and will it update the IFC?
@Coen there is some documentation but this is all generic concepts and doesn't go into detail about buttons etc..
Basically, the 'working branch' tells you what branch you have open in blenderbim.
The list of revisions is a browser that you can use to explore branches and their revisions, but your model open in blenderbim stays the same unless you switch revision (the ? button), or merge branches (the ⚗️ button below that).
The solid diamond ? (and [HEAD] prefix) on a list item tells you which revision from this branch is open in blenderbim.
If you 'switch' to the top (most recent) revision of a branch then the BlenderBIM model changes accordingly, and your 'working branch' is now this branch. Edit and commit and you are extending this branch.
If you switch to any other revision (ie not at the top), then you have what Git calls a 'detached HEAD'. Edit and commit and you are forced to create a new branch. Currently this is the only way to create a branch in blenderbim since I'm trying to avoid adding too many buttons.
Please do ask questions, although I have been using git since forever, I never really understood it. I'm not sure I entirely understand it now, but I do know it is really weird.
I'm not sure what you mean. You can have two unrelated IFC files in a single repository, their history is tracked separately but there is no mechanism other than blender copy/paste for moving stuff between them.
Otherwise, in Git a revision is a snapshot of the data, a three-way-merge looks at differences between the branches you are merging, against the fork point when they split. There is no way I can think-of to isolate a single change, as it may depend on the previous changes going all the way back to the fork.
@brunopostle Thanks for the answer, is it possible to create a branch through the Blender UI? Or do I need the terminal to create a branch?
Just switch to an earlier version and when you next commit you have to give it a branch name.
If you want to branch from the latest model, save it again, commit this (empty) change, and the point you wanted to branch from is no longer the latest revision.
You mean give the git command in the commit message in the Blender UI?
Think of it as a superhero movie, if you go back in time and start changing history you are creating a new parallel universe with an alternate timeline (a branch).
Now BlenderBIM has a safety feature, when you change stuff in the past (commit a new revision on top of an older revision), you also have to give the branch a name or discard the change.
If you do accidentally create a branch and make changes in the past that should really have happened in the present day, you don't need Spiderman to find a mcguffin to restore order to the multiverse. Just switch back to the present day (the HEAD of the main branch), pick your forked universe (the branch you created) in the browser and click the 'merge' button.
That was a very wholesome explanation of git history :p
That gave me the urge to test out how chatGPT would explain git branches and forks as a stand-up comedian. Idk why it went rambling about television shows but I think it was funny.
Well at least a comedian's job is safe.
I apoligize in advance for idiotic questions, but I am struggling to understand.
What I have done.
1) Initilized a git repo with ony one ifc file in the git repo, it gives me a master branch. Started a project, modelled two walls and saved it
2) Opened the folder/git repo in VS code to create a branch called
adjust-wall-widthand then set the wall width from 100 to 200mm3) clicked the pencil button which says:
Switches the repository to the selected revision and reloads the IFC file. As which I understand it does a git checkout so you're working in the branch you want to work in? Gave a concise commit message and pressed enter, after enter theCommit changesbutton ungreyed and I could press commit.4) I see the latest commit message in the Blender UI
Now I wanted to go back to the master and switch between the branches, I have to select from the dropdown and click the pencil icon?
It works, but my question is.
Am I using the tool as intended?
Now I want to merge my branch
adjust-wall-widthinto master.But the button is still grey
git fork overview to make it visual:
A more concrete (haha pun unintended) example:
I have the
masterbranch with these two walls.The walls are 100mm width and have a Pset_WallCommon Pset.
Now I have the
adjust-wall-widthbranch with these two wallsThe walls are 200mm width and don't have a Pset_WallCommon Pset.
If I merge the
adjust-wall-widthbranch back into themasterbranch.Do I have walls with 200mm width and a Pset_WallCommon Pset?
Or is there a possibly to cherry pick commits and apply them to different branches?
@Coen this seems like a reasonable workflow, you can do git operations in visual studio and blenderbim should update fine.
The merge button is greyed-out because you are missing the ifcmerge mcguffin. download ifcmerge.exe here, you don't need to follow the instructions on that page, just put it in your
PATHfor BlenderBIM to find it.Yes you should be able to merge a wall that has a layerset width modification in one branch and a pset in another. It will choke if you have modified the same attribute in both because it doesn't know which you prefer - in this case it will tell you the id of the offending element and you will need to find it and resolve the problem before merging again.
@brunopostle
which
PATHdo you mean? Environment variable path for Windows?I've added the
ifcmergefolder with the exectuable in itThe BlenderBIM add-on found the ifcmerge tool, because the button is not greyed out anymore:
Now the button says:
Merges the selected branch into working branchNow I made the
added pset wall propertiesbranch the active branch, I am a bit confused on how to merge the branch back to master. How do I know which branch is which?I have it set like this
After clicking the merge button I get this message:
@Coen I fixed this one a couple.of days ago, so it won't do this if you install the latest BlenderBIM.
..but it is only a message saying that ifcmerge didn't have anything to do. Either you were merging a branch into itself, or you were merging a branch that was a direct descendant of another (ie. not a fork, but this is a valid use case anyway).
In general you stay in the 'working branch' after the merge, but you will see that the commit list for the working branch now has new entries for each of the merged revisions, and one for the merge itself.
@brunopostle
Thanks for your answer, I am always pulling the latest ifcopenshell release from Githhub
I merged my
adjust-wall-widthbranch back with the just the out of the box merge command from git.However I made changes in my
masterbranch. I added a window. It gave a merge conflict which I resolved by clicking away in VS code, then obviously my IFC was not there anymore, it wouldn't load into BlenderBIM because it was missing all kind of IFC relations.I am going to try a second attempt with a clean repository.
How is ifcmerge different from the standard git merge? I was looking at the code in
ifcmerge. Absolutely clueless on what's happening there exactly.Feature request:
Would it be useful to add the git log history as an IfcPropertySet to the IFC when it's being 'released'. In other words. Ready for construction.
I found this SO post, where the command:
git log --pretty="%C(Yellow)%h %C(reset)%ad (%C(Green)%cr%C(reset))%x09 %C(Cyan)%an: %C(reset)%s" --date=short -7outputs:
If you could assign this information as an IfcPropertySet the stakeholders involved who don't need git can also see the workflow.
@Coen A standard git merge always fails with forked IFC files because at the very least the
FILE_NAMEheader line will be modified in both branches, even if nothing else has changed.At this point Git throws you into a conflict resolution mode, marking up the file with lines from both versions (this marked up file definitely won't load in BlenderBIM).
You can resolve this by manually editing the file (and running
git merge --continue), or you can run a mergetool that does a three-way merge. Ifcmerge is a mergetool specific to IFC files.BlenderBIM has logic to deal with this IFC merging thing that visual studio doesn't have. You can use visual studio to do non merge functions, tagging, branching remote operations, visualising branch trees etc..
@Coen yes we could add a commit log to the IFC file, but this would be another commit, so it would immediately be out-of-date.
My plan was to make the Git tags available for insertion into drawing boxes as a revision list, this gives the author some control over what is visible to recipients.
@brunopostle
Is it possible to create a git branch from the Blender UI? I thought there was a button in the standalone version, but with the integration in the BlenderBIM add-on I don't see the create branch menu anymore
I am absolutey clueless on how to merge two branches succesfully,
my
masterbranchmy
edit-wall-widthbranchI am on the lastest stable BlenderBIM release,
my git workflow:
I don't understand how to merge my
edit-wall-widthbranch back intomaster. Don't even know where to begin.The merge button says 'merge the selected branch into the working branch' .
Am I right in assuming the working branch is the branch which I have checked out?
How can I understand what is my selected branch?
I am getting an Ifc Merge failed notifcation with no extra info why it failed.
Does someone have a very simple step by step merge tutorial which I could follow?
@Coen a branch gets created whenever you switch to an older revision, edit it, and try to commit.
The working branch is the model that is open in blenderbim. The selected branch is the branch you are browsing in the revision list.
This merge ought to work. I do need to do a more thorough video tutorial, but I'd like to somehow make the UI less of a boggle.
You could also push your test model to a Github repository, and I'll see why the merge isn't working.
@brunopostle
Thanks, the merge worked this time with a a third attempt. I left the master branch alone this time and didn't touch it until the merge.
I'm able to create and merge branches, however git fork shows me this:
Why doesn't git fork show me all the branches I created? I can see the several branches in the termainl
@Coen No idea, once you have merged the branches they both have the same revision at their HEAD, maybe it is simplifying this for you.
On the command-line you can see everything with
git log --graph --branches --remotesThis is quite an important sentence, I managed to get the ifc merge work each time as long as I don't start working in two branches back and forth. However now I am in search of a good workflow with git branching. Modelling a building is somewhat a different process than writing software. Feature branching workflow works, but I think a different type of workflow would better fit this certain scenarios. still an extremely useful tool when collaborating with other on a remote git server I would think. And I haven't tried reverting back to old commits yet, also really useful when you have done an oopsie.
I think @theoryshaw and @bruno_perdigao have experience with collaborating with this tool on a remote git sever, just curious to their experiences and if they have any insightful thoughts for workflows which worked for them.
@brunopostle
I asked chatGPT what the Perl script exactly does in
ifcmerge-2022-06-20. Just out of curiosity, why was it written in Perl?The code you provided appears to be a Perl script named
ifcmerge. It seems to be a script for merging IFC (Industry Foundation Classes) files. Here's a breakdown of what the script does:The script starts by defining the necessary modules and packages it will use.
It checks the command-line arguments to ensure that the script is executed with the correct number of arguments. It expects four arguments:
base.ifc,local.ifc,remote.ifc, andmerged.ifc.It initializes the necessary objects for
base,local,remote, andmergedIFC files using theIfcclass.The
loadmethod is used to read and load the contents of each IFC file into the corresponding object.The script compares the
localandremotefiles against thebasefile to identify added, modified, and deleted entities.If both
localandremotefiles have added entities, the script renumbers the local added entities to create space for them.The script copies added entities from both
localandremotefiles to themergedfile.Deleted entities from both
localandremotefiles are removed from themergedfile, unless they have been modified in the other file, in which case an error message is added to the@errorsarray.Modified entities are updated in the
mergedfile. If an entity has been modified in bothlocalandremotefiles, the script attempts to merge the attributes. If conflicts arise, an error message is added to the@errorsarray.If any errors occurred during the merging process, the script terminates and prints the errors.
If the merging process is successful, the
writemethod is used to write the merged content to themerged.ifcfile.The script ends with a successful exit status.
Please note that this is just an overview of the script's functionality, and further analysis may be required to fully understand its behavior and the specific requirements of the IFC files it processes.
@Coen reconnecting the history when merging wasn't properly working until a few days ago due to a bug in GitPython. I think @theoryshaw and @bruno_perdigao found that they needed to coordinate work to avoid having to merge.
Merging, when it works, works very well, but there is a curious asymmetry in the process (because it is fundamentally a conflict resolution rather than a simple merge). There may have to be two merge buttons that appear to do the same thing, but which do slightly different stuff under the hood. Either that or there will need to be different behaviour if you are on a 'main' branch, or merging from a remote 'origin/main' branch vs any other branch.
Would it be possible to imagine similarly to how it's done in IDEs when merging two branches of a program, when appropriate, to display only the two elements that have a conflict in the 3D viewport (maybe using different colors ?), and query the user to choose which version they want to keep and which version they want to discard (or keep both). Iteratively for each conflict, until all conflicts have been resolved.
Or more realistically a UI list of all conflicts with the name of the conflictual element and the property that is overwritten, with 3 buttons : keep incoming, discard incoming, keep both (when applicable) ?
@Gorgious at the moment ifcmerge reports a list of conflicts with the step ids (and the index of any conflicting attributes), this appears in a blender pop-up error message which vanishes as soon as you move the mouse.
This could be used to highlight the conflicting elements, though if the conflict is in a non-rooted element there would be nothing to see.
It would be easy enough to modify ifcmerge so that a conflicting attribute is always resolved in favour of one or the other version. This would result in orphaned data in the IFC, probably not a big deal as purging orphaned data seems like a core feature for BlenderBIM.
It's actually quite difficult to generate a genuine merge conflict, you really have to try, IFC is considerably more structured than programming languages so we can merge things that wouldn't be possible with source code.
What does generate unresolvable conflicts is that the merge resolution necessarily rewrites step IDs of conflicting entities in one or other of the two branches, so breaking the Native IFC principle that step IDs never change. This is fine if that branch is going to be discarded, but if you inadvertently carry on working on an older revision within that branch it won't be mergeable.