3 ms·

I understand the sentiment, but Git is hardly meant to be a simple tool that anybody can pick up and use without any prior experience. I don't use Git just to v

I understand the sentiment, but Git is hardly meant to be a simple tool that anybody can pick up and use without any prior experience. I don't use Git just to version and share my code -- I'd use Dropbox if that were the case. No, I use Git because I want to perform complex operations on a directed acyclic graph which represents the history and structure of my project. I use it because it can be interacted with in a programmatic way, and extended to meet my needs. Git is supposed to be complicated, and you do need "Git skills" to use it properly.

skrebbel 12y ago
> No, I use Git because I want to perform complex operations on a directed acyclic graph which represents the history and structure of my project. To accomplish what? Note, I'm not trying to diss you, I really want to understand why you want to do that. I mean, I never woke up in the morning and said "woa, I really want to perform complex operations on an acyclic graph today". Maybe you and me are just different, but I usually want to make software, together with my team. I want to hack on the same software as them at the same time, so we need a way to deal with all the technicalities that make emailing ZIP files around unpractical. I want to keep track of history so that I can see why we did what when, and so that I can undo stupid mistakes. That's really all I want. I don't completely understand why I consciously need to perform complex operations on a directed acyclic graph to accomplish these things, but somehow that what I end up doing, and that makes me sad. I find it to be a horrible distraction. For me, the "D" in DVCS is an implementation detail, and I bet this holds for 90% of GitHub's paying customers.
- Ao7bei3s 12y ago
  > I usually want to make software, together with my team 1. Small-scale history: Developers make mistakes. When things go wrong, a clean history of small, incremental changes is priceless. Git helps you craft such a history. It's not about what actually happened. It's about helping you solve future problems. 2. Large-scale history: large projects branch. Especially commercial ones, where you need to support old versions, or maybe have custom versions for laaarge customers. Git handles this well. And it's good at helping you get identical changes into multiple branches without loosing track. > and I bet this holds for 90% of GitHub's paying customers. 90% of everything is crap ;)
- ossreality 12y ago
  > I find it to be a horrible distraction. For me, the "D" in DVCS is an implementation detail, and I bet this holds for 90% of GitHub's paying customers. And I don't think you have any idea what you're talking about.
- wldlyinaccurate 12y ago
  Sorry, I've just realised how snarky my comment came off as. I guess the point I was trying to make is that a huge portion of Git users don't actually need Git; they would probably get everything they need from a conceptually simpler VCS like Mercurial or SVN. Regarding the DAG thing, this is just because that's essentially how Git actually represents the objects which it stores, which represent your repository and its history. A lot of the time I'm in the mindset of "committing some code to a branch" but sometimes it's useful for me to get into DAG-mode so that I can more easily think about how I want my repository to be structured. An example is how I work with my master branch, which I consider to be the absolute source of truth for a repository's history. This means that it should be full of complete, atomic commits which are ordered in a way that enables me to do things like git-bisect (for finding bugs), generate meaningful release logs, and just generally understand the history at a glance. So rather than just blindly merge my branches into master, I spend a lot of time using git-rebase to squash, re-order, and edit my commits. I find it easier to do this when I'm thinking in terms of a DAG, rather than some abstract concept of a "commit" (whatever that is).
dale-cooper 12y ago
I don't think the choice is that binary (git OR dropbox). I've needed to use both mercurial and git for different jobs. From that experience i would say mercurial is just as powerful as git but more intuitive and easy to learn.

skrebbel 12y ago

> No, I use Git because I want to perform complex operations on a directed acyclic graph which represents the history and structure of my project. To accomplish what? Note, I'm not trying to diss you, I really want to understand why you want to do that. I mean, I never woke up in the morning and said "woa, I really want to perform complex operations on an acyclic graph today". Maybe you and me are just different, but I usually want to make software, together with my team. I want to hack on the same software as them at the same time, so we need a way to deal with all the technicalities that make emailing ZIP files around unpractical. I want to keep track of history so that I can see why we did what when, and so that I can undo stupid mistakes. That's really all I want. I don't completely understand why I consciously need to perform complex operations on a directed acyclic graph to accomplish these things, but somehow that what I end up doing, and that makes me sad. I find it to be a horrible distraction. For me, the "D" in DVCS is an implementation detail, and I bet this holds for 90% of GitHub's paying customers.

Ao7bei3s 12y ago
> I usually want to make software, together with my team 1. Small-scale history: Developers make mistakes. When things go wrong, a clean history of small, incremental changes is priceless. Git helps you craft such a history. It's not about what actually happened. It's about helping you solve future problems. 2. Large-scale history: large projects branch. Especially commercial ones, where you need to support old versions, or maybe have custom versions for laaarge customers. Git handles this well. And it's good at helping you get identical changes into multiple branches without loosing track. > and I bet this holds for 90% of GitHub's paying customers. 90% of everything is crap ;)
ossreality 12y ago
> I find it to be a horrible distraction. For me, the "D" in DVCS is an implementation detail, and I bet this holds for 90% of GitHub's paying customers. And I don't think you have any idea what you're talking about.
wldlyinaccurate 12y ago
Sorry, I've just realised how snarky my comment came off as. I guess the point I was trying to make is that a huge portion of Git users don't actually need Git; they would probably get everything they need from a conceptually simpler VCS like Mercurial or SVN. Regarding the DAG thing, this is just because that's essentially how Git actually represents the objects which it stores, which represent your repository and its history. A lot of the time I'm in the mindset of "committing some code to a branch" but sometimes it's useful for me to get into DAG-mode so that I can more easily think about how I want my repository to be structured. An example is how I work with my master branch, which I consider to be the absolute source of truth for a repository's history. This means that it should be full of complete, atomic commits which are ordered in a way that enables me to do things like git-bisect (for finding bugs), generate meaningful release logs, and just generally understand the history at a glance. So rather than just blindly merge my branches into master, I spend a lot of time using git-rebase to squash, re-order, and edit my commits. I find it easier to do this when I'm thinking in terms of a DAG, rather than some abstract concept of a "commit" (whatever that is).

dale-cooper 12y ago

I don't think the choice is that binary (git OR dropbox). I've needed to use both mercurial and git for different jobs. From that experience i would say mercurial is just as powerful as git but more intuitive and easy to learn.