4 ms·

Ive been using git for 5 years now and i feel ive been using like the same 5 6 commands all the time. I dont understand these debates. Why would you need more

Ive been using git for 5 years now and i feel ive been using like the same 5 6 commands all the time. I dont understand these debates. Why would you need more ? Even when merge and rebase are getting out of hands, just take a good breath and use a bunch of manual cherrypicks.

Ekaros 4y ago
Perfectly fine when you are at clone, pull, push, add and commit level. Even stash isn't bad. But then you make mistake and need to figure out how to fix something even worse if stuff goes to remote...
- ostenning 4y ago
  It shouldn't be easy to rewrite history but it should be easy to change the email of the author retroactively
mrits 4y ago
You just need a single person on the team to learn the other commands. If you are good at fixing bad merges make sure you don't let anyone know.
- alkonaut 4y ago
  > If you are good at fixing bad merges make sure you don't let anyone know. Wish someone had told me this. But someone had to be the guy so push the team from Subversion, and that guy it is. “Stare not into the abyss, lest you are recognized as the team’s dedicated abyss starer” (Wish I could attribute this paraphrase of some Twitter genius)
alkonaut 4y ago
Same for me but “It’s fine I can always Google the solution” or “It’s fine I just use 5% of the functionality and that bit works well and I can remember it” isn’t really a stellar review of an UX either. The UX isn’t really tested at all when just using the 10% of the product even if that’s enough to do 90% of the job. It’s tested on that last 10% of tasks when we need to bring out that last 90% of git. I’m the unfortunate “git guy” of our team so my job is resolving people’s problems. Hooks and aliases oh non posix shells. Auth plug-in uses like windows/Mac auth store, problems with CI servers having made a checkout without LFS so borked their working copy etc. People creating branches differing only in case like /feature/Foo/2 and feature/foo/3 and all hell breaks lose when you have systems with mixed case sensitivity. Now add some monorepo pain like GVFS, or submodules or shallow checkouts etc and the warts really start to show.
nunez 4y ago
The problem is that outside of those five or six commands, Git gets really hard REALLY FAST. Let's use a common scenario as an example. Let's say someone accidentally committed a password into your codebase six months ago and pushed to remote. You can't delete just that commit because Git is a graph, so you have to modify the parent commit that contains the password _and every other commit after it_. So you discover `git filter-branch` which runs a shell script against matching SHAs. You run `man git-filter-branch` or `git filter-branch --help` but discover that (a) it can use special environment variables, none of which are documented here, (b) you notice that there are different types of filters, i.e. `env-filter`, `index-filter`, `tree-filter`, all of which require intimate knowledge of how Git works to use it. (I train junior engineers on Git often. Once you mention the "staging area" and "index", you'll usually lose them. I can't blame them...they just want to track their work!) You then try to run a `git filter-branch` command with the `--index-filter` since this can work against individual SHAs. Immediately, you get this: $: git filter-branch --index-filter '' WARNING: git-filter-branch has a glut of gotchas generating mangled history rewrites. Hit Ctrl-C before proceeding to abort, then use an alternative filtering tool such as 'git filter-repo' (https://github.com/newren/git-filter-repo/) instead. See the filter-branch manual page for more details; to squelch this warning, set FILTER_BRANCH_SQUELCH_WARNING=1. And then it just _hangs._ Since you know that going through six months of history can take a while, you think that it's working in the background. Nope, it just hangs there, waiting for you to CTRL-C instead of exiting with a non-zero exit code like EVERY OTHER CLI IN EXISTENCE. You go back into the `man` page to better understand this warning. Surprise surprise, `FILTER_BRANCH_SQUELCH_WARNING` isn't documented! So you provide the environment variable (if you know how, which isn't a given for junior engineers) and it finally runs...except you have no idea whether commits were rewritten or not (it does tell you whether the commits were rewritten, but you kind-of have to understand Git to understand the message). Now let's say you actually powered through and got it to run...but it caused you to lose work! (Remember, you have to `git push --force` or `git push --force-with-lease` to apply your changes, so this is stupid dangerous already, but it must be done.) To get it back, you then need to learn about `git reflog` and `git reset --hard`, but since `git filter-branch` runs against every commit that matched your pattern, you have to spend time scrolling back at the reflog to find the one you want to reset to. `bfg` exists to make this "simpler," but (a) it's a Java application, and you need to install the JRE to make it work, and (b) IT DOESN'T COME WITH GIT. Again, since this is a really common use-case with Git, it would be really nice if `git` had something more user-friendly, like: `git remove-references-to --regexp "PASSWORD" SHA_PATTERN` and a convenient message after the deed is done, like: 85 commits rewritten; run "git reset --hard [SHA_BEFORE_THE_CHANGES]" to undo. (Note: You must run `git push --force-with-lease to sync changes with your HTTPS-backed remote, "NAME_OF_REMOTE") However, since Git is maintained primarily for Linux development (afaict), this would most likely have to come from a third-party Git CLI. (I can already feel the rage from Linus for a proposal like this.) Funny enough, making things easier against the desires of protocol/system maintainers is how decentralized systems eventually centralize. I can see a world where everyone uses `gh` instead of `git` or has `git` aliased to `gh`, which means that a single company has de-facto control over the future of Git...

