4 ms·

> You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes

> You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you. I'm sure if you were a release manager, or the lead of a sizeable team, or the owner of a busy open source project, you would feel very differently about 'silly' modularised changesets and branching.

m_eiman 12y ago
I don't get this "it makes things easier for a select few, so everyone else just has to suffer an over complicated system" thing. We should make the few suffer instead of the masses; optimize to lower global suffering. It should be possible to build a system that exposes different interfaces to different users, shouldn't it?
- kryptiskt 12y ago
  This guy in the crowd finds it very convenient to be able to commit locally so that you can easily get back to an earlier state of the thing when you fuck up or wants to explore another way to do it. The masses have spoken and they want git.
  - coffeeaddicted 12y ago
    The masses are split with still a slight preference to svn: http://www.ohloh.net/repositories/compare http://www.ohloh.net/repositories/compare (I'm sure there are other statistics out there, but your comment had made me curious and this was the only one I knew of)
    - Zitrax 12y ago
      Would be interesting to compare that to repositories created in the last 2 years or something. It might have quite a different distribution as some old projects probably have kept the vcs they started out with.
- darkFunction 12y ago
  Well it is. You can make branching as complex or as simple as you want. Where I work the developers are only ever exposed to the feature branch they are working on, which is even created automagically for each Jira ticket from the correct release/integration/dev branch. So for a developer it really couldn't be any simpler.
- sanderjd 12y ago
  Modular commits with good messages are analogous to well-written code with good documentation - both are not terribly important (though not harmful either!) for individual contributors but absolutely critical for teams and especially those working at the aggregate team level, like the release managers and team leads your parent mentioned.

m_eiman 12y ago

I don't get this "it makes things easier for a select few, so everyone else just has to suffer an over complicated system" thing. We should make the few suffer instead of the masses; optimize to lower global suffering. It should be possible to build a system that exposes different interfaces to different users, shouldn't it?

kryptiskt 12y ago
This guy in the crowd finds it very convenient to be able to commit locally so that you can easily get back to an earlier state of the thing when you fuck up or wants to explore another way to do it. The masses have spoken and they want git.
- coffeeaddicted 12y ago
  The masses are split with still a slight preference to svn: http://www.ohloh.net/repositories/compare http://www.ohloh.net/repositories/compare (I'm sure there are other statistics out there, but your comment had made me curious and this was the only one I knew of)
  - Zitrax 12y ago
    Would be interesting to compare that to repositories created in the last 2 years or something. It might have quite a different distribution as some old projects probably have kept the vcs they started out with.
darkFunction 12y ago
Well it is. You can make branching as complex or as simple as you want. Where I work the developers are only ever exposed to the feature branch they are working on, which is even created automagically for each Jira ticket from the correct release/integration/dev branch. So for a developer it really couldn't be any simpler.
sanderjd 12y ago
Modular commits with good messages are analogous to well-written code with good documentation - both are not terribly important (though not harmful either!) for individual contributors but absolutely critical for teams and especially those working at the aggregate team level, like the release managers and team leads your parent mentioned.