Many of these problems can be avoided by using a pull-request style workflow.
Oh shit, git (2016)
21–30 of 280 posts
Re: Oh shit, git (2016)
#22> I committed and immediately realized I need to make one small change! I think it might be nice to add a disclaimer saying that this is not advisable if you've already pushed the code. Suck it up and make a new commit–don't rewrite public Git history.
I think changing history is fine on feature branches that only you are working on, though. IMO the benefits of keeping commit history clean outweigh the cost of having to push with "--force".
This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect.
Or, someone might have created another branch off your feature branch, because they depend on your work. Now you've creaed a time bomb for them when they try to merge their work after you've merged your alternative-history version of it. (and the failure mode is just weird, it takes experience to identify that all those seemingly nonsensical merge conflicts are result of this situation)
Etc. It just breaks a lot of things. The Git model and bad UI are already taxing enough to work with in your head, concurrently with your actual programming and domain cognitive load, that adding the uncertainty and multiplied complexity from having history rewritten around you is just a bad tradeoff.
(This may be different if the scenario is not a team, of course...)
Re: Oh shit, git (2016)
#23> I committed and immediately realized I need to make one small change! I think it might be nice to add a disclaimer saying that this is not advisable if you've already pushed the code. Suck it up and make a new commit–don't rewrite public Git history.
Like a few other replies, I force push on my branches all the time.
I push my code up to my origin as soon as I can and as I go I’ll fix up my commits and force push.
There are some advantages for me anyway. Pushing to origin kicks off some smoke tests and end to end tests that are fairy slow and cumbersome to run on my dev machine. That helps me catch bugs earlier, especially since I’m working on a Microservices architecture. Also it acts as a backup for if my dev machine dies on me. I prefer to fix up and force push to create a clean logical story from my code rather than leave in spurious commits which exist only to fix linting for example.
Re: Oh shit, git (2016)
#24Honest to god, I don't know how people who find `git` hard to use manage to write code. Everyone on the Internet acts like the concepts are impossible to grasp and it's like really easy to grok. Honestly, it faded into the background of code from the beginning. I mean, I know "Forward-port local commits to the updated upstream head" means nothing to anyone not already familiar with `git rebase` but a practical master…
OK hot shot. Tell everyone here how you've never fucked up commands and had to blow out a repo and start over and how were all idiots for having done that.
It's a tool. Any tool can be confusing if the person isn't taught how to use it. Git requires teaching so there's a lot of room for misunderstanding.
Re: Oh shit, git (2016)
#25This has been immensely useful every now and then
Re: Oh shit, git (2016)
#26Earlier quoted context omitted.
I think changing history is fine on feature branches that only you are working on, though. IMO the benefits of keeping commit history clean outweigh the cost of having to push with "--force".
This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect. Or, someone might have created another branch off your feature branch, because they depend on your work. Now you've creaed a time bomb for them when they try to merge their work after you'v…
you just rebase on top of their changes. No biggie here. It does not matter one bit if their branch rewrites itself underneath.
Re: Oh shit, git (2016)
#27Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…
Don't gatekeep. Git isn't just for programmers.. it's for people that are learning.. people using it in non programming capacities and tons more. Telling people to "git gud" is not helpful. Not everyone knows, or indeed cares to know what a Directed Acyclic Graph is, and sites like this help people's anxiety who are just learning, or who have already screwed up and just want a solution.
Git is just for programmers. It was made by and for kernel developers, no less. There are better tools for other people.
If you don't care what a DAG is, you will never understand what git is or what it's for. No arguments. Git is a tool for building a DAG. If you don't need a DAG you don't need git.
Re: Oh shit, git (2016)
#28Honest to god, I don't know how people who find `git` hard to use manage to write code. Everyone on the Internet acts like the concepts are impossible to grasp and it's like really easy to grok. Honestly, it faded into the background of code from the beginning. I mean, I know "Forward-port local commits to the updated upstream head" means nothing to anyone not already familiar with `git rebase` but a practical master…
yes. If it is this hard to understand rebasing, how can there be understanding of other programming core concepts?
Re: Oh shit, git (2016)
#29Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…
Git isn't hard but it's usually taught like absolute shit. From the get go you're told to use 4 commands, 2 of which are usually not explained and when they are it's often hand wavey. From there on its usually people pontificating about high level philosophy while failing to give concrete working examples. At least that was my experience.
I'm decent at got now for the work I do so I'm cool with it. It really is an awesome tool. But for some reason its just collectively taught like shit.
Re: Oh shit, git (2016)
#30Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…
I care about the internals of git about as much as I care about the internals of my filesystem. It's probably helpful to know some basics, but do I need to know intimate details of my filesystem to use cp, mv, shell redirection? No. For most basic actions it Just Works ™. The problems in git are purely user-interface based. Other distributed systems have proven you can make a dcvs with a reasonably friendly UI.
That's because a file system is something you already understand, even if you've never actually used an old fashioned paper filing system. The software is providing you with something you understand.
Git is not providing you with something you understand. It is providing you with a DAG and you neither understand what that is or why you need it. The DAG is not the "internals of git". This is the big mistake. It is git. Everything about git is about building that DAG.