Ekaros 4y ago

Perfectly fine when you are at clone, pull, push, add and commit level. Even stash isn't bad. But then you make mistake and need to figure out how to fix something even worse if stuff goes to remote...

ostenning 4y ago
It shouldn't be easy to rewrite history but it should be easy to change the email of the author retroactively

mrits 4y ago

You just need a single person on the team to learn the other commands. If you are good at fixing bad merges make sure you don't let anyone know.

alkonaut 4y ago
> If you are good at fixing bad merges make sure you don't let anyone know. Wish someone had told me this. But someone had to be the guy so push the team from Subversion, and that guy it is. “Stare not into the abyss, lest you are recognized as the team’s dedicated abyss starer” (Wish I could attribute this paraphrase of some Twitter genius)

alkonaut 4y ago

Same for me but “It’s fine I can always Google the solution” or “It’s fine I just use 5% of the functionality and that bit works well and I can remember it” isn’t really a stellar review of an UX either. The UX isn’t really tested at all when just using the 10% of the product even if that’s enough to do 90% of the job. It’s tested on that last 10% of tasks when we need to bring out that last 90% of git. I’m the unfortunate “git guy” of our team so my job is resolving people’s problems. Hooks and aliases oh non posix shells. Auth plug-in uses like windows/Mac auth store, problems with CI servers having made a checkout without LFS so borked their working copy etc. People creating branches differing only in case like /feature/Foo/2 and feature/foo/3 and all hell breaks lose when you have systems with mixed case sensitivity. Now add some monorepo pain like GVFS, or submodules or shallow checkouts etc and the warts really start to show.

nunez 4y ago

The problem is that outside of those five or six commands, Git gets really hard REALLY FAST. Let's use a common scenario as an example. Let's say someone accidentally committed a password into your codebase six months ago and pushed to remote. You can't delete just that commit because Git is a graph, so you have to modify the parent commit that contains the password _and every other commit after it_. So you discover `git filter-branch` which runs a shell script against matching SHAs. You run `man git-filter-branch` or `git filter-branch --help` but discover that (a) it can use special environment variables, none of which are documented here, (b) you notice that there are different types of filters, i.e. `env-filter`, `index-filter`, `tree-filter`, all of which require intimate knowledge of how Git works to use it. (I train junior engineers on Git often. Once you mention the "staging area" and "index", you'll usually lose them. I can't blame them...they just want to track their work!) You then try to run a `git filter-branch` command with the `--index-filter` since this can work against individual SHAs. Immediately, you get this: $: git filter-branch --index-filter '' WARNING: git-filter-branch has a glut of gotchas generating mangled history rewrites. Hit Ctrl-C before proceeding to abort, then use an alternative filtering tool such as 'git filter-repo' (https://github.com/newren/git-filter-repo/) instead. See the filter-branch manual page for more details; to squelch this warning, set FILTER_BRANCH_SQUELCH_WARNING=1. And then it just _hangs._ Since you know that going through six months of history can take a while, you think that it's working in the background. Nope, it just hangs there, waiting for you to CTRL-C instead of exiting with a non-zero exit code like EVERY OTHER CLI IN EXISTENCE. You go back into the `man` page to better understand this warning. Surprise surprise, `FILTER_BRANCH_SQUELCH_WARNING` isn't documented! So you provide the environment variable (if you know how, which isn't a given for junior engineers) and it finally runs...except you have no idea whether commits were rewritten or not (it does tell you whether the commits were rewritten, but you kind-of have to understand Git to understand the message). Now let's say you actually powered through and got it to run...but it caused you to lose work! (Remember, you have to `git push --force` or `git push --force-with-lease` to apply your changes, so this is stupid dangerous already, but it must be done.) To get it back, you then need to learn about `git reflog` and `git reset --hard`, but since `git filter-branch` runs against every commit that matched your pattern, you have to spend time scrolling back at the reflog to find the one you want to reset to. `bfg` exists to make this "simpler," but (a) it's a Java application, and you need to install the JRE to make it work, and (b) IT DOESN'T COME WITH GIT. Again, since this is a really common use-case with Git, it would be really nice if `git` had something more user-friendly, like: `git remove-references-to --regexp "PASSWORD" SHA_PATTERN` and a convenient message after the deed is done, like: 85 commits rewritten; run "git reset --hard [SHA_BEFORE_THE_CHANGES]" to undo. (Note: You must run `git push --force-with-lease to sync changes with your HTTPS-backed remote, "NAME_OF_REMOTE") However, since Git is maintained primarily for Linux development (afaict), this would most likely have to come from a third-party Git CLI. (I can already feel the rage from Linus for a proposal like this.) Funny enough, making things easier against the desires of protocol/system maintainers is how decentralized systems eventually centralize. I can see a world where everyone uses `gh` instead of `git` or has `git` aliased to `gh`, which means that a single company has de-facto control over the future of Git...