Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…
What comes after Git
221–230 of 430 posts
Re: What comes after Git
#222Earlier quoted context omitted.
Knowledge of git has become a sort of status signifier. It "makes you a developer". I think for this reason there's a lot less pushback on its bad UX than there would be for any other program. It would render knowledge of its arcane guts less...special. The juniors will be forced to deal. It makes me wonder though, if needlessly arcane knowledge is and always was a part of other apprentice relationships.
How do you improve the ux though? I see a lot of complaints about it, and agree that for all the porcelain, you do have to become familiar with the plumbing to solve issues. But noones shown me a good alternate ux story, just different porcelain/fittings. I still have to reach under the sink because said new porcelain didn't stop/avoid a case sensitivity clash, or it barfed on a merge and left the repo still to merge…
Mercurial and Git have, for most purposes, functionally identical capabilities. Atlassian at one point allowed you to checkout a project as either a git or a mercurial repo painlessly.
Mercurial's porcelain makes sense: the command is exactly what you think it is, usually without any funky modifying flags. If there are flags, they're often obvious, and if they're not, hg help will clear that right up.
Contrast to git, which is a mishmash of commands and esoteric flags, and the help isn't even inlined.
The underlying concepts are easy enough, but how you access them requires memorization of arbitrary command sets that are inconsistent and overloaded.
Fix the porcelain and IMO you fix most of the problems with Git.
Re: What comes after Git
#223Earlier quoted context omitted.
Yes, and it matches the definition of an "operating system". Originally, an "operating system" is a system that takes the role of an operator. In the early days, operators were people who loaded programs, feed them data, fetched the results, etc... for the users. Matching the modern definition of an interface between the user and hardware. Kubernetes allocate servers (hardware) to containers just like a typical OS al…
> Yes, and it matches the definition of an "operating system". No, it does not. An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs. [1][2] You cannot just arbitrarily take long-established technical terms and redefine them to suit your needs or your rough intuition. If you look in the authoritative sources below, there are…
"Operating systems" in a much narrow sense were invented in the 1950s. I cannot tell you what people meant by the term back then. Then it seems that they accreted features. And then they accreted more features, like a gigantic snowball or avalanche. Ultimately, this all happened because people were lazy and didn't want to repeat themselves -- and there were lots of things to be lazy about. Also, branding and marketing became important. And now an operating system is defined by its user interface guidelines, the artwork in its GUI, what web browser it comes with, and what other software it does/does not ship with. Some people gerrymander the meaning of the word to justify the architectural choices of their favoured operating system.
By the way, being able to parrot the dictionary's definition of a term doesn't mean you know what it means. And knowing what something "means" (that is, knowing how to use it) does not mean you know its dictionary definition. The education system often forces people to remember these things and regurgitate them, which serves only to help you sound convincing in debates.
Re: What comes after Git
#224Earlier quoted context omitted.
Interesting exercise. Mine looks more like: - push/fetch: I personally never liked pull, it's sugar over fetch and merge/rebase. - checkout -b: haven't looked into all the switch stuff yet - rebase -i: my bread and butter. I rarely use merge aside from PRs where rebase bugs people. - add/commit -am: obviously required - cherry-pick/reset: pretty much replaces stash without introducing a whole new set of tools - diff/…
lately i’ve been using stash, reset hard, stash pop. work on a single patch over main. use a backup branch prior to stash, just in case.
Re: What comes after Git
#225I've been using fossil ( https://fossil-scm.org ) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are - 1. Single file executable. No dependencies to "install". Just the executable and you're good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name…
(A long-time fossil dev here...) Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is abso…
I wonder why so few developers consider the scenario you describe. Git fits the development of Linux. But, a question rarely raised: why is Git considered suitable for small or medium projects?
Re: What comes after Git
#226Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and…
For very large projects (eg Linux-scale or Windows-scale) I can totally see why it is the best versioning solution. But most software isn't like that: it's relatively small teams maintaining a legacy codebase and making fairly incremental enhancements. I struggle with what git brings to that vs the cognitive overhead of using it.
I've recently migrated a moderately large codebase from TFS to GitHub. A large part of what drove that was co-workers who were reluctant to use TFS - I suspect that they found it old-fashioned, and that kind of bothers me, even though git is clearly the future and TFS clearly isn't. I like diversity of tools, and tools that don't force me to think too hard about things that should be easy. The knowledge that git could turn into a foot-gun just when I most need to get things done, doesn't help.
After some consideration, I think what I'd like is a tool that gives me a simple SVN-style UX over a real git repo, with the option to drop down into actual git of necessary, and so that colleagues can use only git if they prefer. Github desktop partly achieves this, as does Visual Studio's git integration, but it's not quite what I want.
(Not a git hater. I've had a github account for over a decade and choose to use it a lot for personal projects. But mostly just simple, sequential check-ins over time.)
Re: What comes after Git
#227Earlier quoted context omitted.
I was learning git around the time `switch` and `restore` were introduced to tackle the problem of checkout being overloaded. I started using the new commands and it instantly made more sense and began to click. I very rarely use checkout at all. Something to be aware of when training junior devs. Do them a favour and learn switch/restore first!
I think this is the first time I've heard of switch and restore. Before I moved to magit I always used git checkout and git reset.
Re: What comes after Git
#228Earlier quoted context omitted.
Rebasing other’s stuff feels gross since it is altering externally visible history. Rebasing your own stuff before you push can make commits more clear, understandable, and meaningful. git pull —rebase is pretty unobjectionable. How does rebasing break bisect?
Presumably they are referring to how the `--first-parent` flag works as it only uses the head of the branch from a given merge instead of including each commit from the merge. Some projects prefer rebasing onto master instead of merging onto master or squashing onto master. If you rebase onto master but don't clean up the commits at the end of the PR, this litters master with a bunch of "top level" commits that don't…
The whole beauty of bisect is that is a binary search where if you double the number of commits you only need to do ~1 additional check. So no, it can't take "way" longer.
And it's not like you'd call it a day after finding the merge commit that breaks things - you then need to find the actual problem with that branch and the fastest way to do that is bisecting down to the individual commit so you are actually doing the same work but artificially restricting git bisect from evenly dividing the search space by restricting it to merge commits first.
Re: What comes after Git
#229>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level. I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below. Kubernetes didn't brought open-source collaboration to a new level. No matter how relev…
Also GitHub is the defacto monorepo? Since when you can fork/clone code in a monorepo? The whole point of monorepo is to avoid that!
Re: What comes after Git
#230Earlier quoted context omitted.
> It's when you move a file and make substantial edits that it gets confused. It's your POV that it's the same file. One could argue that it's a new file and the content of the old one embed in the file. That's the huge problem with git users, people cling desperately to the idea of changes, when git is just about snapshots.
People "cling desperately" to the way they are actually working. That Git uses an alien model that happens to somewhat match what I'm doing doesn't mean I'm "desperately clinging" to the actual reality of what I'm doing (editing a file).