5 ms·

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. A

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.

chiefalchemist 7y ago
Agreed. If the applications we built using git were as awkward as git...our users and clients would scream, or worse.
- P_I_Staker 7y ago
  I don't understand the relevance of git in all of that
mschaef 7y ago
> If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work with directories is a problem of the git approach. Having a nice offline story is a distinct advantage.) > And personally I prefer a VCS with less ways to shoot myself in the foot than git. Oddly, the thing I love about git is how easy it makes it to recover from mistakes. Even if there are more ways to shoot yourself in the foot, there are also more ways to put your foot back exactly the way it was before you shot it. (If only real life worked that way!) This is what the immutable content storage under the hood of a git repository gets you. If you know the commit hash (and there are a bunch of ways to easily keep track of these), you can get back to the state that's represented by that hash. Commands like merge/rebase/cherry-pick make this particularly easy by providing an '--abort' option that means "I've screwed this operation up beyond repair and need to bail out." And the abort works. As long as you had your target state committed, you can get back to it. (And if that's just a transient state that you don't want to persist, it's easy enough to squash it into something coherent.)
- coldpie 7y ago
  > At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. Yeah. Take an afternoon to read through gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7). Git is a tool, and just like any other tool (car, tablesaw), you will be much better off if you take the time to learn to use it properly. Once you see "The Matrix" behind Git, it becomes an incredibly easy to use and flexible tool for managing source code and other plaintext files.
  - baud147258 7y ago
    The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling. And why does Git require this whereas other VCS don't? Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work.
    - coldpie 7y ago
      > The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling. They're just examples of tools. > Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work. I talk about this elsewhere in this thread, but I disagree with this assertion. I find Mercurial baffling and Git very elegant, though it could be an artifact of the order in which I learned the tools.
    - mschaef 7y ago
      > And why does Git require this whereas other VCS don't? It doesn't. It just works better when you take the time to learn how it works. (Which is an experience I commonly have with the tools I use, for whatever that's worth.)
- baud147258 7y ago
  >the interface makes a lot more sense if you understand the underlying data structure Except that I don't have to understand the underlying data structure to use a more basic VCS like Mercurial. What makes git so special that I would have to do that before being able to use it? And for recovery from mistakes, I meant stashing the changes somewhere, deleting the repository and downloading a clean copy to start again, which I had to do a few times with Git and never with Mercurial (I might had to do it once or twice with SVN, though).
munmaek 7y ago
You can almost always recover from your mistakes with git reflog.
- P_I_Staker 7y ago
  Yes and no. I'm a git guy and a fan, but you can really, really mess things up. Usually, this is only when using features like force push; however, there are arguably legitimate use cases for that. Buddy had a teammate that almost force pushed references from a slightly different repo. What a mess that could have been! I agree regarding the usefulness of reflog, and think the complaints about messing things up with rebase, reset, ect are overblown. It really isn't an issue for intermediate users.
  - munmaek 7y ago
    Hence almost always. It’s not a common situation to delete commits from history, etc. I don’t see the capability to force push as a negative. There are situations in which it’s necessary, like forcibly removing history (something I had to do just today). Git gives you the ability to shoot yourself in the foot, so it’s up to the operator to not make a mistake like that without backing up the repo to a different place first, etc. Something something only a poor carpenter blames their tools.

chiefalchemist 7y ago

Agreed. If the applications we built using git were as awkward as git...our users and clients would scream, or worse.

P_I_Staker 7y ago
I don't understand the relevance of git in all of that

mschaef 7y ago

> If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work with directories is a problem of the git approach. Having a nice offline story is a distinct advantage.) > And personally I prefer a VCS with less ways to shoot myself in the foot than git. Oddly, the thing I love about git is how easy it makes it to recover from mistakes. Even if there are more ways to shoot yourself in the foot, there are also more ways to put your foot back exactly the way it was before you shot it. (If only real life worked that way!) This is what the immutable content storage under the hood of a git repository gets you. If you know the commit hash (and there are a bunch of ways to easily keep track of these), you can get back to the state that's represented by that hash. Commands like merge/rebase/cherry-pick make this particularly easy by providing an '--abort' option that means "I've screwed this operation up beyond repair and need to bail out." And the abort works. As long as you had your target state committed, you can get back to it. (And if that's just a transient state that you don't want to persist, it's easy enough to squash it into something coherent.)

coldpie 7y ago
> At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. Yeah. Take an afternoon to read through gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7). Git is a tool, and just like any other tool (car, tablesaw), you will be much better off if you take the time to learn to use it properly. Once you see "The Matrix" behind Git, it becomes an incredibly easy to use and flexible tool for managing source code and other plaintext files.
- baud147258 7y ago
  The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling. And why does Git require this whereas other VCS don't? Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work.
  - coldpie 7y ago
    > The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling. They're just examples of tools. > Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work. I talk about this elsewhere in this thread, but I disagree with this assertion. I find Mercurial baffling and Git very elegant, though it could be an artifact of the order in which I learned the tools.
  - mschaef 7y ago
    > And why does Git require this whereas other VCS don't? It doesn't. It just works better when you take the time to learn how it works. (Which is an experience I commonly have with the tools I use, for whatever that's worth.)
baud147258 7y ago
>the interface makes a lot more sense if you understand the underlying data structure Except that I don't have to understand the underlying data structure to use a more basic VCS like Mercurial. What makes git so special that I would have to do that before being able to use it? And for recovery from mistakes, I meant stashing the changes somewhere, deleting the repository and downloading a clean copy to start again, which I had to do a few times with Git and never with Mercurial (I might had to do it once or twice with SVN, though).

munmaek 7y ago

You can almost always recover from your mistakes with git reflog.

P_I_Staker 7y ago
Yes and no. I'm a git guy and a fan, but you can really, really mess things up. Usually, this is only when using features like force push; however, there are arguably legitimate use cases for that. Buddy had a teammate that almost force pushed references from a slightly different repo. What a mess that could have been! I agree regarding the usefulness of reflog, and think the complaints about messing things up with rebase, reset, ect are overblown. It really isn't an issue for intermediate users.
- munmaek 7y ago
  Hence almost always. It’s not a common situation to delete commits from history, etc. I don’t see the capability to force push as a negative. There are situations in which it’s necessary, like forcibly removing history (something I had to do just today). Git gives you the ability to shoot yourself in the foot, so it’s up to the operator to not make a mistake like that without backing up the repo to a different place first, etc. Something something only a poor carpenter blames their tools.