221–230 of 352 posts
> This usually happens to me if I merge to master, then run tests/linters... and FML, I didn't put a space after the equals sign. Am I the only one that runs my tests before committing, let alone merging to master?
Yeah, pushing untested code to master is not such a great way to work. Push to a remote branch other than master, test it there, then merge it into master. That's pretty much git 101
I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than m…
I think the biggest problem people have with git is that you can't and shouldn't want to change shared history, and yet git provides some tools that suggest that maybe you can. It's better to accept history as it is, and fix the problem with reverts, cherry-picking and new commits. History won't be as pretty or clean, but it will reflect what actually happened, which is what history is, after all. The biggest trick t…
See, I fundamentally disagree that this is what I wanted. When I merge my thing with change x into head I expect to see my changes actually go in. Not to see commits retroactively added to head. The merge was the action, not some weird rewriting of historical order of events.
> The biggest trick to understanding git is to learn to think in commits rather than file content.
Ok, I'm starting to see what you meant. (I didn't understand this until the second part and my being confused as heck)
One of the nice workflows that's already built in to the git command line tools is this one. When you're working on a branch and realise that a commit you made a few commits back has a mistake in it: # Make correcting change git commit --all --fixup= # Continue working on branch, then at some point git rebase --interactive --autosquash The --fixup option creates commits with subjects formatted like 'fixup! previous c…
Yeah, super useful, I can second setting auto squash in the config. I was almost thinking of saying the same thing, but I realized this post is probably deliberately avoiding rebase. This workflow is advanced relative to the problems described, and you'd agree those command lines are going to look pretty intimidating to a novice, right? They were to me the first time, there's a lot to understand before they're comfor…
Yeah, true. I posted it mostly because one of the bigger threads of comments was advocating using a GUI instead of the CLI. I'm not going to argue that the git CLI is simple, but it does have some nice features to support specific common workflows.
One thing not covered very well was what to do if you push to origin. My favourite way to fix this: use git revert to create an exact opposite commit to your bad commit. git revert git push It leaves a history of the mistake, for better or worse, but it does undo the mistake on origin.
One thing not covered very well was what to do if you push to origin. My favourite way to fix this: use git revert to create an exact opposite commit to your bad commit. git revert git push It leaves a history of the mistake, for better or worse, but it does undo the mistake on origin.
Earlier quoted context omitted.
it was really hard for me to understand vim until a website explained it as being a set of grammars you can learn. i agree, if you really want to be more productive (and without having to go find some git expert on your team) knowing how each operation works and why its doing what its doing is really beneficial. despite that, its sometimes frustrating due to inconsistencies in the git "grammar" that i sometimes don't…
The absolutely easiest way to learn vim is to just schedule a reminder every ... month? week? to run "vimtutor". Then do that for a few minutes until you get frustrated or want to do something else. It's shocking how fast you'll learn.
Thank you!
Earlier quoted context omitted.
sorry... you come across as a git-sheep. (getting down-voted for it, but someone has to say it)
I'm prepared to give you a lot of examples (which other people might value differently). From the unfortunate consequences of the 'branches are files (and therefore tags are easily mutable by default and surprisingly hard to pin down)' to usual "I just committed, why does 'svn log' not show that?", to git bisect, to git clean and the stubbornness with which svn refuses to even consider implementing that.
lots of these are unnecessarily complicated: > Oh shit, I accidentally committed something to master that should have been on a brand new branch! # disappear the last commit and all changes from it git reset --hard HEAD^ # make a new branch using the last commit git checkout -b new-branch HEAD@{1} > Oh shit, I accidentally committed to the wrong branch! first, you don't need to git-add before and after stash, stash w…
I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…
I'm curious: What are the best free GUI for Git?
Is the documentation really that bad? Would it benefit from a technical writer going over it? Is the project open for discussion on changes to the documentation?
Git is like Perl. And not in any of the good ways. Perl 5 -- I don't know enough about 6 to know whether this is still the case -- involved a couple of design decisions which worked well for one subset of people and did whatever the complete polar opposite of "works" is for a different subset of people. One of those design decisions is the famous "there's more than one way to do it". Ask five Perl programmers to solv…