191–200 of 318 posts
I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.
Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use Learning git like this is honestly just hampering yourself
Also, reusing branches for GitHub pull requests (vs. creating new branches for each PR) might warrant some discussion in section 17?
I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.
Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use Learning git like this is honestly just hampering yourself
> The Old Command: git checkout I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old. To be fair I started learning git a little less than 10 years ago but woah, I can't express how it feels that someone learning git today will be confused of why I use git checkout. Like using old fashioned language. More on topic, this guide would've been super useful when I wa…
I don't think "git checkout" is considered the "old alternative", at least not yet. Last time I checked, `switch` is still experimental, I haven't even considered moving away from the workflows/commands I first learned when I picked up Git ~15 years ago. Everything I want to do still works exactly the same (`git checkout` still does the exact same stuff as before), and I'm able to collaborate with everyone else using git, why change workflow then?
Earlier quoted context omitted.
If you do check it out and there are parts that are confusing, I'd love to hear about it.
This is partially a question and the rest is shameful confession: I had haltingly used cvs as a solo programmer, and when I was suddenly no longer a solo programmer and had to use git, everything went haywire. I am an Old and we never were taught anything about coding with other people who were also working on the same project. I have had many successful projects but never with another person. With that as a backgrou…
It's really simple, much more than what we think at first. I explained it myself here, in section "three-way merge": https://lucasoshiro.github.io/posts-en/2022-03-12-merge-subm...
There are plenty of other explanations out there if mine isn't enough clear for you, just google "Three-way merge".
> blend two functions or whatever and it "works."
It's purely based on find changes and it doesn't check the syntax. If the commits has been merge correctly is responsibility of the programmer.
Look at this valid Python code:
if a == 1:
foo()
bar()
if a == 1:
In Python we can't just leave empty blocks, like C or Java. In Python we would need to use "pass":
if a == 1: pass
So yeah, there are cases that merge doesn't work because Git operates over data, no matters too much what information they hold
Earlier quoted context omitted.
Out of curiosity, what are the most common foot guns, in your opinion?
How do switch to a branch? (Note that you need to fetch before you switch. Also switch is experimental but it’s not really) How do I undo a change and get it to other people on the team? - follow up, What happens if someone has made an unrelaydx change since? - someone has committed an enormous change and I want the commit immediately after it but the enormous change doesn’t affect me. How do I get that single file w…
What I'm curious about though, since I basically entered the software developer workforce just as Git became mainstream and GitHub became popular, how would you do those things with the alternatives at the time; SVN, Mercurial, Perforce and the rest? Would it be easier or harder? Would it work better/worse in a sync/async context, without centralized servers?
There are lots of people complaining about how needlessly complicated git is, but they almost always fail to put forward some simpler alternative that can handle the same things. Is git actually accidentally complicated or purposefully complicated because the topic at hand is kind of complicated?
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
Not wrong, but since you’re mentioning vim in the context of git, might be worth adding :cq as a way to exit with a non-zero status to prevent git from finishing the commit / operation.
Earlier quoted context omitted.
Find your last entry before the rebase using the reflog and reset your local branch to that entry. The work isn’t lost, it is sitting right there.
> Find your last entry before the rebase using the reflog and reset your local branch to that entry. You shouldn’t ever need to go to the reflog unless you’re in an exceptional case, and fit makes it very very easy to get into that exceptional case.
If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
Not wrong, but since you’re mentioning vim in the context of git, might be worth adding :cq as a way to exit with a non-zero status to prevent git from finishing the commit / operation.
Earlier quoted context omitted.
My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page. Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index…
This doesn’t work. Look: Commits are sets of files. They form a tree. A branch is a named location in this tree. The index aka staging area is a pre-commit that has no message. Workdir is just workdir, it doesn’t go in the repo unless you stage it. HEAD is whereafter commit will put new changes. Do I understand git? Seems like yes. Let’s run a quiz then! Q? A. How to make a branch? Git branch -a? Git checkout -b --ne…
You can switch branch also with ‘git checkout’ and you just ‘git stash’ your changes.
‘git reset’ is fine to reset files, but again if you just want to ”clean” repo you can stash.
You can reset staged files again with ‘git reset’
Mo idea why you would want to checkout a random commit and the start committing from that, but you can also just ‘git reset --hard HEAD~x’ where ‘x’ is number of commits you want to go back. Hard is optional, but I assume that is what you want based on your comment.
Depends on the change. If you change different lines there will be no conflicts.
This is all basic stuff you should know if you are developing code with other people