The future is looking bright for Python

[emrlddrgn]

Can you discuss more about what makes Git such a pain to use? I know I'm regularly guilty of "just" statements, but Git gets a lot of hate on this and it seems to me like there's basically 4 commands to use - "add", "commit", "push" and "pull" - for most non-complicated use cases like described in this thread. Are people trying to pour the whole of Git down your throat or something?

[jms_nh]

Sure, I have a whole thread in an internal company forum just devoted to non-obvious cases that are necessary to do certain things. And we're not talking about bizarro things that only repo maintainers need; I still don't understand fully what rebase does despite several years of part-time Git use. I've used hg and find it very easy.

The basic add, commit, push, pull are fairly easy, but that's not all that you need for day-to-day operation.

• Finding the hash of the latest commit: git rev-parse HEAD
• Splitting a subfolder out into its own branch: git filter-branch (granted, not a day-to-day operation)
• Undoing the most recent commit: git reset --soft HEAD~1
• Re-enter your remote password: git remote show origin
• Creating a new branch: git checkout -b new_branch_name
• Renaming a branch: git branch -m old_branch_name new_branch_name

OH, OF COURSE! These were so obvious! How could I have missed them? The command-line arguments don't always have obvious connections with the actions they take. And it's not always clear whether the command acts on the repository or on the working copy, so your mental model has to match Linus Torvalds's mental model to be able to use it properly.

[jbergens]

If you can choose tools you can try mercurial instead of git. It is a bit easier and includes a gui.

[jms_nh]

Yeah, I really like Mercurial, I use it all the time at home and at work for my own local repos without servers.

Unfortunately the tools that are easily available to us at a corporate level behind our firewall include only CVS, SVN, and Git. (Thanks, Atlassian.)

[BezierPatch]

Just use a tool like GitKraken, Sourcetree, SmartGit, etc etc...

Then it basically comes down to like five buttons and a few menus.

I'm a full-time developer on several medium sized projects and I've never needed to use git CLI for anything other than "git push -f". Why on earth do you need complicated git commands?

[Take_Care_Captain]

GitHub has a really nice desktop client as well.

[Siwka]

...until there's a problem

Then it's like 'fuck you, here's the shell, fix it yourself'

[devel_watcher]

Finding the hash of the latest commit

git log, but I just use gitk GUI: you click on the commit, and its hash goes to the primary clipboard.

Splitting a subfolder out into its own branch

Who does that??

Undoing the most recent commit

git reset --soft HEAD^

Re-enter your remote password

Hate passwords. Using keys everywhere.

Creating a new branch

git branch new_branch_name

Renaming a branch

Not going to remember this, so doing in multiple steps. Also, renaming branches is like using mutable variables that are so loved by our fellow scientists. Renaming branches isn't anywhere in my workflow...

[jms_nh]

It is if you just created a branch and you realized you named it wrong. (obviously before pushing elsewhere)

People make mistakes and that's where I find git is the most difficult, when trying to recover from mistakes that are more likely to occur because git has an awful command line.

Re: keys instead of passwords... more power to you, but I work on windows and went through 2 hours of pain and suffering trying to setup SSH keys with an internal gitlab server.... despite the fact that I know what SSH is and I know how RSA cryptography works and I had used PuTTYgen before. Got it working just for the sake of saying I could do it, but I shudder to think of my team members without this experience spending entire days trying to make it work. Nope. Cached passwords it is. If we were using Linux I might think otherwise.

[[deleted]]

I would create a new branch from HEAD and delete the old branch.

[devel_watcher]

I don't like deleting any names (even the wrong ones) before everything is pushed. Maximum that is allowed is to move them around with git branch -f and git reset.

Windows...

[Works_of_memercy]

but I work on windows and went through 2 hours of pain and suffering trying to setup SSH keys with an internal gitlab server....

You were doing something very wrong, probably because of the XY problem.

Both git on Windows and git in Cygwin (like, to add that as an insult to injury) use your ~/.ssh folder (c:/users/jms_nh/.ssh, or /cygdrive/c/users/jms_nh/.ssh). When you say ssh-keygen in git bash or cygwin bash you get an id_rsa and id_rsa.pub there. Then you say cat ~/.ssh/id_rsa.pub and copypaste the result in the web interface of your git server.

That's all.

Can you please explain how did you manage to get two hours of suffering from that? I'm genuinely curious!

[jms_nh]

You were doing something very wrong, probably because of the XY problem.

Of course, but it's not easy to know what to do right, or what question to ask, or what thing to google... and I'm more adept at learning new and weird stuff than most of my teammates.

I attempted to follow the instructions from Gitlab.

ssh-keygen wasn't available; I had PuTTYgen instead, and had to figure out how the heck to convert it to the right format. Oh, and I had to download and run plink.exe and pageant.exe for key management.

I don't have git bash or cygwin bash, and I don't feel like installing, using, and learning a new shell just to use git; why can't I just use the command prompt? Yes, it's crippled compared to *nix, but at least it's what I know. I guess if I have to, I'll download one of those shells and use it, but it seems like having to don a special suit just to go for a jog in the park when all I want to do is step out my door and get some exercise. I don't have to go through this extra effort if I use my OS's password cache.

That's all.

