5 ms·

I have co-workers who work on a big intranet web application that runs on IIS, and they never touch it. They recently finally switched to git for source contro

I have co-workers who work on a big intranet web application that runs on IIS, and they never touch it. They recently finally switched to git for source control, and they want to do everything via GUI. I've tried to show them how some things are just easier/better from the command line, but if something isn't doable via GUI, they won't do it. One of them keeps committing line endings differently than everyone else, and he literally won't run git config --global core.autocrlf true because... I dunno why. He just doesn't want to, because it's the command line.

khalilravanna 8y ago
I just went through this with most of the engineers at our company as they're mostly .NET devs. It's an ongoing process but I basically gave a big talk open to questions on how to use git, all the commands, and the benefits of using the CLI. Thankfully they have a willingness to learn and become better developers and so it's been going pretty smoothly outside of a couple hiccups where I had to step in and perform git-surgery and explain to them how things work a bit better. >One of them keeps committing line endings differently than everyone else, and he literally won't run git config --global core.autocrlf true because... I dunno why. He just doesn't want to, because it's the command line. It sounds like someone needs to have a conversation with this engineer. I personally wouldn't want a single engineer on my team or company that has a resistance to learning new skills. Learning new things and better ways to do those things is basically the job description. Hopefully they have a good reason other than being obstinate otherwise they might need to find a new company that tolerates mediocrity :/
- knewter 8y ago
  I took it as a given they'd found such a company already
IshKebab 8y ago
Git has such a terrible command line that most things are easier in (good) GUIs than on the command line. The only exceptions I can think of are interactive rebase which has a weirdly good command line interface and is really confusing in every GUI I've tried; and continuing/aborting rebase and cherry picks when there is a conflict. And that's only because most GUIs don't bother to actually implement that properly and mislead you into thinking that you should make a new commit.
- jolmg 8y ago
  I find git to be one of the best CLI programs I've ever used. There are a few things I don't like, like how `git blame` requires me to put my terminal in fullscreen to see the output properly. I wish there was an option to make the output group changes of a commit together. It could put the commit details on a line before and add a single character prefix to all lines to differentiate between file lines and commit lines, just like how ag/ack/rg improve grep's output format for human viewing. There's also a long-standing bug in `git log --graph` that causes the lines of the graph to sometimes move back to the previous line at the end of a commit description. I love the -p/--patch option that's available in many subcommands. It's really quick to work with. What specific things do you not like about git's CLI?
  - mikewhy 8y ago
    > What specific things do you not like about git's CLI? The biggest for me is staging lines. In GitHub desktop you click the line numbers, in the command line (iirc) you navigate through chunks as they appear in the file, maybe splitting them into smaller chunks and hopefully can get it down to what you want.
    - lloeki 8y ago
      In git add --patch you can do `e` to edit the hunk interactively, and this help comment appears: # To remove '-' lines, make them ' ' lines (context). # To remove '+' lines, delete them. # Lines starting with # will be removed. I wish tig would have a line-by-line marking feature that would do just that behind the scenes, to make it more accessible.
  - unscaled 8y ago
    The CLI for Git is one of the most confusing CLIs I've ever seen. I can describe all the warts here, but other did that better than me: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/ Besides the inconsistencies, there are many gotchas which keep tripping developers. For instance, git pull always tries to merge in the remote branch, but you almost never want that. You can do: git pull --ff-only, but most developers I know don't know that and end up with a mess they have to spend time cleaning up. The main issue is that git commands mix up so many concepts and the defaults are almost always useless. For instance, git add manages tracking files and staging commits. git rebase both deals with rebasing and history clean-up (rebase -i). A better CLI would just have consistent clear verbs that expose the git model properly instead of mixing up concepts: git track <file> git untrack <file> git stage <file> git unstage <file> git commit And the syntax for creating/deleting/removing branches, remotes and tags would be unified.
pjmlp 8y ago
I only use git on the CLI to fix the typical git blowups. It is so much better just to use standard IDE workflows.

khalilravanna 8y ago

I just went through this with most of the engineers at our company as they're mostly .NET devs. It's an ongoing process but I basically gave a big talk open to questions on how to use git, all the commands, and the benefits of using the CLI. Thankfully they have a willingness to learn and become better developers and so it's been going pretty smoothly outside of a couple hiccups where I had to step in and perform git-surgery and explain to them how things work a bit better. >One of them keeps committing line endings differently than everyone else, and he literally won't run git config --global core.autocrlf true because... I dunno why. He just doesn't want to, because it's the command line. It sounds like someone needs to have a conversation with this engineer. I personally wouldn't want a single engineer on my team or company that has a resistance to learning new skills. Learning new things and better ways to do those things is basically the job description. Hopefully they have a good reason other than being obstinate otherwise they might need to find a new company that tolerates mediocrity :/

knewter 8y ago
I took it as a given they'd found such a company already

IshKebab 8y ago

Git has such a terrible command line that most things are easier in (good) GUIs than on the command line. The only exceptions I can think of are interactive rebase which has a weirdly good command line interface and is really confusing in every GUI I've tried; and continuing/aborting rebase and cherry picks when there is a conflict. And that's only because most GUIs don't bother to actually implement that properly and mislead you into thinking that you should make a new commit.

jolmg 8y ago
I find git to be one of the best CLI programs I've ever used. There are a few things I don't like, like how `git blame` requires me to put my terminal in fullscreen to see the output properly. I wish there was an option to make the output group changes of a commit together. It could put the commit details on a line before and add a single character prefix to all lines to differentiate between file lines and commit lines, just like how ag/ack/rg improve grep's output format for human viewing. There's also a long-standing bug in `git log --graph` that causes the lines of the graph to sometimes move back to the previous line at the end of a commit description. I love the -p/--patch option that's available in many subcommands. It's really quick to work with. What specific things do you not like about git's CLI?
- mikewhy 8y ago
  > What specific things do you not like about git's CLI? The biggest for me is staging lines. In GitHub desktop you click the line numbers, in the command line (iirc) you navigate through chunks as they appear in the file, maybe splitting them into smaller chunks and hopefully can get it down to what you want.
  - lloeki 8y ago
    In git add --patch you can do `e` to edit the hunk interactively, and this help comment appears: # To remove '-' lines, make them ' ' lines (context). # To remove '+' lines, delete them. # Lines starting with # will be removed. I wish tig would have a line-by-line marking feature that would do just that behind the scenes, to make it more accessible.
- unscaled 8y ago
  The CLI for Git is one of the most confusing CLIs I've ever seen. I can describe all the warts here, but other did that better than me: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/ Besides the inconsistencies, there are many gotchas which keep tripping developers. For instance, git pull always tries to merge in the remote branch, but you almost never want that. You can do: git pull --ff-only, but most developers I know don't know that and end up with a mess they have to spend time cleaning up. The main issue is that git commands mix up so many concepts and the defaults are almost always useless. For instance, git add manages tracking files and staging commits. git rebase both deals with rebasing and history clean-up (rebase -i). A better CLI would just have consistent clear verbs that expose the git model properly instead of mixing up concepts: git track <file> git untrack <file> git stage <file> git unstage <file> git commit And the syntax for creating/deleting/removing branches, remotes and tags would be unified.

pjmlp 8y ago

I only use git on the CLI to fix the typical git blowups. It is so much better just to use standard IDE workflows.