High-Level Problems with Git and How to Fix Them • Hacker News Board

Re: High-Level Problems with Git and How to Fix Them

#291

Post by Sheeriapi » Thu, Dec 14, 2017, 5:38 PM UTC

cryptonector wrote: post #268

cannam wrote: post #138

This is a really interesting piece that introduced a number of ideas I hadn't ever thought deeply about, particularly in the section on nameless workflow. (I do think of myself as reasonably capable with both Mercurial and Git.) If your instinctive response is to defend Git, boost Mercurial, ridicule people who can't use their tools, ridicule the tools for being unusable, or whatever -- suppress it for a while and gi…

My instinctive response is to explain why git is easier. TFA is very unfortunate. I think the author is missing out on a better experience, and their git hate isn't helping them.

Let me suggest to suppress that instinct and read the article again. There's not a shred of "git hate". Quite the contrary: The author is a Git user himself and has detailed suggestions to improve Git and its ecosystem. That is a good thing, not "very unfortunate". Also, Git is easier than what exactly? Than the proposed improvements? I suspect you haven't read the article. This is neither a "Mercurial vs Git" nor a "Git sucks" piece, which you should have noticed while reading.

Re: High-Level Problems with Git and How to Fix Them

#292

Post by marvy » Fri, Dec 15, 2017, 2:26 AM UTC

j_s wrote: post #273

Klathmon wrote: post #17

Earlier quoted context omitted.

> A better VCS isn't going to solve that! It might! I feel like a "language aware" VCS would be able to help a lot in this area. I know there are 3rd party tools that can do this, but if a VCS came along that natively knew about some languages it could unlock some really cool features. Imagine instead of your VCS storing the text source, it stores the AST! Language aware means it can also integrate tightly with langu…

This discussion won't see much more now that it's off the front page, but is there any work towards full undo support integrating with version control or even at the IDE level? There's a lot of stuff that doesn't get checked in; I wouldn't necessarily want it all in the official history but it would be amazing to have a time-searchable view of the project's entire development story for my own personal review/rescue o…

https://www.jetbrains.com/help/idea/using-local-history.html

Re: High-Level Problems with Git and How to Fix Them

#293

Post by cryptonector » Mon, Dec 18, 2017, 4:51 AM UTC

fulafel wrote: post #282

cryptonector wrote: post #264

Earlier quoted context omitted.

There's three ways to deal with the git index/staging area: - always commit everything, merge/push that (Mercurial style) - always commit everything, then eventually do a rebase where you merge/split commits into logical units - always git add -e then commit logical units I do mostly the latter, but since I don't usually write code the way I want it in the end before pushing, I almost always have to go back and rebas…

A goal of producing a "nice, clean, logical, and minimal" history, as opposed to preserving history, is very opinionated, as I'm sure you're aware. I think it's not something most people should attempt voluntarily - If you want "nice, clean" waypoints, just diff between the relevant merge commits, and read their commit messages.

Yes, but git doesn't force you to do this -- you can be as messy as you like with git, knock yourself out. Git is NOT opinionated. I am opinionated. But Mercurial and others don't make it possible (or easy) to get nice, clean history, therefore they are inferior.

And no, "just diff between merges" is NOT nice and clean. It bundles lots of changes together, therefore you can't easily separate them without actually understanding all of it. The cognitive burden of reading diffs is high. The cognitive burden of reading commit subjects and messages is lower -- much much lower.

One really does have to be considerate of the people who will be maintaining one's code in the future. Even that will be you yourself, you should still be considerate to your future self.

When you work with codebases measured in Mloc or Gloc, you really need the code and its history to be accessible. This is obvious to people who have worked with such codebases. It's less obvious to people who haven't, but it it's still true.

Re: High-Level Problems with Git and How to Fix Them

#294

Post by nurettin » Mon, Dec 18, 2017, 5:51 AM UTC

forgottenpass wrote: post #239

nurettin wrote: post #10

>> And the Git staging area should be an opt-in feature. Thousands of yes! `git commit -a` just doesn't add the untracked files it is the most annoying misfeature of any version control system. Oh, I added unwanted project directories? I would then just remove them and put them to `.gitignore`, or create a `.gitignore` prior to `init`. Of course I could just alias `add -A . && commit -m` on every machine I ever conne…

Of course I could just alias `add -A . && commit -m` on every machine I ever connect to for developing. There's a great, practical solution. Maximally practical or not, if you don't already have a repository for configuration files, shell scripts, aliases, and other little quality of life enhancements then create one today. Your git workflow isn't the only thing that will benefit. Next time you're hassled to do yet a…

I did try this, but it comes with the extra work of managing yet another git repo, which you conveniently ignore. It requires workarounds such as making a bare repo, turning off showing untracked files, then you have branches for multiple computers and it's all a mess in no time.

Perhaps there is a better alternative to saving and loading your dotfiles?