6 ms·

I think that while Git would be great as a library, as a front-facing program it's UX could do an improvement: A good UX is simple things should be simple, but

I think that while Git would be great as a library, as a front-facing program it's UX could do an improvement: A good UX is simple things should be simple, but complicated things should be possible, but now look at the following "basic" git workflow: 1. Add. I want git to track this file. Yes, sometimes I need to add certain lines, files, etc. Keep git add, commit, and push. But have a "git update" or something for beginners (and for 99% of use) 2. History - How can I go through a file to see its history? "git show REV"? What if I want a wikipedia style history? What if I want to go through the history of a file? There should be something like "git history main.c" 3. Undelete file - This is fairly common, yet, the command is git checkout $(git rev-list -n 1 HEAD -- "$file")^ -- "$file" A command like git undelete $file would probably make life easier. I haven't gotten to the more complex workflow, and I definitely agree that git is a great revision system, but UX improvements can help --- EDIT, Mandatory xkcd https://xkcd.com/1597/ https://xkcd.com/1597/

steveklabnik 10y ago
What would "update" actually do? For history, "git log", that is "git log file". Isn't part three the same as "git checkout HEAD~1 -- file" ?
- dispose13432 10y ago
  >What would "update" actually do? git add . && git commit && git push >Isn't part three the same as "git checkout HEAD~1 -- file" ? What if the delete took place three commits ago?
  - steveklabnik 10y ago
    Ah okay. I can see that. Then you use HEAD~3.
    - dispose13432 10y ago
      But you first have to find in which commit you deleted the file.
      - steveklabnik 10y ago
        Ah ha, we're starting from different assumptions. Makes sense now, thank you!
  - saghm 10y ago
    > What if the delete took place three commits ago? The original command he was suggesting a replacement for used `-n 1`, so it seems kind of silly to point this out to him.
- Kiro 10y ago
  As soon as a command requires stuff as "HEAD" and "~" I believe there should be an easier way.
tangue 10y ago
Yep. I really hope someone forks git with these ideas ...
- dispose13432 10y ago
  I don't even know if it has to be a fork, maybe a few batch/python scripts could be enough. The problem is that frequently by the time people become experts in a field, they no longer see the beginner's difficulties.
  - syngrog66 10y ago
    your 2nd para is gold. I believe this explains the phenomenon where when you join a new company or parachute into a new codebase for the first time, its often painful ramping up. because so much tribal knowledge is undocumented. or docs not kept updated and wrong. or each dev has their own workflow that works for them privately but nobody's maintaining a common one a newbie can use to get started. some shops/projects better about it than others, obviously.
- no_protocol 10y ago
  No need for so much work. Simple commands can be accomplished by adding a git alias. More complex commands can be just a shell script. Put it on PATH with a name like `git-something` and now you can run `git something`.
AceJohnny2 10y ago
Yes, git's "frontend" is complicated and confusing. There are a plethora of tools that purport to replace it, partially or fully, with something more intuitive. Just off the top of my head: http://gitless.com/ http://gitless.com/ http://www.git-legit.org/ http://www.git-legit.org/ However, they never seem to really take off. Why is that? One thought is also a mandatory XKCD: http://xkcd.com/927/ http://xkcd.com/927/
- ashark 10y ago
  I think most people just have the 5-6 obscure/painful commands they execute more than once a year stuck in an alias, and don't have a strong enough need for Yet Another Thing to Install on fresh systems. It's also sometimes hard to know what exactly these extra commands will do if you don't use them often enough to know, so safe use still involves checking the docs, at which point you may as well google for "git [description of thing I need to do]"
  - btschaegg 10y ago
    After having worked with people that were absolutely hell bent on never using the CLI version of git (and having helped them fix the screwups of their GUI tools a good number of times), I actually think most people would be better off trying to understand how git works internally a little bit more instead of just installing another tool after the last one disappointed them. I don't say you'll have to be an expert, but not having a clue what the tool actually tries to do doesn't really help in those cases (neither does it if you want to do something complicated in SVN, for example) - and the abstractions GUIs add on top of git are bound to break sometime. That is - of course - if you are using git in more than just some basic way. If you're the single person committing code, it will "work" anyway. Perhaps that's the problem: Some people don't see that collaborating on the same set of files in more usable, but also more complex ways (than they are used to) requires more orchestration than just "lock - update - release"...