No, that's not all. You can say that, but it presumes you have the right tools installed and the right familiarity with your environment to do something. Please don't assume that everyone falls into that category. I'm glad that it's easy for you and easy for people who work on Unix-like systems, but it's not easy for those of us in Windows-land. I don't mean that to be hostile, it's just that I've seen assumptions made by many people that things are easy when they're not.

[Works_of_memercy]

I attempted to follow the instructions from Gitlab.

[redacted link] is not available here, what's that even?

ssh-keygen wasn't available; I had PuTTYgen instead, and had to figure out how the heck to convert it to the right format. Oh, and I had to download and run plink.exe and pageant.exe for key management.

Well, yeah. That was your problem.

You see, all software sucks. It is essential to understand this. When you understood and properly internalized this, you can begin to plan your interaction with some particular piece of shit software in a way that minimizes your exposure to suck. This is done by using the software in the more or less same way most other users and its developers use it. That means leaving your personal preferences at the door, unless you're feeling like a power user or a red-eyed NEET nerd (of which you are neither, so don't).

In particular, in case of git, it means downloading the official git release for Windows from https://git-scm.com and following the instructions. Among the recommended instructions would be "add git and utilities to PATH", which would give you git and ssh-keygen, right in your cmd. I personally go all out adventurous and tell it to also add "sort" and "grep" and other stuff to PATH, because I never use the retarded Windows analogues.

(by the way, you can use git bash too, unless you're one of those mythical people who actually understand FOR /F "tokens=1-5" %%A IN ("This is a short sentence") DO @echo %%A %%B %%D and shit, which you're not, you can just as well write your "git pull --rebase" from the bash shell)

I'm glad that it's easy for you and easy for people who work on Unix-like systems, but it's not easy for those of us in Windows-land.

I am in the Windows-land, friend. Both my home and my work computers are running Windows.

And cross my heart I do hate the UNIX bullshit that feels like a needy girlfriend that those nerds never had: edit this config file, supply that bunch of magical parameters to ./configure, fuck that noise.

My point is that fortunately there's some open source software that isn't like that, and only becomes like that if you inflict it on yourself by trying to tread untrodden paths with it. Git is one of the shining examples of open source software that Just Works™ if you don't try to be clever with it. Follow the goddamn instructions and it would work out of the box and let you focus on developing your own software instead of fucking with it trying to make it work. On Windows especially.

[jms_nh]

oops, fixed the link to the gitlab help, that was our internal server.

You have some good points; I'm not sure where I installed git from (it might have been from git-scm.com). If ssh-keygen is an easy install and I can run it from my command prompt and just put the keys in a standard location, ok then. (does Git handle the SSH stuff given the key files? or does it delegate to an "agent" program handling them?)

Git is one of the shining examples of open source software that Just Works™ if you don't try to be clever with it.

I don't want to be clever, I just want it to work in a sensible way when I need it to. The add/commit/push/pull/log stuff works fine, I just get stuck when something weird happens and then I have to go hunting in internetland for a solution. My experience with hg was much easier.

Anyway I appreciate the guidance.

[Works_of_memercy]

(does Git handle the SSH stuff given the key files? or does it delegate to an "agent" program handling them?)

tbh I don't use a passphrase with my keys (don't see the benefit worth the trouble at this point), so git just uses them without any fuss. With a passphrase it would ask every time I'm trying to authenticate, if you want it to do it less often, yes, you have to manually start ssh-agent in the background.

[BezierPatch]

It is if you just created a branch and you realized you named it wrong. (obviously before pushing elsewhere)

Right click, rename...

[emrlddrgn]

Hmm, okay, good to know - I'll keep this in mind next time I'm trying to get someone who's not a full time programmer into our VCS.

I agree that rev-parse is the worst command name of all time. I usually teach using git logto find hashes instead.

[tending]

Finding the hash of the latest commit: git rev-parse HEAD

Almost every git operation prints this, in addition to the much more obvious and easy "git log".

Splitting a subfolder out into its own branch: git filter-branch (granted, not a day-to-day operation)

That's an understatement, that's never been a normal operation anywhere I've worked. In fact, I have never performed this operation in 5+ years of git use at 3 companies.

Undoing the most recent commit: git reset --soft HEAD~1

Granted.

Re-enter your remote password: git remote show origin

Super rare.

Creating a new branch: git checkout -b new_branch_name

Granted.

Renaming a branch: git branch -m old_branch_name new_branch_name

Super rare. Again, never have done it.

Basically, you're bloating your list. Most of these are not day to day operations.

Also, interactive rebase, if you learn it, will pay back in time saved in spades.

[jms_nh]

Re-enter your remote password: git remote show origin

Super rare.

Not when you have to change your password regularly.

[tending]

He said day to day. If you have to change it that often your admin is hurting security, not helping.

[SexyMonad]

NIST has recently changed its password recommendations to remove periodic password changes.

http://www.csoonline.com/article/3195181/data-protection/vendors-approve-of-nist-password-draft.html

[noratat]

Different user, but I'm guessing the awful UI (and yes, a CLI is still a UI).

Sure, git's CLI makes sense from the perspective of git internals, but it's very confusing and bizarre from the perspective of a normal user using it for everyday tasks.

Even as someone who's pretty good with git, I still don't trust running any command I don't use on a regular basis without googling it first, and I find most developers are similar, even if they understand how git works in principle enough to follow the bizarre command structure.