3 ms·

How about, no? The day you realize the tools you use are not the most important part of your function is the day you finally understand what it is you do. Yes,

How about, no? The day you realize the tools you use are not the most important part of your function is the day you finally understand what it is you do. Yes, tools can make things easier, run more smoothly, or make you happy but... Can you do the same, if not better, job with alternate, less efficient tools? Yes. Tool elitism is no better than language elitism. Now, I'll be in the corner using notepad and copying my file every time I make a major change. ;)

dexen 16y ago
You are mistaking the tools you use for the tools that a team can use. That's Git: it lets teammates communicate changes in a straightforward, consistent manner, with little overhead. With a tool suite to review, pull en mass or cherry-pick the changes at will; with the defaults being the most practical choices most of the time. If you want your team to be more than a sum of the members (as opposed to stepping on each others' toes), you need decent communication tool. Or you can dispose of communication by being a lone wolf.
- abyssknight 16y ago
  Just to play devil's advocate here, and definitely not disagreeing with you, but... Do you know how we communicated changes before git and other team tools? With our voices, markers, and boards. If your team steps on each other's toes, might that not be a problem with the team dynamics and not necessarily the tools themselves?
  - danssig 16y ago
    The easier you make things for people the less likely they are to mess it up. We used to get around by horse and buggy but I think you'd agree that a change in tools has been a benefit that lets us do things we couldn't do before, wouldn't because it was too hard or tried to do but failed often from the same mistakes over and over.
  - dexen 16y ago
    Those are not the changes you are looking for :-) You are absolutely right about the way to propagate changes in ideas, prerequisites, protocols etc. etc.. Actually, I'm a frequent whiteboard user myself. I should've made myself clear I was meaning the physical changes to the implementation files; in any case, something that is byproduct of information shared verbally.
mduerksen 16y ago
> Can you do the same, if not better, job with alternate, less efficient tools? The question is: Is a tool just 10% more efficient or does it introduce a whole new quality of working with it? What do you do when your already delivered software has a bug that needs to be fixed urgently, but you already started to add new features that are not ready yet? Using branches with svn is a thing just everyone is scared of (and rightly so), but with git, this has lost it's horror. You can confidently handle the above situation with git. That's a new quality.
- nupark 16y ago
  I don't understand the branching mantra that I hear from git proponents. Subversion has had merge tracking since 1.5, and with it, branching and method is as painless as it can reasonably be. Unless you want to work on a submarine, or have an organizational need for people to maintain private unpublished branches (eg, open source), I don't really see what advantages git has to offer over subversion in organizational (read: corporate) development.
  - mduerksen 16y ago
    Well, in my case it's not a submarine, but a train. And yes, it is great advantage that I can freely make a branch with the new feature that I just started working on, without having to summon a meeting to let everyone know that a new branch will be created, which is not intended to be used by anyone else even if it's visible to everyone.
    - nupark 16y ago
      I don't follow. Isn't needing a meeting to create a branch an organizational problem, not a technical one? As for working offline, my choice of the submarine example was intentional. 10 years ago I used cvsup (and later, svk) to work on the train and plane while using cvs and svn. That mode of working predates git quite a bit, but it's also much less useful nowadays -- Now I just use phone tethering and inflight wifi. I'd be working less efficiently without Internet resources at hand, so now that wireless technology has caught up, I don't have to.

dexen 16y ago

You are mistaking the tools you use for the tools that a team can use. That's Git: it lets teammates communicate changes in a straightforward, consistent manner, with little overhead. With a tool suite to review, pull en mass or cherry-pick the changes at will; with the defaults being the most practical choices most of the time. If you want your team to be more than a sum of the members (as opposed to stepping on each others' toes), you need decent communication tool. Or you can dispose of communication by being a lone wolf.

abyssknight 16y ago
Just to play devil's advocate here, and definitely not disagreeing with you, but... Do you know how we communicated changes before git and other team tools? With our voices, markers, and boards. If your team steps on each other's toes, might that not be a problem with the team dynamics and not necessarily the tools themselves?
- danssig 16y ago
  The easier you make things for people the less likely they are to mess it up. We used to get around by horse and buggy but I think you'd agree that a change in tools has been a benefit that lets us do things we couldn't do before, wouldn't because it was too hard or tried to do but failed often from the same mistakes over and over.
- dexen 16y ago
  Those are not the changes you are looking for :-) You are absolutely right about the way to propagate changes in ideas, prerequisites, protocols etc. etc.. Actually, I'm a frequent whiteboard user myself. I should've made myself clear I was meaning the physical changes to the implementation files; in any case, something that is byproduct of information shared verbally.

mduerksen 16y ago

> Can you do the same, if not better, job with alternate, less efficient tools? The question is: Is a tool just 10% more efficient or does it introduce a whole new quality of working with it? What do you do when your already delivered software has a bug that needs to be fixed urgently, but you already started to add new features that are not ready yet? Using branches with svn is a thing just everyone is scared of (and rightly so), but with git, this has lost it's horror. You can confidently handle the above situation with git. That's a new quality.

nupark 16y ago
I don't understand the branching mantra that I hear from git proponents. Subversion has had merge tracking since 1.5, and with it, branching and method is as painless as it can reasonably be. Unless you want to work on a submarine, or have an organizational need for people to maintain private unpublished branches (eg, open source), I don't really see what advantages git has to offer over subversion in organizational (read: corporate) development.
- mduerksen 16y ago
  Well, in my case it's not a submarine, but a train. And yes, it is great advantage that I can freely make a branch with the new feature that I just started working on, without having to summon a meeting to let everyone know that a new branch will be created, which is not intended to be used by anyone else even if it's visible to everyone.
  - nupark 16y ago
    I don't follow. Isn't needing a meeting to create a branch an organizational problem, not a technical one? As for working offline, my choice of the submarine example was intentional. 10 years ago I used cvsup (and later, svk) to work on the train and plane while using cvs and svn. That mode of working predates git quite a bit, but it's also much less useful nowadays -- Now I just use phone tethering and inflight wifi. I'd be working less efficiently without Internet resources at hand, so now that wireless technology has caught up, I don't have to.