grigjd3 10y ago
As someone who spent 13 years using CVS, 8 with SVN and 3 with git, I can only say that I greatly disagree with you. The idea of adding a file to track, committing locally and pushing your commits on a branch to a remote makes perfect sense if you spend the thirty minutes it takes to learn what git actually does. Moreover, this is the minimum number of commands to effectively use git correctly.
- dispose13432 10y ago
  1. Sure, if you're an expert, each command is useful. Practically, I commit only when it's ready (building, passes tests). So why would you commit without pushing (unless you're offline)? 2. I know what it does. I've read some manuals :) . The thing is a. I'm not a VC (Version Control) expert, and most people aren't being paid to be VC experts. They're paid to produce code. Now, I (unlike a lot of people) don't mind spending some time learning my text editor (vi) which I use eight hours a day, but I'm not going to become an expert in a tool I use five times a day at most. I just don't interact with it that often. b. Good software is really meant to be gradual interaction. Take vi (which is infamous for being complicated) for example, to use vi, you need to know about 4 or 5 commands, each of which is a single letter or two letters at most, "i" to insert, "x" to delete, ":w" to write and ":q" to quit. Now you can use vi as a glorified notepad. You need a more complicated workflow, you need to copy,paste, undo, fine. Learn each one as you need it. And this is one of the more obtuse text-editing programs. Honestly, if I used a text editor as often as I use git, I'd use nano or something.
  - MaulingMonkey 10y ago
    > Practically, I commit only when it's ready (building, passes tests). So why would you commit without pushing (unless you're offline)? I haven't set up a VCS server yet. I've fixed a security issue and haven't hit the embargo date yet. I'm doing exploratory coding (prototypes, refactorings, etc.) that may be discarded or reworked, even if it builds and passes tests right now. It passes all local tests but needs to be fuzz tested overnight before I'm satisfied enough to commit it upstream - but want to keep working in the meantime. I have more related changes to make before wanting to sic reviewers or the CI build process on my changes. I want to push my changes to a dev environment, but not a production environment just yet. I want to rebase to make my history look cleaner, but can't be bothered with doing so just yet. I commit when it's not ready: I use WIP commits instead of stashes, and sometimes commit more often than I build. This has advantages: It can keep the individual diffs cleaner - an autoreformatting of a file to fix whitespace issues, and hand-implemented refactoring, should be separate commits for cleaner, more readable and reviewable diffs. This has drawbacks: In a centralized VCS, these will either get merged together into one messy commit (common), or they'll get blindly commited without (re)building for all permutations and occasionally break the build, or you'll slow everything down painstakingly testing the entire build after every minor permutation. > but I'm not going to become an expert in a tool I use five times a day at most. I'm no expert either. That said: In the interests of smaller, simpler, more reviewable changes - both for whoever might be doing a code review, and for myself if I mess up and want to figure out what I've done in the past few minutes to break something - I interact with my VCS much more frequently. There are days I make 30 or so commits, and I likely diffed each commit multiple times before committing and/or submitting. Aside from making it way easier to figure out what the hell it is that I've done, being able to finger a specific small changelist as having broken something has saved me tons of time I'd otherwise squander on false leads and disbelief. One of the nastiest heisenbugs I've had the misfortune to debug, I manually did the equivalent of a 'git bisect' on a perforce repository to track down the offending commit for. Totally innocuous change, totally to blame for a fruitless 2 week session of debugging in vain thanks to a buggy system API it used. So innocuous and seemingly unrelated, that I had to reproduce the issue in a simple test app to convince myself it was really the problem. I could've easily wasted another 2 weeks had the changelist been a little bit larger. . TL;DR: Smaller commits have saved me months of work, I figure. Committing without pushing lets me commit without shifting gears, encouraging smaller commits.
