261–270 of 318 posts
Earlier quoted context omitted.
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.
TIL! The funny thing about Vim is that you can have used vi/Vim for 30+ years and still learn new things. I'll add this to the Vim appendix. Cheers!
Earlier quoted context omitted.
> Git is complicated _beacuse_ of this Right, but since git specifically was made for usage without decentralized servers, that complexity isn't accidental, it's purposeful as without serving that particular use case, git isn't really git anymore. Most design decisions in git comes from having to serve that use case, for better or worse. > . It's _so_ much simpler - because it's centralized Right, but that's also a p…
You’re looking for someone to suggest an alternative to a DVCS - git is the winner in that category. But if you go one step backwards and ask “do you really need distributed”, the answer for the vast, vast, vast majority of people is no, for the vast vast majority of use cases. To use your analogy it’s as if we all used rsync because it’s the best remote file management tool, but we use it locally because everyone el…
With GitHub being the top platform for sharing source code and as the top choice for the basket of all our eggs, I'd wager we need DVCSs more than people need or appreciate today. And that's just considering how often GitHub is down today.
If we start to emphasize with people who have really shitty internet connections (which is a larger part of the world than you seem to think), we can start to understand why it's really useful to be able to share our code with our co-workers on our local network without having to rely on terrible, minimum 5s latency connections to US companies who basically don't care about you.
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.
It tells me that git is the wrong tool for the majority of people but it just happened to stick.
No. Git is a complex program but version control is an inherently complex problem that requires powerful tools. There's certain set of problems where, as a programmer, you're going to have to sit down and actually read the book. The universe doesn't owe you an easy 10 minute video solution to everything, it's an annoying educational expectation that people seem to have developed. Some things are just that difficult a…
That's the thing. For most developers, it's not, and it doesn't. I have never needed a VCS that couldn't be wrapped in a few batch files like add.bat, get.bat, put.bat, diff.bat, merge.bat, and list.bat. You can do the same thing with git, of course, but just understanding enough about it to write the batch files practically takes a semester of study.
Unless your job is to maintain the Linux kernel, git is probably not the right tool for your job. But it 'won the source control war', so... git, it is.
Earlier quoted context omitted.
You’re looking for someone to suggest an alternative to a DVCS - git is the winner in that category. But if you go one step backwards and ask “do you really need distributed”, the answer for the vast, vast, vast majority of people is no, for the vast vast majority of use cases. To use your analogy it’s as if we all used rsync because it’s the best remote file management tool, but we use it locally because everyone el…
> the answer for the vast, vast, vast majority of people is no, for the vast vast majority of use cases. With GitHub being the top platform for sharing source code and as the top choice for the basket of all our eggs, I'd wager we need DVCSs more than people need or appreciate today. And that's just considering how often GitHub is down today. If we start to emphasize with people who have really shitty internet connec…
Note: centralized does not mean you can’t work in offline mode or share basic deltas
Earlier quoted context omitted.
The guide is comprehensive, on the other extreme, this one-pager contains 90% of git commands you'll ever need: https://wizardzines.com/git-cheat-sheet.pdf
It is quite bad and uninformative, you better not spread it.
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
There are two things I suggest as workflows for people when I teach them about rebase workflows.
> Since rebase “replays” your commits onto the new base one at a time, each replay is a merge conflict opportunity. This means that as you rebase, you might have to resolve multiple conflicts one after another. ... This is why you can conclude a merge with a simple commit, but ...
For multiple conflicts on several commits being replayed, if it's _not_ useful to go through them all one at a time, I suggest that people do a squash first rebase from the fork point (which by definition can not have conflicts) to collapse their commits into a single commit first, and then rebase again from the branch.
For instance, if forked from main:
git rebase -i `git merge-base main --fork-point`
git rebase -i main
"rerere" (https://git-scm.com/book/en/v2/Git-Tools-Rerere) will allow git to "reuse recorded resolution" so that you don't have to do them manually each time.
My gitconfig for these:
[alias]
forked = "!f() { git merge-base $1 --fork-point; }; f"
squash-first = "!f() { git rebase -i `git merge-base $1 --fork-point`; }; f"
[rerere]
enabled = trueHowever I'm seriously thinking about patching something together by grabbing appropriate bits of this.
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej