19 ms·

What’s wrong with Git? A conceptual design analysis (2016)

142 points by edward 6y ago

runningmike 6y ago
conceptual designs should be created before. Not afterwards. Using it for analysis of a product will of course create a complicate view since evolution of a product is missed.
- ketzo 6y ago
  This feels more like a learning exercise than an actual critique of git that would necessitate some kind of response. I thought it was a useful way to practice thinking about software design with a tool I already know.
  - ajarmst 6y ago
    They should perhaps revisit their title, then.
    - ketzo 6y ago
      I mean, it's absolutely a criticism of git, so in that sense the title's spot on; it's not a pull request, or a suggestion that we should all go out and stop using git. I mostly took issue with GP's implication that there was no reason to perform a conceptual design review after the software's already created.
- crazygringo 6y ago
  Huh? This is a critique of the conceptual designs, which is valid. And an improvement upon them IMHO. I don't understand what you're arguing.
williesleg 6y ago
It's not China?
ajross 6y ago
All the examples[1] are about the index. And indeed, the index is probably a feature that should have been optional. While it's supremely useful for maintainer-side operations (splitting patches, picking out parts of them, committing only the meat of a patch and not debug code, etc...) it's really not useful for a typical new user. At all. New users would be best served by a "commit" variant that simply updated the HEAD commit in place. [1] Actually not the last one. I couldn't figure out what they were talking about. "Only committed versions of a file can be part of a branch" -- I mean... duh? Branches are a DAG of committed trees. I don't understand what they're asking for when they complain that the working version of a file can't be part of more than one branch. It's not part of any yet!
- tsimionescu 6y ago
  The problem they are talking about is that you can't checkout a new branch wothout first committing, stashing or undoing your work. In other VCS tools, including gitless apparently, your uncommitted work is also branched (usually by virtue of different branches being chekced out in different directories on disk). You can also achieve this in Git by using different working trees.
  - ajross 6y ago
    Ah, OK. And this is why I think lots of criticism like this is a little off the rails. It's too dependent on what to my eyes is just a broken mental model. I mean... branches are commits. If you want your uncommitted work to be on a branch you... commit it. There's a command for that. It's called "commit". I mean, literally "git commit -a -m WIP; git checkout $OTHER_BRANCH" is all that's required. It's even "orthogonal" per the requirements in the article.
    - geofft 6y ago
      This is the workflow I follow, but my experience is it's pretty high-mental-overhead in practice - Git doesn't draw a distinction between commits that I created because I'm still working on something and want to switch branches, and are therefore reasonable to modify, and commits that came from some remote source and which you want to keep intact. They're both "commits." That means you, the user, have to keep track of which is which and think about which Git operations might disturb the wrong type of commits. I'd like Git to have a mode where, say, git rebase -i won't show me published commits by default, only work-in-progress ones. (This isn't necessarily the same as "commits since the remote branch we're tracking," since it's possible to end up tracking a branch that's behind for some reason, or even in a situation like a detached HEAD where you're not tracking anything at all.) I'd also like Git to keep track of whether I'm done with a commit and ready to publish it. Usually when I commit to switch branches, it's because I'm thinking about the branch I'm switching to, so I don't want to spend the time yet to write a three-paragraph commit message about my current work. But that makes it too easy to push an incomplete commit message.
jrochkind1 6y ago
Last listed release of gitless seems to be two years ago. Is it still alive? How's it going? https://gitless.com/ https://gitless.com/
crazygringo 6y ago
This actually... makes a ton of sense. Just as one example, automatically stashing and unstashing when switching branches is so obviously convenient, in hindsight I'm puzzled as to why git doesn't just do this automatically. So whatever happened to this project? In the same way SourceTree adopted git-flow with a few special menu commands, I'd love to also see it be able to adopt a "gitless" mode. Because the great thing about this model is that it can still remain the more complicated git underneath. It just makes using it more straightforward.
- deathanatos 6y ago
  > Just as one example, automatically stashing and unstashing when switching branches is so obviously convenient, in hindsight I'm puzzled as to why git doesn't just do this automatically. Yeah, I too have wished for this. Do note that that can fail, if there are conflicts, so you'd have to decide whether to fail the command (like today) or to drop the user into conflict resolution.
  - hvdijk 6y ago
    That's the exception, though. If the changes are automatically stashed when you switch away from a branch, restored when you switch back, and operations that act on branches require you to first switch to that branch, the stash and branch won't get out of sync, the stash will be right on top of the branch. Conflicts shouldn't happen unless you do weird things like reset a branch (git checkout -B) or update it directly without checking it out (git update-ref), in which case you might not even need conflict resolution, such operations might just be specified to immediately drop the stash.
  - jmchuster 6y ago
    I've used Tower for a couple of years, and that's exactly what it does. Auto-stash, re-apply stash when switching branches, and then you have to resolve the merge conflict in the UI if it doesn't re-apply cleanly. Or you just stash if you didn't actually want to re-apply those changes after all, but I've found the default to re-apply to be what I wanted the majority of the time.
- 6y ago
slaymaker1907 6y ago
My biggest complaints with git is more around how it is difficult to throw away changes and how ignoring files is such a stateful process. I almost never need something nearly as specific as "git checkout" or "git reset". I generally either want to throw everything away up to the last local commit or I want to throw away everything and get my version to be the same as the branch on the server/another local branch. If I need something more fine grained, I will still do this, just on a per file basis. At no point have I ever wanted to just get rid of untracked files. That leads to my next point about ignores. I hate that I have to manually untrack a file even if it would be ignored according to a new ignore file. The best practice there in my opinion would be to explicitly exclude said file IN THE IGNORE FILE ITSELF from being ignored. The other problem with ignore rules in Git is that for some reason Git tries to hide the fact that it has a per repo ignore file in the .git folder which doesn't get synced at all. Instead of having untracked/tracked files, I would really rather just use ignore files, both local and remote, so that excluding something from being committed is an explicit action.
- ajkjk 6y ago
  It is also really absurd that you can reset everything with `git reset --hard` but you have to use `git checkout -- ` to reset individual files. It's not even clear why `checkout` is involved in resetting files at all.
  - johnmaguire 6y ago
    `git reset --hard` resets your worktree to the HEAD state. `git checkout -- <file>` checks out the HEAD version of a given file.
    - infogulch 6y ago
      Yes, but you can also word it in two other ways that make the redundancy more apparent at the cost of a tiny bit of inaccuracy: A: `git reset --hard` checks out the HEAD version of your worktree. `git checkout -- <file>` checks out the HEAD version of a given file. B: `git reset --hard` resets your worktree to the HEAD state. `git checkout -- <file>` resets a file to the HEAD state. I don't think a newbie could even grok the difference between these three descriptions.
kerblang 6y ago
I have a dedicated shell script for each thing I do in git, because it is impossible for me to memorize the original syntax and I'm terrified I'll gut the repo by getting a flag wrong. I have an "undo" script, that just gets rid of unstaged changes, a branch deletion script for removing local & remote branches, and so on. I just take my scripts with me everywhere I go. They're not ingenious, just a necessity. I advise doing this. People like to tell me, "Oh see you just need to understand that git has something called a 'directed acyclic graph' blahblahblahblah" and no, that has nothing to do with it. It's just incredibly arcane and bizarre syntax for the most obvious everyday operations. But since my scripts make life easy, I sort of don't care at this point. Also I don't rebase and thus I don't force push and thus I don't reduce my repo to a pile of burning rubble and work til 3AM repairing it and if people ask me to rebase enough times I'll threaten to literally take a dump on their desk/car/front porch which usually makes them stop. I advise doing this as well.
- domano 6y ago
  I have never understood the benefit of hiding away the actual history. Many people i know find rebasing to be superior because you have this pretty history, but i actually love having the ability to understand what happended when exactly as it happened in reality.
  - formerly_proven 6y ago
    "No broken commits" is one, "nobody cares how often you merged master into your feature branch" is another. Most of the real reasons revolve around making a bisect quicker and easier.
    - kerblang 6y ago
      If it helps any, I usually squash-merge my final output into sparkling, concise commits with nice messages (my original branch usually has "x" for every commit message). And yes I have a dedicated script for squash-merging too...
    - patrickthebold 6y ago
jayd16 6y ago
As a tech lead on game projects that feature less than the most technical developers (artists, game designers) the biggest "problem" with git happens to be its strength. The inconsistent cli and naming can be pasted over with cleaner GUIs. No, the real issue is gits configurability. Not just the configurability but the enforced decentralization of that configurability. For better or worse, it seems like git is actively hostile to any kind of concept of a central authority. Can I configure hooks for my team? No. Can I configure diff tools for my team? No. Can set recursive pulls to be the default? No. Can I enforce line endings? No. Can I even enforce LFS is setup right? No. I certainly can't even enforce things in receive hooks and expect team members to know how to change their histories to adhere to our policies. I love git but its such a pain. I really wish someone would come up with some kind of "accept remote config" policy or some such thing.
- dgfitz 6y ago
  Someone can correct me if I’m wrong but I think mercurial would solve the issues you describe.
  - alkonaut 6y ago
    Git isn’t chosen on its own merits - it’s what the other tools support. If CI servers, issue managers, container tools etc all had a nice VCS-agnostic interface that would be great. But they don’t. We’re stuck with git or at least something that speaks git. Choosing an objectively “better” VCS is often directly coupled to the loss of some other tool.
    - deleted 6y ago
      [deleted]
    - throwawayboise 6y ago
      https://github.com/felipec/git/wiki/git-remote-hg https://github.com/felipec/git/wiki/git-remote-hg
- satya71 6y ago
Guthur 6y ago
I use magit and everything seems a lot less wrong :). I personally found Mercurials a lot more palatable but at this stage git is pretty much ubiquitous.
- crdrost 6y ago
  I was trying to explain Mercurial to other folks at a Subversion shop to make the case for DVCS to them, seemed like it'd be easier to describe the shift from SVN to Hg rather than SVN to Git. As part of this I drew a diagram on a whiteboard I had put up in my cubicle, which I then forgot to erase. A week later I was in the middle of coding when one of the nontechnical people from the company came by my cubicle, I motioned for him to wait a minute for me to finish what I was writing before talking to him, which he did. When I finally looked up, "okay, what's up," he said "first, let me see if I got the gist of this diagram. Inside of a folder you have this repository file named .hg..." and proceeded to give me a half-good explanation of how Mercurial works. And I was just floored and I said "yep, yep, there you go," and at the end he was like "so why do we save all of these things in Fileserv with a timestamp at the end?" and I was like "well I'll send you a link to TortoiseHg and you can just start using it, but yeah most people just want to do the thing that's in front of them and don't want to learn a whole tool that does things differently to get started." (And sadly that was true and as far as I know he also never invested the time to learn TortoiseHg and get started with that, haha.) Left an impression on me, for sure.
