5 ms·

Saving commits are good for code archeology. Like initial implementation did not work because

by z3t4 6y ago

u801e 6y ago
Those commits do not necessarily need to be in the history. The commit with the working implementation could explain that X alternate solutions were considered but those solutions didn't work with the details of why they didn't work. Of course, that's assuming that those other solutions were tried, tested, and found not to work prior to them getting merged and deployed in production.
- WorldMaker 6y ago
  On the flipside, git is based on a full DAG. There's a lot of power within that data structure to capture a deep, nested understanding of the workflow/process/history/archaeology. Often the issue is not that the DAG can't usefully hold all the alternates and piecemeal sub-solutions, in useful ways that we can come back to and revisit as necessary, but that our visualization tools on top of the DAG aren't great about letting us meaningfully interact with that (showing it when we need it, hiding it when it is noise to the signal we are looking for). (And we have the power to build better defaults for our visualization tools and/or better visualization tools.)
- z3t4 6y ago
  Code is more precise then prose. Someone could say "we already tried X" then you can test it yourself. Repeating an experiment could be as easy as a git checkout.
jefftk 6y ago
Initial versions, and the review comments that led to their abandonment, can be saved in your code review system.
- WorldMaker 6y ago
  What if you need to change code review systems? Do you just abandon all that information? What if your code review system becomes a central point of failure for information that you need about your process/workflow? To use a DVCS in a distributed fashion, doesn't it make more sense to store that data in the DVCS itself?
  - jefftk 6y ago
    > What if you need to change code review systems? Do you just abandon all that information? You choose one of: (a) migrate the data, (b) leave the old system running, (c) archive the data. Same as if you need to change version control systems, or any other important system. > What if your code review system becomes a central point of failure for information that you need about your process/workflow? Could you elaborate? I thought we were talking about needing to answer questions like "what were they thinking when they decided to make a specific change, at a level of detail too fine for the change description?" What would be critical to your workflow, but only available in past review discussions? > To use a DVCS in a distributed fashion, doesn't it make more sense to store that data in the DVCS itself? Nowhere I've worked has used the version control system in a distributed way, beyond someone being able to work while they're on their laptop without wifi.
    - WorldMaker 6y ago
      > Could you elaborate? I thought we were talking about needing to answer questions like "what were they thinking when they decided to make a specific change, at a level of detail too fine for the change description?" What would be critical to your workflow, but only available in past review discussions? Those discussions are an "oral history" of the project. While we may hope for 100% documentation, it isn't uncommon that everything from implicit best practices to "hidden" decision processes to even customer complaints only ever get recorded in code reviews. "Why did we decide to do it this way?" is often the most common question for an archeology dig, and the answer sometimes is critical to a given workflow. If you want to fix the bug without breaking the user scenario that introduced the bug, that can be very important information to have. > Nowhere I've worked has used the version control system in a distributed way, beyond someone being able to work while they're on their laptop without wifi. So? Just because few do it today or think they "need" to do it other than what they believe to be rare offline scenarios, implies it isn't work striving for more distributed systems as an ideal?

Saving commits are good for code archeology. Like initial implementation did not work because

by z3t4 6y ago

Saving commits are good for code archeology. Like initial implementation did not work because

Those commits do not necessarily need to be in the history. The commit with the working implementation could explain that X alternate solutions were considered but those solutions didn't work with the details of why they didn't work. Of course, that's assuming that those other solutions were tried, tested, and found not to work prior to them getting merged and deployed in production.

WorldMaker 6y ago
On the flipside, git is based on a full DAG. There's a lot of power within that data structure to capture a deep, nested understanding of the workflow/process/history/archaeology. Often the issue is not that the DAG can't usefully hold all the alternates and piecemeal sub-solutions, in useful ways that we can come back to and revisit as necessary, but that our visualization tools on top of the DAG aren't great about letting us meaningfully interact with that (showing it when we need it, hiding it when it is noise to the signal we are looking for). (And we have the power to build better defaults for our visualization tools and/or better visualization tools.)
z3t4 6y ago
Code is more precise then prose. Someone could say "we already tried X" then you can test it yourself. Repeating an experiment could be as easy as a git checkout.

jefftk 6y ago

Initial versions, and the review comments that led to their abandonment, can be saved in your code review system.

WorldMaker 6y ago
What if you need to change code review systems? Do you just abandon all that information? What if your code review system becomes a central point of failure for information that you need about your process/workflow? To use a DVCS in a distributed fashion, doesn't it make more sense to store that data in the DVCS itself?
- jefftk 6y ago
  > What if you need to change code review systems? Do you just abandon all that information? You choose one of: (a) migrate the data, (b) leave the old system running, (c) archive the data. Same as if you need to change version control systems, or any other important system. > What if your code review system becomes a central point of failure for information that you need about your process/workflow? Could you elaborate? I thought we were talking about needing to answer questions like "what were they thinking when they decided to make a specific change, at a level of detail too fine for the change description?" What would be critical to your workflow, but only available in past review discussions? > To use a DVCS in a distributed fashion, doesn't it make more sense to store that data in the DVCS itself? Nowhere I've worked has used the version control system in a distributed way, beyond someone being able to work while they're on their laptop without wifi.
  - WorldMaker 6y ago
    > Could you elaborate? I thought we were talking about needing to answer questions like "what were they thinking when they decided to make a specific change, at a level of detail too fine for the change description?" What would be critical to your workflow, but only available in past review discussions? Those discussions are an "oral history" of the project. While we may hope for 100% documentation, it isn't uncommon that everything from implicit best practices to "hidden" decision processes to even customer complaints only ever get recorded in code reviews. "Why did we decide to do it this way?" is often the most common question for an archeology dig, and the answer sometimes is critical to a given workflow. If you want to fix the bug without breaking the user scenario that introduced the bug, that can be very important information to have. > Nowhere I've worked has used the version control system in a distributed way, beyond someone being able to work while they're on their laptop without wifi. So? Just because few do it today or think they "need" to do it other than what they believe to be rare offline scenarios, implies it isn't work striving for more distributed systems as an ideal?