731–740 of 821 posts
Earlier quoted context omitted.
I think `git checkout` definitely needs to be there. Also `git reset` in case you make a mistake while `git add`ing
Added checkout. I'm not sure about classifying 'git reset' as an 'everyday' command.
“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217
Earlier quoted context omitted.
How is this any less technobabble? I looked up torsor on wikipedia. I learned nothing, except that "torsor" is a real word, and not just something you made up for a joke.
How could you possibly not have learned anything by reading the wikipedia page for "torsor" that starts with the following? In algebraic geometry, given a smooth algebraic group G, a G-torsor or a principal G-bundle P over a scheme X is a scheme (or even algebraic space) with an action of G that is locally trivial in the given Grothendieck topology in the sense that the base change Y × X P {\displaystyle Y\times _{X}…
Earlier quoted context omitted.
I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits? All sorts of workflows become substantially more difficult (if not impossible) with kitchen sink commits. Undoing a single-line change, for instance. I dislike large pull requests, let alone commits that introduce a half dozen different changes. Sure, if you’re really…
> porcelain without it encourage overly large commits? Not for me. When using Mercurial back in the day I would manually split up commit, usually by copying over sets of files into a clean repo and committing there. In Git tho the staging area is a lie. It encourages you commit half-truths. What I'd really want is to be able to enter a commit mode where the on-disk and staging area roles are flipped. I want the stuff…
https://github.com/tv42/staged does something like that by writing the staged content to a temp dir.
(It has some smarts for Go GOPATH adjusting on top, but might not do things right with modules, at this time.)
The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…
> The underlying technology of git is great I disagree. It is quite slow and makes the wrong assumption that everything should be text.
The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…
I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…
The main problem that I see with using git is that when you are part of a team, what kind of release and branching strategy should you use.
It's comparatively easy with one person team but becomes complicated with a team and even more if it's an open source project and now you have individual devs contributing their changes.
Earlier quoted context omitted.
I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…
You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squas…
It depends on your team's workflow, probably, but if you find yourself needing all of those daily, it seems to me like your workflow has some extra complexity that most people won't have.
> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=…
I found the author's apparent belief that Git and Github are the same thing extremely annoying. Github is a parasite.
> the quality of the tech that is Git is a testament to GitHub being able to make it this far in the tech space
But in reality, Github makes Git more complex, because now you have to understand the concept of forks. Not only is there your local copy and an origin, there is a 3rd repository in play.
Earlier quoted context omitted.
I think you're twisting the problem statement a little here. Asking "How do I unsend an email" is just as unreasonable as asking "Hey, give me that gift I gave you back". The problem is that, regardless of your intent, you've given something to someone and they own it now. You can't undo that without involving the 3rd party (Or breaking the law and stealing it, digitally for the email). And I want to be clear upfront…
> I have to laugh when you say its replacing email. Laugh all you like, but kids and the interns I've chatted with see email as something akin to how I feel about fax machines: not something they'd use by choice, but necessary for historical reasons. When I've been at organizations during a Slack adoption, email volume drops hugely; 50-80%, I'd guess. I've closed most of the mailing lists I used to run because they s…
At no point did I appeal to authority or history in my argument above, so drop the shit around
> "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices."
---
If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.
Earlier quoted context omitted.
That's a plausible reason, but it's definitely not what the person I was responding to said. "There are user reasons that won't work," is a very different answer than scoffing that the person asking the question just doesn't understand the underlying technology. I also don't think what you said is necessarily true. If person A has pushed and nobody else has pulled, then for most situations there's no reason to preven…
>I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior. Gitlab and Github (rightfully imo) came to this behavior. It was not random and is not the default git behavior which is to just allow the force push and all the chaos afterward. If you don't like it, mark your master branches as unprotected. However, there's clear reasons for the current defaults.
They seem entirely stuck in the assumption that there's a more powerful entity in the relationship that can arbitrate interactions between individuals.