|
|
|
|
|
by bob1029
1853 days ago
|
|
This is how I view the handling of the "well what about complex transactions..." game. You can create a totally separate branch to process that complex beast and then attempt to merge it back into the main. If there is a merge conflict (someone debited/credited the account line between branch & merge operation), the transaction would be aborted. Rebasing of transactions on top of the main branch would be possible and the semantics of this even make sense for real world use cases - "We attempted to reconcile your transaction into the main flow, but there was a change in the circumstances of the various basis accounts. Can you rebase your transactions on these circumstances and resubmit?" As part of that rebase operation, you would re-run your biz constraints on the complex transaction and then resubmit if you could still satisfy them all. Depending on how you use and understand git for software, it is either a hauntingly-similar facsimile of any arbitrary blockchain tech today, or a completely alien technology with no practical relationship to blockchain whatsoever. There also seems to be some notion that the time domain must flow in a continuous way. The time domain in git is discrete, but this does not violate any of the semantics. Just hypothetical processes around them. |
|