3 ms·

Not being quite sure how git deals with this even though, as the parent argues, it is the sensible default behavior, is really the problem. Everything is possib

by gizmo 3y ago

Not being quite sure how git deals with this even though, as the parent argues, it is the sensible default behavior, is really the problem. Everything is possible with git but nothing is easy or easy to remember.

PaulDavisThe1st 3y ago
> Everything is possible with git but nothing is easy or easy to remember. These are the commands the overwhelming majority of git users will use the overwhelming majority of the time: clone / checkout (or switch) / commit / merge / rebase / diff / stash Time to stop the "nothing is easy" fairy tale. Yes, hacking around with the reflog and fixing up weird situations with git is ... tricky and hard to remember. But the vast bulk of git usage is easy and easy to remember.
- nerdponx 3y ago
  As a very satisfied long time Git user who also ends up being its biggest advocate and trainer at any organization I end up at... no, it's not easy. It's easy from the perspective of someone who already understands its conceptual model, which is wonderfully elegant. It's not at all easy for beginners. The happy path is fine for the most part. There are several conceptual hurdles to developing basic competence with add, commit, push, and pull, but usually people are able to push past them and get to the point of using those commands even if their purpose and mechanism of action remain mysterious. But things immediately go to hell if something deviates from the happy path. Have you ever seen a beginner try to wrap their head around a merge conflict? Have you ever seen someone try to puzzle through the man pages and Stackoverflow to figure out how to recover from a situation when they can't push, due to remote changes? It often ends in disaster, as they stumble through increasingly opaque and arcane commands, as they mess up the state of their local repository ever further with every copied and pasted snippet. This is not a case of newbies trying to do advanced things they shouldn't be doing. These are "advanced beginner" tasks that arise naturally at some point in just about any workflow. Of course, a lot of this can be ascribed to general lack of competence in doing computer stuff. But Git seems especially disorienting even to people with high general intelligence and years of experience solving difficult technical problems. There's something about its combination of commands that do not map cleanly to the underlying data model, complicated layers of automatic behavior that are only revealed deep within chatty jargon filled reference manual pages (or can only be found in the source code), broadly inconsistent terminology and UI elements, and CLI that tends to be either too verbose or too quiet by default. It's hard to learn and hard to teach. That, in my opinion, makes it hard to use.
  - adhesive_wombat 3y ago
    In my opinion, the biggest thing git could do to be easier to learn is make the "git lola" alias what happens by default when you write "git log". Once you see the graph change as you move about, it all makes a lot more sense. http://blog.kfish.org/2010/04/git-lola.html?m=1 http://blog.kfish.org/2010/04/git-lola.html?m=1
    - nerdponx 3y ago
      Agreed, with the caveat that a tangled commit history can be overwhelming to a beginner. Probably the only time I really want to recommend a Git GUI is for visualizing the commit graph. I think GitUp does a really good job of making it navigable and understandable, but is unfortunately Mac-only: https://gitup.co/ https://gitup.co/ If you're interested, here's my version of this: [alias] ## Pretty log graph log-oneline = log --decorate=short --date='format-local:%a %F %H:%M' --pretty='tformat:%C(auto)%h%C(reset) %C(auto,blue)[%ad]%C(reset)%C(auto)%d%C(reset) %aN: %s' log-graph = log-oneline --topo-order --graph reflog-oneline = log-oneline --walk-reflogs lg = log-graph lgl = log-graph --branches --tags lgr = log-graph --branches --tags --remotes lga = log-graph --all For anyone who doesn't want to dig around in the git-log(1) man page, the relevant format placeholder are: %C(col) Change color to "col" %h Abbreviated commit hash %ad Author date (formatted as per --date) %d Ref name (like with --decorate) %aN Author name %s "Subject" (first line of commit message) The difference with the usual `--decorate --pretty=oneline --abbrev-commit` options is that my version includes the date and author name, which can be really helpful when navigating a long commit history and/or a project with multiple contributors. Without it, I often found myself wondering "who did that, and when did they do it?". The --topo-order option also helps here.
  - _a_a_a_ 3y ago
    Agreed, it's a bugger and it's caused me more learning, effort & timewaste than any other piece of software that basically does so little, comparatively speaking, with anything else I use. And I still don't fucking understand it to the point of feeling safe with it.
  - cmrdporcupine 3y ago
- vore 3y ago
  Well, at the same time, you can get yourself into funny situations that are hard to get out of without knowing the intricacies of Git (e.g. what is "detached HEAD"?). And rebasing is absolutely not easy to understand.
  - goku12 3y ago
    > And rebasing is absolutely not easy to understand. Rebasing is very easy to understand if you treat commits as diffs. Commits are stored as snapshots. But operations like rebase and merge act on diffs introduced by the commit (often that action is a 3-way merge). For example, when you drop/delete a commit while rebasing, the change introduced by that commit is removed from all subsequent commits. Meanwhile, another problem is that you can easily get lost if a rebase is interrupted by a conflict. This would have been easier if you could see the commits as diffs. The easiest way out I found is to do no more than 2 operations per rebase. You can do as many rebases as you wish.
- adhesive_wombat 3y ago
  Git is also really quite good at enabling pretty much any workflow. There's no blessed golden workflow that is completely frictionless, but there're also not many things that are completely impractical. Most "git but better" alternatives seem to favour a particular workflow. Which is fine, until it isn't (e.g. no matter what you might think of the git rebase system, using a tool that doesn't support rebase at all is much less fun). Wierd situations very rarely seem happen to me. At worst you just git reset --hard to something sensible. If you're nervous about doing something, make a tag before you do it at your current HEAD location (git tag "pre-drama-tag-here-we-go") and you'll always be able to tap your heels and go home without even having to find the right hash.