ruraljuror 10y ago
Thanks for posting the xkcd comic. I was intrigued by the phrase "distributed graph theory tree model." It is definitely missing some hyphens. Ultimately I decided it should be "distributed graph-theory-tree model." That is, "graph theory" is an adjective modifying tree, and tree is an adjective modifying model.
joatmon-snoo 10y ago
> 2. History - How can I go through a file to see its history? "git show REV"? What if I want a wikipedia style history? What if I want to go through the history of a file? There should be something like "git history main.c" git log --stat --patch -- main.c
- Ajedi32 10y ago
  Make that an alias: git config --global alias.history "log --stat --patch --"
nimchimpsky 10y ago
Don't you use an ide/sourcetree ? All that functionality is available.

steveklabnik 10y ago

What would "update" actually do? For history, "git log", that is "git log file". Isn't part three the same as "git checkout HEAD~1 -- file" ?

dispose13432 10y ago
>What would "update" actually do? git add . && git commit && git push >Isn't part three the same as "git checkout HEAD~1 -- file" ? What if the delete took place three commits ago?
- steveklabnik 10y ago
  Ah okay. I can see that. Then you use HEAD~3.
  - dispose13432 10y ago
    But you first have to find in which commit you deleted the file.
    - steveklabnik 10y ago
      Ah ha, we're starting from different assumptions. Makes sense now, thank you!
- saghm 10y ago
  > What if the delete took place three commits ago? The original command he was suggesting a replacement for used `-n 1`, so it seems kind of silly to point this out to him.
Kiro 10y ago
As soon as a command requires stuff as "HEAD" and "~" I believe there should be an easier way.

tangue 10y ago

Yep. I really hope someone forks git with these ideas ...

dispose13432 10y ago
I don't even know if it has to be a fork, maybe a few batch/python scripts could be enough. The problem is that frequently by the time people become experts in a field, they no longer see the beginner's difficulties.
- syngrog66 10y ago
  your 2nd para is gold. I believe this explains the phenomenon where when you join a new company or parachute into a new codebase for the first time, its often painful ramping up. because so much tribal knowledge is undocumented. or docs not kept updated and wrong. or each dev has their own workflow that works for them privately but nobody's maintaining a common one a newbie can use to get started. some shops/projects better about it than others, obviously.
no_protocol 10y ago
No need for so much work. Simple commands can be accomplished by adding a git alias. More complex commands can be just a shell script. Put it on PATH with a name like `git-something` and now you can run `git something`.

AceJohnny2 10y ago

Yes, git's "frontend" is complicated and confusing. There are a plethora of tools that purport to replace it, partially or fully, with something more intuitive. Just off the top of my head: http://gitless.com/ http://gitless.com/ http://www.git-legit.org/ http://www.git-legit.org/ However, they never seem to really take off. Why is that? One thought is also a mandatory XKCD: http://xkcd.com/927/ http://xkcd.com/927/

ashark 10y ago
I think most people just have the 5-6 obscure/painful commands they execute more than once a year stuck in an alias, and don't have a strong enough need for Yet Another Thing to Install on fresh systems. It's also sometimes hard to know what exactly these extra commands will do if you don't use them often enough to know, so safe use still involves checking the docs, at which point you may as well google for "git [description of thing I need to do]"
- btschaegg 10y ago
  After having worked with people that were absolutely hell bent on never using the CLI version of git (and having helped them fix the screwups of their GUI tools a good number of times), I actually think most people would be better off trying to understand how git works internally a little bit more instead of just installing another tool after the last one disappointed them. I don't say you'll have to be an expert, but not having a clue what the tool actually tries to do doesn't really help in those cases (neither does it if you want to do something complicated in SVN, for example) - and the abstractions GUIs add on top of git are bound to break sometime. That is - of course - if you are using git in more than just some basic way. If you're the single person committing code, it will "work" anyway. Perhaps that's the problem: Some people don't see that collaborating on the same set of files in more usable, but also more complex ways (than they are used to) requires more orchestration than just "lock - update - release"...

grigjd3 10y ago

As someone who spent 13 years using CVS, 8 with SVN and 3 with git, I can only say that I greatly disagree with you. The idea of adding a file to track, committing locally and pushing your commits on a branch to a remote makes perfect sense if you spend the thirty minutes it takes to learn what git actually does. Moreover, this is the minimum number of commands to effectively use git correctly.

