Modern Git replacements/extenders like Sapling, Jujutsu, Gitbutler usally add to Git these features: you have a stack of commits and you can improve them, iteratively, adding things to commits, splitting or folding them; the way you fix merge conflicts is saved, so when you change the commit history again or receive changes upstream, many merges can be reapplied automatically; the history of changes is saved in a log and you can undo/redo and review what you have changed in the repo, not only in the files.I didn't understand what the real problem is with Git?
The history of git is interesting. There are ancillary lessons to learn too.It just seems like programmers keep trying to follow some bus somewhere. Like greener pastures when they don't exist.
There is always some better scheme to sell.
I find the terms in git just wrong. I think the verb tense direction is often wrong.I have always considered git to be a pain in the rear.
I've heard Americans say that. Another phrase that drives me nuts is, "Me and my friend are going to the store". I learned in my first years of schooling that you put the others first in a sentence. "My friend and..." You can then check the phrasing by leaving the 'friend' part out like, "Me going to the store." You wouldn't say it that way.I've had Swedish and Finnish flatmates use the English phase "Will you borrow me 20 dollars?"
That is from dating where "my friends" is a secondary noun group with the "me" and the unspoken noun "you" are the primary. We could fix this with stuffing suffixes on worlds like latin. Maybe we can get the author of Perligata to look at the git syntax too.Another phrase that drives me nuts is, "Me and my friend are going to the store".
Language is fascinating. I'm Italian, and I would say something like "I'm going to the store with my friend", but "Me and my friend are going to the store" implies the fact that both me and my friend are interested into buying something, while the former not necessarily.I've heard Americans say that. Another phrase that drives me nuts is, "Me and my friend are going to the store". I learned in my first years of schooling that you put the others first in a sentence. "My friend and..." You can then check the phrasing by leaving the 'friend' part out like, "Me going to the store." You wouldn't say it that way.
I agree with mer, everyone should write computer programs!If everyone spoke american english, it would be so much easier.
Maybe not as much fun, but easier.
And before anyone gets upset, that is a joke.
Your experience is a bit different than mine. I've found that most non native speakers prefer to be corrected. (Though privately, if possible).Of course, you can't correct people cause they would be offended.
Rust, Algol, Cobol, PL/1, LIsp, Prolog, Befunge, Piet?I agree with mer, everyone should write computer programs!
...because programming languages are based on english.
You haven't worked with any Chinese Perl programmers, have you...I agree with mer, everyone should write computer programs!
...because programming languages are based on english.
I know the rules, but saying it like that casually sounds oddI've heard Americans say that. Another phrase that drives me nuts is, "Me and my friend are going to the store". I learned in my first years of schooling that you put the others first in a sentence. "My friend and..." You can then check the phrasing by leaving the 'friend' part out like, "Me going to the store." You wouldn't say it that way.
Of course, you can't correct people cause they would be offended.
Many of us (me for sure) are lazy. For learning and remembering subtle details of a foreign language, I had to make exercises.The putting me or I first is usually a sign that a person hasn't been taught correctly, or these days, wants to show that they're not educated. If they're non-native speakers of course, it's less important in my opinion.
Likely this is more about being aware of who (in your team) is working on what and being able to look at their work in progress. I take at least a cursory look at most every FreeBSD commit. It would be nice to know what changes are upcoming in some areas of interest, associated tests, PRs, documentation etc. Not sure how well this can scale when the "team" consists of 100+ people working remotely.That's what coding needs. It needs to be social.
I've been doing this with plain Git for at least ten years.Modern Git replacements/extenders like Sapling, Jujutsu, Gitbutler usally add to Git these features: you have a stack of commits and you can improve them, iteratively, adding things to commits, splitting or folding them; the way you fix merge conflicts is saved, so when you change the commit history again or receive changes upstream, many merges can be reapplied automatically; the history of changes is saved in a log and you can undo/redo and review what you have changed in the repo, not only in the files.
Sigh, nobody appreciates the finely curated commits in my merge requests. I try to group changes thematically so they're easier to review. I'm literally the only person who does that where I work.It is easier having a polite history, because commits (expecially not pushed commits) are more "fluid".