- dreamcompiler 3y ago
  https://boyter.org/static/books/CpWvVOoW8AAjYmB.jpg https://boyter.org/static/books/CpWvVOoW8AAjYmB.jpg

by gizmo 3y ago

PaulDavisThe1st 3y ago

> Everything is possible with git but nothing is easy or easy to remember. These are the commands the overwhelming majority of git users will use the overwhelming majority of the time: clone / checkout (or switch) / commit / merge / rebase / diff / stash Time to stop the "nothing is easy" fairy tale. Yes, hacking around with the reflog and fixing up weird situations with git is ... tricky and hard to remember. But the vast bulk of git usage is easy and easy to remember.

nerdponx 3y ago
As a very satisfied long time Git user who also ends up being its biggest advocate and trainer at any organization I end up at... no, it's not easy. It's easy from the perspective of someone who already understands its conceptual model, which is wonderfully elegant. It's not at all easy for beginners. The happy path is fine for the most part. There are several conceptual hurdles to developing basic competence with add, commit, push, and pull, but usually people are able to push past them and get to the point of using those commands even if their purpose and mechanism of action remain mysterious. But things immediately go to hell if something deviates from the happy path. Have you ever seen a beginner try to wrap their head around a merge conflict? Have you ever seen someone try to puzzle through the man pages and Stackoverflow to figure out how to recover from a situation when they can't push, due to remote changes? It often ends in disaster, as they stumble through increasingly opaque and arcane commands, as they mess up the state of their local repository ever further with every copied and pasted snippet. This is not a case of newbies trying to do advanced things they shouldn't be doing. These are "advanced beginner" tasks that arise naturally at some point in just about any workflow. Of course, a lot of this can be ascribed to general lack of competence in doing computer stuff. But Git seems especially disorienting even to people with high general intelligence and years of experience solving difficult technical problems. There's something about its combination of commands that do not map cleanly to the underlying data model, complicated layers of automatic behavior that are only revealed deep within chatty jargon filled reference manual pages (or can only be found in the source code), broadly inconsistent terminology and UI elements, and CLI that tends to be either too verbose or too quiet by default. It's hard to learn and hard to teach. That, in my opinion, makes it hard to use.
- adhesive_wombat 3y ago
  In my opinion, the biggest thing git could do to be easier to learn is make the "git lola" alias what happens by default when you write "git log". Once you see the graph change as you move about, it all makes a lot more sense. http://blog.kfish.org/2010/04/git-lola.html?m=1 http://blog.kfish.org/2010/04/git-lola.html?m=1
  - nerdponx 3y ago
    Agreed, with the caveat that a tangled commit history can be overwhelming to a beginner. Probably the only time I really want to recommend a Git GUI is for visualizing the commit graph. I think GitUp does a really good job of making it navigable and understandable, but is unfortunately Mac-only: https://gitup.co/ https://gitup.co/ If you're interested, here's my version of this: [alias] ## Pretty log graph log-oneline = log --decorate=short --date='format-local:%a %F %H:%M' --pretty='tformat:%C(auto)%h%C(reset) %C(auto,blue)[%ad]%C(reset)%C(auto)%d%C(reset) %aN: %s' log-graph = log-oneline --topo-order --graph reflog-oneline = log-oneline --walk-reflogs lg = log-graph lgl = log-graph --branches --tags lgr = log-graph --branches --tags --remotes lga = log-graph --all For anyone who doesn't want to dig around in the git-log(1) man page, the relevant format placeholder are: %C(col) Change color to "col" %h Abbreviated commit hash %ad Author date (formatted as per --date) %d Ref name (like with --decorate) %aN Author name %s "Subject" (first line of commit message) The difference with the usual `--decorate --pretty=oneline --abbrev-commit` options is that my version includes the date and author name, which can be really helpful when navigating a long commit history and/or a project with multiple contributors. Without it, I often found myself wondering "who did that, and when did they do it?". The --topo-order option also helps here.
- _a_a_a_ 3y ago
  Agreed, it's a bugger and it's caused me more learning, effort & timewaste than any other piece of software that basically does so little, comparatively speaking, with anything else I use. And I still don't fucking understand it to the point of feeling safe with it.
- cmrdporcupine 3y ago
vore 3y ago
Well, at the same time, you can get yourself into funny situations that are hard to get out of without knowing the intricacies of Git (e.g. what is "detached HEAD"?). And rebasing is absolutely not easy to understand.
- goku12 3y ago
  > And rebasing is absolutely not easy to understand. Rebasing is very easy to understand if you treat commits as diffs. Commits are stored as snapshots. But operations like rebase and merge act on diffs introduced by the commit (often that action is a 3-way merge). For example, when you drop/delete a commit while rebasing, the change introduced by that commit is removed from all subsequent commits. Meanwhile, another problem is that you can easily get lost if a rebase is interrupted by a conflict. This would have been easier if you could see the commits as diffs. The easiest way out I found is to do no more than 2 operations per rebase. You can do as many rebases as you wish.
adhesive_wombat 3y ago
Git is also really quite good at enabling pretty much any workflow. There's no blessed golden workflow that is completely frictionless, but there're also not many things that are completely impractical. Most "git but better" alternatives seem to favour a particular workflow. Which is fine, until it isn't (e.g. no matter what you might think of the git rebase system, using a tool that doesn't support rebase at all is much less fun). Wierd situations very rarely seem happen to me. At worst you just git reset --hard to something sensible. If you're nervous about doing something, make a tag before you do it at your current HEAD location (git tag "pre-drama-tag-here-we-go") and you'll always be able to tap your heels and go home without even having to find the right hash.
dreamcompiler 3y ago
https://boyter.org/static/books/CpWvVOoW8AAjYmB.jpg https://boyter.org/static/books/CpWvVOoW8AAjYmB.jpg