- globular-toast 6y ago
  Magit is by far the best way to use git. I've been the git expert at every job I've been in but I owe it all to magit. It really can't be overstated how big of a game changer it is. I've thought about writing a stand-alone TUI version for people who are scared of emacs. But then I realise it's impossible. Magit is inseparable from emacs. Emacs is what makes it so powerful. Emacs is not a text editor, it's an environment for interacting with text-based tools. Having your text editor and git, as well as every other text tool, in the same environment with the same interface is unbeatable.
  - iudqnolq 6y ago
deathanatos 6y ago
> the elimination of the staging area was enthusiastically received as a major reduction in complexity Well, that'd be a huge negative to me… it is much easier to build up a commit piece by piece, verify that it's correct, and then commit it. The only two alternatives I can imagine are worse: disallowing partial commits (I use this feature all the time; I guess I could replace it by a temp commit on a branch and then so long as cherry-pick -p still exists, use that) or specifying it to git-commit (that would be one gnarly set of flags…) Sure, a git without a staging area is less complex. But it removes essential complexity, and would no longer solve my problems. (And in systems that lack it, like Perforce, I've sorely wanted it, and there was just not a good workaround. But yeah, that aspect of the VCS was simpler, I suppose…) I do agree teaching the staging area seems problematic. Newcomers struggle with it. I also agree with how the article mentions other commands sometimes effecting one or more of the staging area & working dir, and it being unclear when are where they effect what. `reset` is perhaps the most confusing command in that regard. Outside of "git reset", "git reset -p" and "git reset --hard", I'm looking at the manual while I run it. (Granted, those first 3 cover probably 99% of the use cases…)
- jcranmer 6y ago
  > The only two alternatives I can imagine are worse: disallowing partial commits (I use this feature all the time; I guess I could replace it by a temp commit on a branch and then so long as cherry-pick -p still exists, use that) or specifying it to git-commit (that would be one gnarly set of flags…) Are you aware that git commit --amend exists? That replaces anything I might ever be tempted to use the staging area for.
  - Arelius 6y ago
    I'm not sure how you use --amend to do partial commits of a file.
    - jcranmer 6y ago
      Well, that would be solved with --interactive, would it not?
brundolf 6y ago
For me it's the enormous number of (mostly hidden) states that a local repository can be in. That's what gives me anxiety as soon as I go off the golden path: you have to keep a running mental model of where exactly you are (what state the repo is in) in any given ongoing process, and if you don't do the right thing as the next step, you can get into an even worse and more obscure state that you then have to chart your way out of (mostly blindly). It's like that old saying about democracy: "Git is the worst version-control system, except for all the others."
- t-writescode 6y ago
  Have you looked at using a good gui for the repository? I find that helps a lot with the mess. I used to use Git Extensions and lately I've been using the one built into IntelliJ's products. It's not as good, but it's available on mac, so my options are limited.
  - jmchuster 6y ago
    For git on mac, i've found https://www.git-tower.com/ https://www.git-tower.com/ to be ridiculously good. Now that i primarily work on linux, i've settled for Sublime Merge, which has customizable actions, but isn't as intuitive a match for how i want scm to work, like Tower was.
    - TheRealDunkirk 6y ago
      I pay for this out of my own pocket without hesitation. They allow you to use your license on 2 different machines. I do most of my work on my personal Mac, but also keep Tower on my work laptop, so I can do the things I need to do there. I briefly tried Fork, but went back to Tower (and Kaleidosope.) You can pry Sublime Text out of my cold, dead hands, but I find Merge to be confusing.
  - brundolf 6y ago
    Yeah, I usually use a GUI. I used SourceTree for a long time but it's gone downhill in recent years. VSCode's integration is great for simple stuff, but it's fairly limited. I haven't found one that I'm happy with across the board.
yarg 6y ago
A DAG of features rather than a DAG of changes would make bug patching a nicer experience.
darepublic 6y ago
I had a hard time learning git but once I did it helped my productivity tremendously. Quite often I meet devs who use wrappers around git and they are always getting stuck on something. git in the terminal is your friend, it's powerful even with just a subset of its capabilities
indymike 6y ago
My biggest problem with git is the bad, buggy code I manage with it. Git blame tells everyone who commited the bug... and sometimes that's me. There is a lot of complexity around managing code that gets wrapped into the discussion about git. Everything from CI to code formatters to linters to audit tools. Most of these tools aren't VCS's. They are often language and toolchain specific or are some other devops lifecycle stuff that really isn't what git is doing. What git does do, it does wonderfully well - and makes it as easy to work with an entire codebase as it used to be to work on a single file. If there is a complaint about git, it's the thing many other comments hit - switching branches with staged to uncommitted changes requires some care... and removing history (e.g. someone commits a private key) is a little tricky.
dang 6y ago
Some past threads: What’s wrong with Git? A conceptual design analysis - https://news.ycombinator.com/item?id=12785200 https://news.ycombinator.com/item?id=12785200 - Oct 2016 (109 comments) What’s wrong with Git? A conceptual design analysis - https://news.ycombinator.com/item?id=12777074 https://news.ycombinator.com/item?id=12777074 - Oct 2016 (1 comment) What’s Wrong with Git? A Conceptual Design Analysis - https://news.ycombinator.com/item?id=6983566 https://news.ycombinator.com/item?id=6983566 - Dec 2013 (74 comments)
crossroadsguy 6y ago
It’s about its design but rather the adoption. I find it kinda concerning that git pretty much has a monopoly.
surbhinahtajain 6y ago
Front web development is very popular today and SevenMentor is the Best UI UX design classes in Pune will cover all aspects of web designing. It is worth learning Web development because the world is more digitized hence web developer demand is increasing. https://www.sevenmentor.com/ui-and-ux-and-web-development-training-in-pune.php https://www.sevenmentor.com/ui-and-ux-and-web-development-tr...
collyw 6y ago
Its too complicated. Hardly anyone actually needs a distributed version control system. It's a tool and should stay out of my road, not require hours of Stack Overflow to roll back a couple of mistakes.
- denton-scratch 6y ago
  As far as I can see, SVN and Hg are distributed. What Git brings to the table is the ability to work offline, but in a distributed multi-developer environment. I spent two years full-time working with a team that used Git. The work wasn't distributed; we all worked in the same room, doing the same hours. I never really got Git; too much unwanted complication, and I had quite enough to learn without having to learn Git at the same time. I did like the ability to edit commits at commit-time, line-by-line. That was nice, but it's the kind of feature that could be back-patched onto something like SVN. It doesn't depend on any intrinsic design-element of Git. I never got rebasing. It scared the shit out of me.

142 points by edward 6y ago

conceptual designs should be created before. Not afterwards. Using it for analysis of a product will of course create a complicate view since evolution of a product is missed.

ketzo 6y ago
This feels more like a learning exercise than an actual critique of git that would necessitate some kind of response. I thought it was a useful way to practice thinking about software design with a tool I already know.
- ajarmst 6y ago
  They should perhaps revisit their title, then.
  - ketzo 6y ago
    I mean, it's absolutely a criticism of git, so in that sense the title's spot on; it's not a pull request, or a suggestion that we should all go out and stop using git. I mostly took issue with GP's implication that there was no reason to perform a conceptual design review after the software's already created.
crazygringo 6y ago
Huh? This is a critique of the conceptual designs, which is valid. And an improvement upon them IMHO. I don't understand what you're arguing.

williesleg 6y ago

It's not China?

ajross 6y ago

All the examples[1] are about the index. And indeed, the index is probably a feature that should have been optional. While it's supremely useful for maintainer-side operations (splitting patches, picking out parts of them, committing only the meat of a patch and not debug code, etc...) it's really not useful for a typical new user. At all. New users would be best served by a "commit" variant that simply updated the HEAD commit in place. [1] Actually not the last one. I couldn't figure out what they were talking about. "Only committed versions of a file can be part of a branch" -- I mean... duh? Branches are a DAG of committed trees. I don't understand what they're asking for when they complain that the working version of a file can't be part of more than one branch. It's not part of any yet!

tsimionescu 6y ago
The problem they are talking about is that you can't checkout a new branch wothout first committing, stashing or undoing your work. In other VCS tools, including gitless apparently, your uncommitted work is also branched (usually by virtue of different branches being chekced out in different directories on disk). You can also achieve this in Git by using different working trees.
- ajross 6y ago
  Ah, OK. And this is why I think lots of criticism like this is a little off the rails. It's too dependent on what to my eyes is just a broken mental model. I mean... branches are commits. If you want your uncommitted work to be on a branch you... commit it. There's a command for that. It's called "commit". I mean, literally "git commit -a -m WIP; git checkout $OTHER_BRANCH" is all that's required. It's even "orthogonal" per the requirements in the article.
  - geofft 6y ago
    This is the workflow I follow, but my experience is it's pretty high-mental-overhead in practice - Git doesn't draw a distinction between commits that I created because I'm still working on something and want to switch branches, and are therefore reasonable to modify, and commits that came from some remote source and which you want to keep intact. They're both "commits." That means you, the user, have to keep track of which is which and think about which Git operations might disturb the wrong type of commits. I'd like Git to have a mode where, say, git rebase -i won't show me published commits by default, only work-in-progress ones. (This isn't necessarily the same as "commits since the remote branch we're tracking," since it's possible to end up tracking a branch that's behind for some reason, or even in a situation like a detached HEAD where you're not tracking anything at all.) I'd also like Git to keep track of whether I'm done with a commit and ready to publish it. Usually when I commit to switch branches, it's because I'm thinking about the branch I'm switching to, so I don't want to spend the time yet to write a three-paragraph commit message about my current work. But that makes it too easy to push an incomplete commit message.

jrochkind1 6y ago

Last listed release of gitless seems to be two years ago. Is it still alive? How's it going? https://gitless.com/ https://gitless.com/

crazygringo 6y ago

This actually... makes a ton of sense. Just as one example, automatically stashing and unstashing when switching branches is so obviously convenient, in hindsight I'm puzzled as to why git doesn't just do this automatically. So whatever happened to this project? In the same way SourceTree adopted git-flow with a few special menu commands, I'd love to also see it be able to adopt a "gitless" mode. Because the great thing about this model is that it can still remain the more complicated git underneath. It just makes using it more straightforward.

deathanatos 6y ago
> Just as one example, automatically stashing and unstashing when switching branches is so obviously convenient, in hindsight I'm puzzled as to why git doesn't just do this automatically. Yeah, I too have wished for this. Do note that that can fail, if there are conflicts, so you'd have to decide whether to fail the command (like today) or to drop the user into conflict resolution.
- hvdijk 6y ago
  That's the exception, though. If the changes are automatically stashed when you switch away from a branch, restored when you switch back, and operations that act on branches require you to first switch to that branch, the stash and branch won't get out of sync, the stash will be right on top of the branch. Conflicts shouldn't happen unless you do weird things like reset a branch (git checkout -B) or update it directly without checking it out (git update-ref), in which case you might not even need conflict resolution, such operations might just be specified to immediately drop the stash.
- jmchuster 6y ago
  I've used Tower for a couple of years, and that's exactly what it does. Auto-stash, re-apply stash when switching branches, and then you have to resolve the merge conflict in the UI if it doesn't re-apply cleanly. Or you just stash if you didn't actually want to re-apply those changes after all, but I've found the default to re-apply to be what I wanted the majority of the time.
6y ago

slaymaker1907 6y ago

My biggest complaints with git is more around how it is difficult to throw away changes and how ignoring files is such a stateful process. I almost never need something nearly as specific as "git checkout" or "git reset". I generally either want to throw everything away up to the last local commit or I want to throw away everything and get my version to be the same as the branch on the server/another local branch. If I need something more fine grained, I will still do this, just on a per file basis. At no point have I ever wanted to just get rid of untracked files. That leads to my next point about ignores. I hate that I have to manually untrack a file even if it would be ignored according to a new ignore file. The best practice there in my opinion would be to explicitly exclude said file IN THE IGNORE FILE ITSELF from being ignored. The other problem with ignore rules in Git is that for some reason Git tries to hide the fact that it has a per repo ignore file in the .git folder which doesn't get synced at all. Instead of having untracked/tracked files, I would really rather just use ignore files, both local and remote, so that excluding something from being committed is an explicit action.

ajkjk 6y ago
It is also really absurd that you can reset everything with `git reset --hard` but you have to use `git checkout -- ` to reset individual files. It's not even clear why `checkout` is involved in resetting files at all.
- johnmaguire 6y ago
  `git reset --hard` resets your worktree to the HEAD state. `git checkout -- <file>` checks out the HEAD version of a given file.
  - infogulch 6y ago
    Yes, but you can also word it in two other ways that make the redundancy more apparent at the cost of a tiny bit of inaccuracy: A: `git reset --hard` checks out the HEAD version of your worktree. `git checkout -- <file>` checks out the HEAD version of a given file. B: `git reset --hard` resets your worktree to the HEAD state. `git checkout -- <file>` resets a file to the HEAD state. I don't think a newbie could even grok the difference between these three descriptions.

kerblang 6y ago

I have a dedicated shell script for each thing I do in git, because it is impossible for me to memorize the original syntax and I'm terrified I'll gut the repo by getting a flag wrong. I have an "undo" script, that just gets rid of unstaged changes, a branch deletion script for removing local & remote branches, and so on. I just take my scripts with me everywhere I go. They're not ingenious, just a necessity. I advise doing this. People like to tell me, "Oh see you just need to understand that git has something called a 'directed acyclic graph' blahblahblahblah" and no, that has nothing to do with it. It's just incredibly arcane and bizarre syntax for the most obvious everyday operations. But since my scripts make life easy, I sort of don't care at this point. Also I don't rebase and thus I don't force push and thus I don't reduce my repo to a pile of burning rubble and work til 3AM repairing it and if people ask me to rebase enough times I'll threaten to literally take a dump on their desk/car/front porch which usually makes them stop. I advise doing this as well.

domano 6y ago
I have never understood the benefit of hiding away the actual history. Many people i know find rebasing to be superior because you have this pretty history, but i actually love having the ability to understand what happended when exactly as it happened in reality.
- formerly_proven 6y ago
  "No broken commits" is one, "nobody cares how often you merged master into your feature branch" is another. Most of the real reasons revolve around making a bisect quicker and easier.
  - kerblang 6y ago
    If it helps any, I usually squash-merge my final output into sparkling, concise commits with nice messages (my original branch usually has "x" for every commit message). And yes I have a dedicated script for squash-merging too...
  - patrickthebold 6y ago

jayd16 6y ago

As a tech lead on game projects that feature less than the most technical developers (artists, game designers) the biggest "problem" with git happens to be its strength. The inconsistent cli and naming can be pasted over with cleaner GUIs. No, the real issue is gits configurability. Not just the configurability but the enforced decentralization of that configurability. For better or worse, it seems like git is actively hostile to any kind of concept of a central authority. Can I configure hooks for my team? No. Can I configure diff tools for my team? No. Can set recursive pulls to be the default? No. Can I enforce line endings? No. Can I even enforce LFS is setup right? No. I certainly can't even enforce things in receive hooks and expect team members to know how to change their histories to adhere to our policies. I love git but its such a pain. I really wish someone would come up with some kind of "accept remote config" policy or some such thing.

dgfitz 6y ago
Someone can correct me if I’m wrong but I think mercurial would solve the issues you describe.
- alkonaut 6y ago
  Git isn’t chosen on its own merits - it’s what the other tools support. If CI servers, issue managers, container tools etc all had a nice VCS-agnostic interface that would be great. But they don’t. We’re stuck with git or at least something that speaks git. Choosing an objectively “better” VCS is often directly coupled to the loss of some other tool.
  - deleted 6y ago
    [deleted]
  - throwawayboise 6y ago
    https://github.com/felipec/git/wiki/git-remote-hg https://github.com/felipec/git/wiki/git-remote-hg
satya71 6y ago

Guthur 6y ago

I use magit and everything seems a lot less wrong :). I personally found Mercurials a lot more palatable but at this stage git is pretty much ubiquitous.

crdrost 6y ago
I was trying to explain Mercurial to other folks at a Subversion shop to make the case for DVCS to them, seemed like it'd be easier to describe the shift from SVN to Hg rather than SVN to Git. As part of this I drew a diagram on a whiteboard I had put up in my cubicle, which I then forgot to erase. A week later I was in the middle of coding when one of the nontechnical people from the company came by my cubicle, I motioned for him to wait a minute for me to finish what I was writing before talking to him, which he did. When I finally looked up, "okay, what's up," he said "first, let me see if I got the gist of this diagram. Inside of a folder you have this repository file named .hg..." and proceeded to give me a half-good explanation of how Mercurial works. And I was just floored and I said "yep, yep, there you go," and at the end he was like "so why do we save all of these things in Fileserv with a timestamp at the end?" and I was like "well I'll send you a link to TortoiseHg and you can just start using it, but yeah most people just want to do the thing that's in front of them and don't want to learn a whole tool that does things differently to get started." (And sadly that was true and as far as I know he also never invested the time to learn TortoiseHg and get started with that, haha.) Left an impression on me, for sure.
globular-toast 6y ago
Magit is by far the best way to use git. I've been the git expert at every job I've been in but I owe it all to magit. It really can't be overstated how big of a game changer it is. I've thought about writing a stand-alone TUI version for people who are scared of emacs. But then I realise it's impossible. Magit is inseparable from emacs. Emacs is what makes it so powerful. Emacs is not a text editor, it's an environment for interacting with text-based tools. Having your text editor and git, as well as every other text tool, in the same environment with the same interface is unbeatable.
- iudqnolq 6y ago

deathanatos 6y ago

> the elimination of the staging area was enthusiastically received as a major reduction in complexity Well, that'd be a huge negative to me… it is much easier to build up a commit piece by piece, verify that it's correct, and then commit it. The only two alternatives I can imagine are worse: disallowing partial commits (I use this feature all the time; I guess I could replace it by a temp commit on a branch and then so long as cherry-pick -p still exists, use that) or specifying it to git-commit (that would be one gnarly set of flags…) Sure, a git without a staging area is less complex. But it removes essential complexity, and would no longer solve my problems. (And in systems that lack it, like Perforce, I've sorely wanted it, and there was just not a good workaround. But yeah, that aspect of the VCS was simpler, I suppose…) I do agree teaching the staging area seems problematic. Newcomers struggle with it. I also agree with how the article mentions other commands sometimes effecting one or more of the staging area & working dir, and it being unclear when are where they effect what. `reset` is perhaps the most confusing command in that regard. Outside of "git reset", "git reset -p" and "git reset --hard", I'm looking at the manual while I run it. (Granted, those first 3 cover probably 99% of the use cases…)

jcranmer 6y ago
> The only two alternatives I can imagine are worse: disallowing partial commits (I use this feature all the time; I guess I could replace it by a temp commit on a branch and then so long as cherry-pick -p still exists, use that) or specifying it to git-commit (that would be one gnarly set of flags…) Are you aware that git commit --amend exists? That replaces anything I might ever be tempted to use the staging area for.
- Arelius 6y ago
  I'm not sure how you use --amend to do partial commits of a file.
  - jcranmer 6y ago
    Well, that would be solved with --interactive, would it not?

brundolf 6y ago

For me it's the enormous number of (mostly hidden) states that a local repository can be in. That's what gives me anxiety as soon as I go off the golden path: you have to keep a running mental model of where exactly you are (what state the repo is in) in any given ongoing process, and if you don't do the right thing as the next step, you can get into an even worse and more obscure state that you then have to chart your way out of (mostly blindly). It's like that old saying about democracy: "Git is the worst version-control system, except for all the others."

t-writescode 6y ago
Have you looked at using a good gui for the repository? I find that helps a lot with the mess. I used to use Git Extensions and lately I've been using the one built into IntelliJ's products. It's not as good, but it's available on mac, so my options are limited.
- jmchuster 6y ago
  For git on mac, i've found https://www.git-tower.com/ https://www.git-tower.com/ to be ridiculously good. Now that i primarily work on linux, i've settled for Sublime Merge, which has customizable actions, but isn't as intuitive a match for how i want scm to work, like Tower was.
  - TheRealDunkirk 6y ago
    I pay for this out of my own pocket without hesitation. They allow you to use your license on 2 different machines. I do most of my work on my personal Mac, but also keep Tower on my work laptop, so I can do the things I need to do there. I briefly tried Fork, but went back to Tower (and Kaleidosope.) You can pry Sublime Text out of my cold, dead hands, but I find Merge to be confusing.
- brundolf 6y ago
  Yeah, I usually use a GUI. I used SourceTree for a long time but it's gone downhill in recent years. VSCode's integration is great for simple stuff, but it's fairly limited. I haven't found one that I'm happy with across the board.

yarg 6y ago

A DAG of features rather than a DAG of changes would make bug patching a nicer experience.

darepublic 6y ago

I had a hard time learning git but once I did it helped my productivity tremendously. Quite often I meet devs who use wrappers around git and they are always getting stuck on something. git in the terminal is your friend, it's powerful even with just a subset of its capabilities

indymike 6y ago

My biggest problem with git is the bad, buggy code I manage with it. Git blame tells everyone who commited the bug... and sometimes that's me. There is a lot of complexity around managing code that gets wrapped into the discussion about git. Everything from CI to code formatters to linters to audit tools. Most of these tools aren't VCS's. They are often language and toolchain specific or are some other devops lifecycle stuff that really isn't what git is doing. What git does do, it does wonderfully well - and makes it as easy to work with an entire codebase as it used to be to work on a single file. If there is a complaint about git, it's the thing many other comments hit - switching branches with staged to uncommitted changes requires some care... and removing history (e.g. someone commits a private key) is a little tricky.

dang 6y ago

Some past threads: What’s wrong with Git? A conceptual design analysis - https://news.ycombinator.com/item?id=12785200 https://news.ycombinator.com/item?id=12785200 - Oct 2016 (109 comments) What’s wrong with Git? A conceptual design analysis - https://news.ycombinator.com/item?id=12777074 https://news.ycombinator.com/item?id=12777074 - Oct 2016 (1 comment) What’s Wrong with Git? A Conceptual Design Analysis - https://news.ycombinator.com/item?id=6983566 https://news.ycombinator.com/item?id=6983566 - Dec 2013 (74 comments)

crossroadsguy 6y ago

It’s about its design but rather the adoption. I find it kinda concerning that git pretty much has a monopoly.

surbhinahtajain 6y ago

Front web development is very popular today and SevenMentor is the Best UI UX design classes in Pune will cover all aspects of web designing. It is worth learning Web development because the world is more digitized hence web developer demand is increasing. https://www.sevenmentor.com/ui-and-ux-and-web-development-training-in-pune.php https://www.sevenmentor.com/ui-and-ux-and-web-development-tr...

collyw 6y ago

Its too complicated. Hardly anyone actually needs a distributed version control system. It's a tool and should stay out of my road, not require hours of Stack Overflow to roll back a couple of mistakes.

denton-scratch 6y ago
As far as I can see, SVN and Hg are distributed. What Git brings to the table is the ability to work offline, but in a distributed multi-developer environment. I spent two years full-time working with a team that used Git. The work wasn't distributed; we all worked in the same room, doing the same hours. I never really got Git; too much unwanted complication, and I had quite enough to learn without having to learn Git at the same time. I did like the ability to edit commits at commit-time, line-by-line. That was nice, but it's the kind of feature that could be back-patched onto something like SVN. It doesn't depend on any intrinsic design-element of Git. I never got rebasing. It scared the shit out of me.