6 ms·

git

raverbashing 9y ago
it was awful, it is getting better and I think it's a good example in several occasions (I mean when it's not an unpredictable sequence of commands that need to be passed to accomplish something outside of a regular workflow)
- odammit 9y ago
  I enjoy how much git-flow-avh dumbs down git for me. I've been using regular old git commands for years but inevitably end up in some weird merge conflict with myself and possibly a slightly inebriated version of me that was coding the night before.
- souenzzo 9y ago
  I'm using git cli. Already tried sourceTree, gitkraken, intellij plugins, atom plugins.... all these attempts ended up in "I do not know which branch I am in" or "How do I get a diff to remote"?
  - tracker1 9y ago
    Agreed, part of why I love the integrated terminal in VS Code... mostly doing git, node and npm commands while working on my projects. About the most GUI I use, is the active diff tool in VS Code. But that's not CLI based. I've also tried a few gui tools for git, and none seem to be quite as easy as just using the CLI for it. Probably the cli that I find the most useful beyond git that I use regularly is docker... It's pretty useful if you aren't in a linux environment but need to build something in one... In my node lambda builds, I'll do something like: docker -i -v "${PWD}/dist":/app -w /app node:6.10 npm i Which is usually enough to give me something I can zip and upload for use in a lambda... Though, like git, if I'm doing something not usual, I often wind up having to google it. Like anything in git more complicated than a simple rebase or add/commit/push.
weavie 9y ago
For the love of your chosen deity, please do not take git as a good example to base your CLI UX on..
- cat199 9y ago
  Maybe you just need to read the manual? Hmm... https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
  - weavie 9y ago
    Made my day. Thankyou! :-)
- xyzzy_plugh 9y ago
  I think there are a number of great things to learn from the git UX. - sub commands (and sub sub commands) provide a high level abstraction over the many different tools and features. The "toolkit" approach allows for easy expansion and refactoring of individual features, and is entirely pluggable by end users. It even provides tools to interface seamlessly (git rev-parse --parseopt; rev-parse is amazing and allows you to wrangle git types trivially). Git also doesn't care what language you use. It ships git subcommands in C, shell and perl, but you can use node, python, bash, go, whatever you like. Really great. - git divides it's interface and features into porcelain (user facing) and plumbing (internal; used by porcelain implementations). This allows them to avoid breaking changes while providing new and exciting features. This is a great design choice and it's been copied extensively by many projects, but I've never seen it pulled off as well as git. - git consistently reuses terms and objects (there have been some missteps over the years but the maintainers are very humble). Commit objects, refs, dates and times all work the same almost everywhere. - git is extremely well documented, both in its man pages, online and within the tool itself. Help flags and interactive messages and descriptions and suggestions of what to do next. Have you ever performed an interactive rebase? Or resolved a merge commit? Or corrected a tracking branch? Just great stuff. I know we love to hate on git here but let's just for a moment acknowledge this wonderful, powerful tool for something it does a great job at. Git cuts no corners, it's consistent and trustworthy, and a hallmark of modern day software engineering and UX.
Sir_Cmpwn 9y ago
Sad to see this in the grey. Git is unintuitive to those who don't understand it. If you read about its internals and learn how it works, the command line gets much better. It's well documented and it gives you a whole lot of power and insight into the inner workings of the VCS. Things like launching your editor to do more complex commands, plugging a script into git bisect, these are all great design choices.
- exDM69 9y ago
  All of what you say is correct. git is great in many ways and not too difficult to use once you grok the internals. But git's user interface is inconsistent, has got weird error messages and confusing terminology with too many ways to do some things. Good thing that it has quite decent manpages which explain these things thoroughly. The UI gets the job done but it sure isn't a great example of a well designed command line.
  - Sir_Cmpwn 9y ago
    It's rough in some ways, and elegant in others. A bad error message does not a bad UX make. Good error messages are great, but remember UX is also about hitting the important points well.
- viraptor 9y ago
  It didn't matter how powerful it is. It's still inconsistent and a bad example of ux. Some trivial examples: "tag -d", but "remote remove"; exiting editor after "commit" aborts, but after "rebase -i" continues operation; etc. There are other projects that interact with git and are really good: tig, for example. But git itself? Someone wrote a good paper about it already. "What's wrong with git?" was the title, I believe.
- polymeris 9y ago
  git has a terrible UI, IMO. git reset, for instance, does like 17 different things. And what does checkout have to do with creating branches as in "git checkout -b"? Not that git branch is that much better, it's conflating creating, listing and deleting under one command (named after a verb or singular noun). Compare to hg's branch/branches or fossil's even clearer convention of noun + action, like in "fossil branch new ...". That said, you are right that understanding the git model helps a lot and for that, I recommend the "Getting Git" talk. https://vimeo.com/14629850 https://vimeo.com/14629850

