5 ms·

I never feel this way. When I started to use it, I only had to understand a few concepts. And when it started to get more complex, it was because the things I

I never feel this way. When I started to use it, I only had to understand a few concepts. And when it started to get more complex, it was because the things I wished to do were more complex in the first place.

strictfp 5y ago
Did you ever use any other VCS?
- emodendroket 5y ago
  I used mercurial a bit when I was starting out but I saw which way the wind was blowing and switched.
  - throwawayboise 5y ago
    Kind of similar. I went from Subversion to git, then tried mercurial. I found mercurial to be more natural, and still use it for my own projects. I have never seen it used in the workplace though.
    - bluGill 5y ago
      My workplace switched from hg to git. Hg didn't get support for all the other tools we use. The Jenkins hg maintainers were all using git when we checked, and it showed. That is but one example of a tool that didn't work with hg.
- throwawayboise 5y ago
  Subversion, and mercurial to a lesser extent. CVS and Visual Source Safe way back in the day.
  - strictfp 5y ago
    Intersting. I always found git needlessly obtuse, with for instance the status reporting diffs to local remote-tracking branches instead of the actual remote branches, the staging area having an unclear purpose to me at the start, that it mixes up "local" "remote" and "base" depending on how an operation is implemented, commands doing double duty providing wildly different functionality etc..
    - throwawayboise 5y ago
      Yes, coming from Subversion the whole staging area concept seemed like needless complexity. For my purposes it still is, but I've gotten used to it.
      - emodendroket 5y ago
        It seems like a nice way of having changes you don't actually want to commit but I'm not sure how other systems approach that problem.
      - strictfp 5y ago
        I really liked Perforce changelists, so in theory I should like the staging area, but I kind of don't :) I use it nowadays, but I think it's too limited to provide value like Perforce changelists does. I'd like to have one changelist for random local dev changes, like setting debug flags or turning off optimizations. Stuff I have no plan on checking in. Then I'd like to group my edits into maybe one to three possible future commits. The staging area doesn't allow this, I need to keep doing "git add -p" and carefully sidestep all the debugging stuff, plus that I can only work on one commit at a time. So could have been useful, but not so useful in it's current state IMO.
        jeffbee 5y ago
        > plus that I can only work on one commit at a time. This is that part of git that bugs me the most! It's totally hostile to the way I prefer to work: one screen session containing all the editors and shells per change that I am concurrently working on. Git simply cannot do it, unless I clone the entire repo for every change, which is not practical for large projects.
- aidenn0 5y ago
  I have used SCCS, CVS, VSS, SVN, Clearcase, darcs, git, and hg. I found darcs to be the most ergonomic, except for the fact that it was orders of magnitude too slow. SVN was good in that it fixed most of the pain-points that CVS had. git and hg are both great. I tried them both out at about the same time and found hg to be more intuitive, but it didn't take me long using git to be comfortable with it. The UI of git is honestly quite terrible. Commands are often confusingly named and have seemingly disparate uses. However the underlying model of git is straightforward enough for me to reason about what operations should be possible. Pretty much all VCSs require some such knowledge and reasoning; e.g.: - The lack of atomic commits in CVS stems from the underlying RCS stack it is based on. - SVNs brain-dead branching stems from the fact that there are no branches in SVN, just O(1) copies from one path to another.
throwawayboise 5y ago
Yes, it can be that way. I know/use clone, diff, add, commit, and pull/push. That is all I ever do with Git, and it's pretty straightforward. I have found no need for the rest of it, and it confused me when I tried to look into it.
loudthing 5y ago
Honestly, git is absolutely needlessly complex. The worst aspect of git is the almost arbitrary naming of tasks that hardcore git users swear are obvious. E.g. "cherry picking", "fast forward", "rebase". Anyone not familiar with git will balk at the concept that the intent of these phrases are obvious. Note: I use git frequently every day, not by choice, but simply because it is the defacto version tracking system. I have grown to like it, but I miss the more straightforward every day use of Mercurial (which is rarely supported by any services anymore). Edit: ... and as a native English speaker, I can't help but feel bad for others who are expected to become familiar with these functions without familiarity with these colloquialisms.
- withinboredom 5y ago
  If you used SVN or something similar, daily, prior to git existing, git operations actually does seem pretty obvious.
  - HWR_14 5y ago
    As the poster pointed out, he's coming from Mecurial, which is a DVCS similar to Git.
  - wyoung2 5y ago
    Fossil was designed by someone coming from CVS, so its everyday CLI is actually closest to that. As a Subversion expat, I found Fossil quite easy to pick up, modulo a few quibbles that muscle memory sorted out quickly enough.
- judge2020 5y ago
  Perhaps, but it originates from the days you'd run `man git <command>` before using it. `man git rebase` works and has a very lengthy description with example tree states.
  - strictfp 5y ago
    git-remove-ref-format vigilantly removes non-annotated remote ref formats using non-configured upstream branches, while applying applicable parents to transfer the given ref formats. https://git-man-page-generator.lokaltog.net https://git-man-page-generator.lokaltog.net

