351–360 of 430 posts
Earlier quoted context omitted.
> I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same. The big advantage of git is github and co, not git itself. By switching and using mercurial you lose all of the advantages of github too.
Or there's sourcehut so you can use Hg. https://sr.ht
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…
Earlier quoted context omitted.
Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. Sometimes basic operations like merge need separate role (human) to perform. Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git) I know you have no time to know your tool. But I don't…
Mercurial is also great for rebasing (that's cherry picking in Git terminology - not the same as git rebase!). If I had experimental changes, I would often just commit things and mark them as private (so they wouldn't get pushed) rather than shelve (the Hg equivalent of git stash). Then, when I actually wanted them, I would rebase them on to the most recent revision (using --keep so the originals were still there if…
I’d love to move away from parent commit hash being included in a commit hash. It makes rewriting history so complex.
Earlier quoted context omitted.
> I think that it is possible to add local branches and commits to centralised version control Well, you think wrong, because it's not. Centralized change control will contact the central server for every change. If you can make local commits, it's decentralized source control. Prove me wrong: show in the SVN or p4 or CVS documentation where you can create local branches or commits while the central server isn't reac…
I believe that - hypothetically - centralised version control can have disconnected local commits with private local branches. But using GitHub as a single source of truth for git repositories makes git mostly centralised. Think of it as of SVN with local commits and a central repository on GitHub (with its UI). And with awkward git’s CLI. I don’t think that SVN, p4 or CVS have support for local commits. What I want…
The fact that you keep coming back to github to "prove" it's somehow centralized at the vcs level is clearly you just doing some contrarian trolling.
Earlier quoted context omitted.
Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. Sometimes basic operations like merge need separate role (human) to perform. Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git) I know you have no time to know your tool. But I don't…
Mercurial is also great for rebasing (that's cherry picking in Git terminology - not the same as git rebase!). If I had experimental changes, I would often just commit things and mark them as private (so they wouldn't get pushed) rather than shelve (the Hg equivalent of git stash). Then, when I actually wanted them, I would rebase them on to the most recent revision (using --keep so the originals were still there if…
Every 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…
> marvel at how it ever became popular. It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-2012 or so. The dvcs systems won because they changed a bad paradigm to one that's much much better - literally the way you think about version control these days is a radical departure from the previous way it was done. Merges are much much nicer in git then t…
Earlier quoted context omitted.
> I think that it is possible to add local branches and commits to centralised version control Well, you think wrong, because it's not. Centralized change control will contact the central server for every change. If you can make local commits, it's decentralized source control. Prove me wrong: show in the SVN or p4 or CVS documentation where you can create local branches or commits while the central server isn't reac…
I believe that - hypothetically - centralised version control can have disconnected local commits with private local branches. But using GitHub as a single source of truth for git repositories makes git mostly centralised. Think of it as of SVN with local commits and a central repository on GitHub (with its UI). And with awkward git’s CLI. I don’t think that SVN, p4 or CVS have support for local commits. What I want…
Earlier quoted context omitted.
Git has a terrible UI from a learning point of view. You can't learn Git by using its commands. You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Because Git is really just a brilliantly simple data structure manipulated by dozens of ad-hoc commands.
Is there any other soft where ppl do seriously advise newbies to learn its internals? Everywhere it'd bee seen as a flaw from ux standpoint, but git gets a "pass" Imagine having to read excel's or windows code in order to use it consciously, lol.
Earlier quoted context omitted.
Mercurial is really nice. I find its CLI interface much less confusing than Git's. I think a lot of this has to do with Git's "index" where you have to "add" files and then "commit" them. This seems like the #1 source of confusion when people are learning Git and persists into operations like "rebase" and "cherry-pick" where the index is used for marking conflicts as resolved or not.
I personally always liked the flexibility the stage offers.