dispose13432 10y ago
1. Sure, if you're an expert, each command is useful. Practically, I commit only when it's ready (building, passes tests). So why would you commit without pushing (unless you're offline)? 2. I know what it does. I've read some manuals :) . The thing is a. I'm not a VC (Version Control) expert, and most people aren't being paid to be VC experts. They're paid to produce code. Now, I (unlike a lot of people) don't mind spending some time learning my text editor (vi) which I use eight hours a day, but I'm not going to become an expert in a tool I use five times a day at most. I just don't interact with it that often. b. Good software is really meant to be gradual interaction. Take vi (which is infamous for being complicated) for example, to use vi, you need to know about 4 or 5 commands, each of which is a single letter or two letters at most, "i" to insert, "x" to delete, ":w" to write and ":q" to quit. Now you can use vi as a glorified notepad. You need a more complicated workflow, you need to copy,paste, undo, fine. Learn each one as you need it. And this is one of the more obtuse text-editing programs. Honestly, if I used a text editor as often as I use git, I'd use nano or something.
- MaulingMonkey 10y ago
  > Practically, I commit only when it's ready (building, passes tests). So why would you commit without pushing (unless you're offline)? I haven't set up a VCS server yet. I've fixed a security issue and haven't hit the embargo date yet. I'm doing exploratory coding (prototypes, refactorings, etc.) that may be discarded or reworked, even if it builds and passes tests right now. It passes all local tests but needs to be fuzz tested overnight before I'm satisfied enough to commit it upstream - but want to keep working in the meantime. I have more related changes to make before wanting to sic reviewers or the CI build process on my changes. I want to push my changes to a dev environment, but not a production environment just yet. I want to rebase to make my history look cleaner, but can't be bothered with doing so just yet. I commit when it's not ready: I use WIP commits instead of stashes, and sometimes commit more often than I build. This has advantages: It can keep the individual diffs cleaner - an autoreformatting of a file to fix whitespace issues, and hand-implemented refactoring, should be separate commits for cleaner, more readable and reviewable diffs. This has drawbacks: In a centralized VCS, these will either get merged together into one messy commit (common), or they'll get blindly commited without (re)building for all permutations and occasionally break the build, or you'll slow everything down painstakingly testing the entire build after every minor permutation. > but I'm not going to become an expert in a tool I use five times a day at most. I'm no expert either. That said: In the interests of smaller, simpler, more reviewable changes - both for whoever might be doing a code review, and for myself if I mess up and want to figure out what I've done in the past few minutes to break something - I interact with my VCS much more frequently. There are days I make 30 or so commits, and I likely diffed each commit multiple times before committing and/or submitting. Aside from making it way easier to figure out what the hell it is that I've done, being able to finger a specific small changelist as having broken something has saved me tons of time I'd otherwise squander on false leads and disbelief. One of the nastiest heisenbugs I've had the misfortune to debug, I manually did the equivalent of a 'git bisect' on a perforce repository to track down the offending commit for. Totally innocuous change, totally to blame for a fruitless 2 week session of debugging in vain thanks to a buggy system API it used. So innocuous and seemingly unrelated, that I had to reproduce the issue in a simple test app to convince myself it was really the problem. I could've easily wasted another 2 weeks had the changelist been a little bit larger. . TL;DR: Smaller commits have saved me months of work, I figure. Committing without pushing lets me commit without shifting gears, encouraging smaller commits.

ruraljuror 10y ago

Thanks for posting the xkcd comic. I was intrigued by the phrase "distributed graph theory tree model." It is definitely missing some hyphens. Ultimately I decided it should be "distributed graph-theory-tree model." That is, "graph theory" is an adjective modifying tree, and tree is an adjective modifying model.

joatmon-snoo 10y ago

> 2. History - How can I go through a file to see its history? "git show REV"? What if I want a wikipedia style history? What if I want to go through the history of a file? There should be something like "git history main.c" git log --stat --patch -- main.c

Ajedi32 10y ago
Make that an alias: git config --global alias.history "log --stat --patch --"

nimchimpsky 10y ago

Don't you use an ide/sourcetree ? All that functionality is available.