git

it was awful, it is getting better and I think it's a good example in several occasions (I mean when it's not an unpredictable sequence of commands that need to be passed to accomplish something outside of a regular workflow)

odammit 9y ago
I enjoy how much git-flow-avh dumbs down git for me. I've been using regular old git commands for years but inevitably end up in some weird merge conflict with myself and possibly a slightly inebriated version of me that was coding the night before.
souenzzo 9y ago
I'm using git cli. Already tried sourceTree, gitkraken, intellij plugins, atom plugins.... all these attempts ended up in "I do not know which branch I am in" or "How do I get a diff to remote"?
- tracker1 9y ago
  Agreed, part of why I love the integrated terminal in VS Code... mostly doing git, node and npm commands while working on my projects. About the most GUI I use, is the active diff tool in VS Code. But that's not CLI based. I've also tried a few gui tools for git, and none seem to be quite as easy as just using the CLI for it. Probably the cli that I find the most useful beyond git that I use regularly is docker... It's pretty useful if you aren't in a linux environment but need to build something in one... In my node lambda builds, I'll do something like: docker -i -v "${PWD}/dist":/app -w /app node:6.10 npm i Which is usually enough to give me something I can zip and upload for use in a lambda... Though, like git, if I'm doing something not usual, I often wind up having to google it. Like anything in git more complicated than a simple rebase or add/commit/push.

weavie 9y ago

For the love of your chosen deity, please do not take git as a good example to base your CLI UX on..

cat199 9y ago
Maybe you just need to read the manual? Hmm... https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
- weavie 9y ago
  Made my day. Thankyou! :-)
xyzzy_plugh 9y ago
I think there are a number of great things to learn from the git UX. - sub commands (and sub sub commands) provide a high level abstraction over the many different tools and features. The "toolkit" approach allows for easy expansion and refactoring of individual features, and is entirely pluggable by end users. It even provides tools to interface seamlessly (git rev-parse --parseopt; rev-parse is amazing and allows you to wrangle git types trivially). Git also doesn't care what language you use. It ships git subcommands in C, shell and perl, but you can use node, python, bash, go, whatever you like. Really great. - git divides it's interface and features into porcelain (user facing) and plumbing (internal; used by porcelain implementations). This allows them to avoid breaking changes while providing new and exciting features. This is a great design choice and it's been copied extensively by many projects, but I've never seen it pulled off as well as git. - git consistently reuses terms and objects (there have been some missteps over the years but the maintainers are very humble). Commit objects, refs, dates and times all work the same almost everywhere. - git is extremely well documented, both in its man pages, online and within the tool itself. Help flags and interactive messages and descriptions and suggestions of what to do next. Have you ever performed an interactive rebase? Or resolved a merge commit? Or corrected a tracking branch? Just great stuff. I know we love to hate on git here but let's just for a moment acknowledge this wonderful, powerful tool for something it does a great job at. Git cuts no corners, it's consistent and trustworthy, and a hallmark of modern day software engineering and UX.

Sir_Cmpwn 9y ago

Sad to see this in the grey. Git is unintuitive to those who don't understand it. If you read about its internals and learn how it works, the command line gets much better. It's well documented and it gives you a whole lot of power and insight into the inner workings of the VCS. Things like launching your editor to do more complex commands, plugging a script into git bisect, these are all great design choices.

exDM69 9y ago
All of what you say is correct. git is great in many ways and not too difficult to use once you grok the internals. But git's user interface is inconsistent, has got weird error messages and confusing terminology with too many ways to do some things. Good thing that it has quite decent manpages which explain these things thoroughly. The UI gets the job done but it sure isn't a great example of a well designed command line.
- Sir_Cmpwn 9y ago
  It's rough in some ways, and elegant in others. A bad error message does not a bad UX make. Good error messages are great, but remember UX is also about hitting the important points well.
viraptor 9y ago
It didn't matter how powerful it is. It's still inconsistent and a bad example of ux. Some trivial examples: "tag -d", but "remote remove"; exiting editor after "commit" aborts, but after "rebase -i" continues operation; etc. There are other projects that interact with git and are really good: tig, for example. But git itself? Someone wrote a good paper about it already. "What's wrong with git?" was the title, I believe.
polymeris 9y ago
git has a terrible UI, IMO. git reset, for instance, does like 17 different things. And what does checkout have to do with creating branches as in "git checkout -b"? Not that git branch is that much better, it's conflating creating, listing and deleting under one command (named after a verb or singular noun). Compare to hg's branch/branches or fossil's even clearer convention of noun + action, like in "fossil branch new ...". That said, you are right that understanding the git model helps a lot and for that, I recommend the "Getting Git" talk. https://vimeo.com/14629850 https://vimeo.com/14629850