I mean, it's called .mailmap, and it's a map of commit email to cannonical email instead of uuid to canonical email, but this basically exists: https://git-scm.com/docs/gitmailmap
Things I just don't like about Git
41–50 of 118 posts
Re: Things I just don't like about Git
#42I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.
Back in a day, late 00s, early 10s, Git had alternatives. - Bazaar - Mercurial (Hg) Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible. What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user int…
Highly subjective.
Both Mercurial and Bazaar were plagued a long time by muddled branching and collaboration story. In hg there were the anonymous branches, multiple repos, bookmarks, all worked in different ways and their interactions were confusing. Bazaar I didn't use much but remember not understanding at all its branching model then, and didn't bother finding out.
Git won because it got many things right from the start, and was better than the competition.
Re: Things I just don't like about Git
#43I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.
Scrap the thing entirely and replace it with something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. Folders instead of branches. Be 100% language-aware; any merge result has to build obviously. If this rejects actions and limits possibilities that Git provides, so be it.
Re: Things I just don't like about Git
#44That said, I agree with most points. The main problem with Git is that it's not bad, it's good enough. Mercurial and Fossil are superior, but Git is good enough, so people won't switch.
Re: Things I just don't like about Git
#45Comes up in every conversation I have about Emacs, Git, CSS, etc: Just because a tool is the best at what it does, that doesn't necessarily mean it's good at what it does. Those are two different metrics. There's no danger of me dropping Git, the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does. But Git definitely still has flaws; a lot of this post rings true to…
It's legitimately one of the largest divergences between simplicity of concepts and complexity of UX/interface of any serious tool I've ever worked with in my career.
Again, it's huge service and absolutely a benefit - but also the amount of collective dev hours wasted on understanding git minutiae is way too high.
Re: Things I just don't like about Git
#46I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.
> I'd love to hear more about what people hate about Git. It's not implemented as a single portable library. This makes embedding or driving git from other programs—a thing I've wanted or needed to do several times in my career, so I'm pretty sure it's really common —suck a lot more than it needs to.
Re: Things I just don't like about Git
#47I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.
Will your VCS be compatible with git pull, git push, and the file format on disk used by git?
Re: Things I just don't like about Git
#48I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.
Back in a day, late 00s, early 10s, Git had alternatives. - Bazaar - Mercurial (Hg) Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible. What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user int…
Unfortunately it's been long enough that I don't remember any details about why I found mercurial confusing.
Re: Things I just don't like about Git
#49Comes up in every conversation I have about Emacs, Git, CSS, etc: Just because a tool is the best at what it does, that doesn't necessarily mean it's good at what it does. Those are two different metrics. There's no danger of me dropping Git, the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does. But Git definitely still has flaws; a lot of this post rings true to…
> the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does. The fossil developers (myself included) would be interested in hearing what those mistakes are. We're open to improvement so long as they don't break backwards compatibility (e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil).
We could go further, but yeah, this is basically the biggest problem. I know this is a fundamental attribute of Fossil and that's fine, but to me it makes Fossil unusable as a VC system for most serious projects. I don't think of VC as an immutable record, I think of it as a tool for organization and collaboration that also allows me to have documentation around repository history, and I don't think that immutable history helps with either documentation or collaboration.
Obviously some people disagree with me on that, but the really short answer is that I think the way Fossil defines version control is misguided, so it's unlikely I would ever make the switch over.
Re: Things I just don't like about Git
#50I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.
Back in a day, late 00s, early 10s, Git had alternatives. - Bazaar - Mercurial (Hg) Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible. What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user int…
Back in 2011 or 2012 i once had one of the libgit developers sitting at my workstation for a full hour trying un-hose my local checkout after i'd made the mistake of following git instructions from SO.
SO git advice: 0 of 5 stars. Cannot recommend.