strictfp 5y ago

Did you ever use any other VCS?

emodendroket 5y ago
I used mercurial a bit when I was starting out but I saw which way the wind was blowing and switched.
- throwawayboise 5y ago
  Kind of similar. I went from Subversion to git, then tried mercurial. I found mercurial to be more natural, and still use it for my own projects. I have never seen it used in the workplace though.
  - bluGill 5y ago
    My workplace switched from hg to git. Hg didn't get support for all the other tools we use. The Jenkins hg maintainers were all using git when we checked, and it showed. That is but one example of a tool that didn't work with hg.
throwawayboise 5y ago
Subversion, and mercurial to a lesser extent. CVS and Visual Source Safe way back in the day.
- strictfp 5y ago
  Intersting. I always found git needlessly obtuse, with for instance the status reporting diffs to local remote-tracking branches instead of the actual remote branches, the staging area having an unclear purpose to me at the start, that it mixes up "local" "remote" and "base" depending on how an operation is implemented, commands doing double duty providing wildly different functionality etc..
  - throwawayboise 5y ago
    Yes, coming from Subversion the whole staging area concept seemed like needless complexity. For my purposes it still is, but I've gotten used to it.
    - emodendroket 5y ago
      It seems like a nice way of having changes you don't actually want to commit but I'm not sure how other systems approach that problem.
    - strictfp 5y ago
      I really liked Perforce changelists, so in theory I should like the staging area, but I kind of don't :) I use it nowadays, but I think it's too limited to provide value like Perforce changelists does. I'd like to have one changelist for random local dev changes, like setting debug flags or turning off optimizations. Stuff I have no plan on checking in. Then I'd like to group my edits into maybe one to three possible future commits. The staging area doesn't allow this, I need to keep doing "git add -p" and carefully sidestep all the debugging stuff, plus that I can only work on one commit at a time. So could have been useful, but not so useful in it's current state IMO.
      - jeffbee 5y ago
        > plus that I can only work on one commit at a time. This is that part of git that bugs me the most! It's totally hostile to the way I prefer to work: one screen session containing all the editors and shells per change that I am concurrently working on. Git simply cannot do it, unless I clone the entire repo for every change, which is not practical for large projects.
aidenn0 5y ago
I have used SCCS, CVS, VSS, SVN, Clearcase, darcs, git, and hg. I found darcs to be the most ergonomic, except for the fact that it was orders of magnitude too slow. SVN was good in that it fixed most of the pain-points that CVS had. git and hg are both great. I tried them both out at about the same time and found hg to be more intuitive, but it didn't take me long using git to be comfortable with it. The UI of git is honestly quite terrible. Commands are often confusingly named and have seemingly disparate uses. However the underlying model of git is straightforward enough for me to reason about what operations should be possible. Pretty much all VCSs require some such knowledge and reasoning; e.g.: - The lack of atomic commits in CVS stems from the underlying RCS stack it is based on. - SVNs brain-dead branching stems from the fact that there are no branches in SVN, just O(1) copies from one path to another.

throwawayboise 5y ago

Yes, it can be that way. I know/use clone, diff, add, commit, and pull/push. That is all I ever do with Git, and it's pretty straightforward. I have found no need for the rest of it, and it confused me when I tried to look into it.

loudthing 5y ago

Honestly, git is absolutely needlessly complex. The worst aspect of git is the almost arbitrary naming of tasks that hardcore git users swear are obvious. E.g. "cherry picking", "fast forward", "rebase". Anyone not familiar with git will balk at the concept that the intent of these phrases are obvious. Note: I use git frequently every day, not by choice, but simply because it is the defacto version tracking system. I have grown to like it, but I miss the more straightforward every day use of Mercurial (which is rarely supported by any services anymore). Edit: ... and as a native English speaker, I can't help but feel bad for others who are expected to become familiar with these functions without familiarity with these colloquialisms.

withinboredom 5y ago
If you used SVN or something similar, daily, prior to git existing, git operations actually does seem pretty obvious.
- HWR_14 5y ago
  As the poster pointed out, he's coming from Mecurial, which is a DVCS similar to Git.
- wyoung2 5y ago
  Fossil was designed by someone coming from CVS, so its everyday CLI is actually closest to that. As a Subversion expat, I found Fossil quite easy to pick up, modulo a few quibbles that muscle memory sorted out quickly enough.
judge2020 5y ago
Perhaps, but it originates from the days you'd run `man git <command>` before using it. `man git rebase` works and has a very lengthy description with example tree states.
- strictfp 5y ago
  git-remove-ref-format vigilantly removes non-annotated remote ref formats using non-configured upstream branches, while applying applicable parents to transfer the given ref formats. https://git-man-page-generator.lokaltog.net https://git-man-page-generator.lokaltog.net