5 ms·

For one, I try to keep my commits as "atomic units of functionality", not just state snapshots. I often have three or four commits' worth of changes in my worki

For one, I try to keep my commits as "atomic units of functionality", not just state snapshots. I often have three or four commits' worth of changes in my working copy, and sort through them carefully when one is complete to create a commit of only that small piece of functionality.

infogulch 10y ago
Right... now your working copy is just a commit named WIP that sits at the top of the branch and is updated (--amend style) in real time. Wait! let me finish: So now you decide you want to move a part of the delta from WIP into a real commit. So split it and move some of the delta from WIP into the split and rename the split. It's the same workflow!
- JadeNB 10y ago
  But surely "your workflow can be re-implemented in this different interface" is merely an argument that the different interface has not lost power, rather than necessarily that it is as good as (or even better than) the existing interface?
  - infogulch 10y ago
    I'd prefer to phrase it as "this different interface also supports your workflow". Whether the different interface is better or not is completely independent from when it was developed in relation to an existing interface. For example, I find debit cards a much preferable interface to the "pay for things from your bank account" workflow over writing checks, and checks were developed much earlier. :) An interface is only as good as the power it gives you. Recall that power is work/time, so you can increase power by increasing work or decreasing time [1]. It's better if it's easier or faster to use and you can overcome the transition/initial learning costs. I'd guess that the vast majority of typical users of git have to pull up the git man pages (or stackoverflow) to do most of the actions shown in this article, hinting that such an interface may both save time and increase work (users often just not do stuff that they have to research to accomplish). [1]: Ok, I might be stretching the physics analogy a bit. :P
JadeNB 10y ago
> For one, I try to keep my commits as "atomic units of functionality", not just state snapshots. I often have three or four commits' worth of changes in my working copy, and sort through them carefully when one is complete to create a commit of only that small piece of functionality. Given that this is not a universal working model, your explication of your working model, and why it makes the proposed interface not appropriate for you, seems like a much more useful comment than "That… silly. No. That doesn't make any sense at all."

infogulch 10y ago

Right... now your working copy is just a commit named WIP that sits at the top of the branch and is updated (--amend style) in real time. Wait! let me finish: So now you decide you want to move a part of the delta from WIP into a real commit. So split it and move some of the delta from WIP into the split and rename the split. It's the same workflow!

JadeNB 10y ago
But surely "your workflow can be re-implemented in this different interface" is merely an argument that the different interface has not lost power, rather than necessarily that it is as good as (or even better than) the existing interface?
- infogulch 10y ago
  I'd prefer to phrase it as "this different interface also supports your workflow". Whether the different interface is better or not is completely independent from when it was developed in relation to an existing interface. For example, I find debit cards a much preferable interface to the "pay for things from your bank account" workflow over writing checks, and checks were developed much earlier. :) An interface is only as good as the power it gives you. Recall that power is work/time, so you can increase power by increasing work or decreasing time [1]. It's better if it's easier or faster to use and you can overcome the transition/initial learning costs. I'd guess that the vast majority of typical users of git have to pull up the git man pages (or stackoverflow) to do most of the actions shown in this article, hinting that such an interface may both save time and increase work (users often just not do stuff that they have to research to accomplish). [1]: Ok, I might be stretching the physics analogy a bit. :P

JadeNB 10y ago

> For one, I try to keep my commits as "atomic units of functionality", not just state snapshots. I often have three or four commits' worth of changes in my working copy, and sort through them carefully when one is complete to create a commit of only that small piece of functionality. Given that this is not a universal working model, your explication of your working model, and why it makes the proposed interface not appropriate for you, seems like a much more useful comment than "That… silly. No. That doesn't make any sense at all."