Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Git Irreplaceable? (2019)

fossil-scm.org

Post reply on HN
Print view View original

311–320 of 559 posts

Re: Is Git Irreplaceable? (2019)

#311

Post by teleforce »

emodendroket wrote: post #16
colechristensen wrote: post #10

Earlier quoted context omitted.

SVN also had serious difficulties and performance limitations which git does not. Git is somewhat confusing to use, but not enough so that anyone really cares all that much (besides a few people who really care) and that is not a recipe for easy replacement. There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason.

I mean so is Unix and it's still around all these years. Heck there's nothing especially obvious about a for loop, yet every language has them. Once everyone's accustomed to the weird interface they are just going to demand everything else have the same weird interface they're used to. This is one of the lamentations of the Unix Hater's Handbook.

Git is probably destined to be Unix for our generation that was born after Unics/Unix invention. It is not a coincident that the designer/programmer of the most popular Unix version/clone of our generation is the same guy who designed and programmed Git.

Re: Is Git Irreplaceable? (2019)

#312

Post by adrianmsmith »

saurik wrote: post #279
alkonaut wrote: post #228

Earlier quoted context omitted.

I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, bran…

Another simple tracking thing that git doesn't do that would easily make git much much better is if it tracked when you did a cherrypick of another commit in the commit graph (not just as some kind of metadata comment in the commit message, but as a kind of soft parent); then if you did a rebase, you could actually "reverse engineer" the rebase (if and only if you absolutely needed to, such as to track what happened…

Another thing that Git does not track -

I saw a web designer check in a huge hierarchy of empty directories which would be the structure of the new project that their team should work on. They were quite surprised when it didn't show up on any of the other designer's computers after a "pull". They had to go to the "Git guru" for help.

Windows and Mac both have directories as a major fundamental concept. Everyone knows them and is familiar with them. Subversion tracks directories. Git does not.

Re: Is Git Irreplaceable? (2019)

#313

Post by bhaak »

philbarr wrote: post #305
bhaak wrote: post #289

Earlier quoted context omitted.

I've seen nobody complain about the commit messages. Commit messages are not versioned. I can't go back and change the commit message to fix a typo or add something that was missed without changing the history. This always bothered me somewhat but now that I have non native and native people on the team that can't spell, I feel the pain everyday.

But you can go back and change a commit message with ammend? Or are you wanting to change other people's? https://www.atlassian.com/git/tutorials/rewriting-history#gi...

Look at the URL: "rewriting-history"

Ammending changes the hash of the commit. That doesn't matter if you haven't pushed it yet but if you have, you can't push the change upstream without force-pushing.

And if I want to change a commit message further back in history (regardless of my own or of somebody else), it would branch off at that point from the upstream git history.

What I want is that you could put multiple comments onto the same commit with different timestamps. Like git versions files, it should also allow to version commit messages.

Re: Is Git Irreplaceable? (2019)

#314

Post by TwoHeadedBeast »

kstrauser wrote: post #86
codazoda wrote: post #63

Earlier quoted context omitted.

I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "hos…

Same. I didn't get what was better about a distributed system for small projects, until it fully clicked with me that my copy was just as "official" as any other sitting around, and that any "server" was a copy that we collectively decided was going to be the one of record. I can't imagine any plausible scenario in which I'd go back to having a central SVN-style server.

Having an official central server is precisely what you want in most development environments. Being able to go back to any prior version of the code is tremendously useful and something git can't do.

Re: Is Git Irreplaceable? (2019)

#315

Post by TwoHeadedBeast »

duskwuff wrote: post #104
codazoda wrote: post #63

Earlier quoted context omitted.

I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "hos…

Having history available locally also means you can perform interesting operations on history -- like "git blame" -- without making the server do all the heavy lifting.

The problem is, is that git will happily destroy history. git blame is not useful because it doesn't tell you who authored the line of code.

Re: Is Git Irreplaceable? (2019)

#316

Post by barrkel »

tomesch1982 wrote: post #237
tasuki wrote: post #199

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

Git is neither easy not is it really elegant. It is useful for projects like Linux™ but for the vast majority of projects way better tools like mercurial or fossil would be a much better fit.

After svn, git was a breath of fresh air; far easier to use and reason about, not to mention much faster.

I don't think much of your all-in-one solution like fossil - that's a competitor for GitHub (without the bits that make GH good), not git.

I tried to use hg at one point in the early days, and found it much slower than git. Git's low latency for commands made a substantial difference, perceptually. In principle I think git encourages too much attention to things like rebases, which fraudulently rewrite history and lie about how code was written, just so the diff history can look neater. Working code should be the primary artifact, not neat history, and rebases and other rewrites make it too easy to cause chaos with missing or duplicated commits in a team environment. So ideologically, mercurial is a better fit, but that's not enough to make me use it.

Fit is a function of an environment; when we say survival of the fittest, we mean fitness as adapted to an environment. Feature set isn't the only aspect; at this point, the network effects of git are insurmountable without a leap forward in functionality of some kind.

(I think git & hg are just as elegant as one another; to me, the elegance is in the Merkle tree and the conceptual model one needs to operate the history graph.)

Re: Is Git Irreplaceable? (2019)

#317

Post by theamk »

rhabarba wrote: post #2

Fossil's new(ish) semi-automatic bidirectional interaction with Git mirrors has finally made Mercurial replaceable for me. However, it is hard to ignore that the IT world has mostly decided to settle with whatever is the most commonly used right now, no matter if it is actually the best solution - so at least when it comes to DVCS, the war seems to be over.

Does not Fossil’s “no rebases” philosophy bother you?

IMHO, the ability to “commit early, commit often” and to squash/rebase original work later into clean and understandable commits is one of the best features of Git.

Re: Is Git Irreplaceable? (2019)

#318

Post by adrianmsmith »

TwoHeadedBeast wrote: post #315
duskwuff wrote: post #104

Earlier quoted context omitted.

Having history available locally also means you can perform interesting operations on history -- like "git blame" -- without making the server do all the heavy lifting.

The problem is, is that git will happily destroy history. git blame is not useful because it doesn't tell you who authored the line of code.

Right, especially after a "squash", which seems to be the standard way to merge branches in the companies I've been working with recently. (Which is, ironically, also the way Subversion merges branches. With the exception that "svn blame -g" will go into the commits which were squashed if you want. An option which doesn't exist after a "squash" on Git.)

Re: Is Git Irreplaceable? (2019)

#319

Post by breck »

ken wrote: post #134
frutiger wrote: post #98

Earlier quoted context omitted.

What you want has nothing to do with git (which is a storage model). You can use arbitrary diff and merge resolution algorithms with git's plumbing, which would give you the AST-aware functionality that you want.

That's like saying DVCS has nothing to do with VCS -- it's just the server model. Every major advance has been accomplished by increasing the scope of version control. Arbitrary diff/merge in Git is a great example of the Turing Tar-Pit. It's possible, but prohibitively inefficient for many things I want to do. You can't add your own types, index, or query optimizations. Today, if I want to store data for my applicat…

> Today, if I want to store data for my application, I have a choice between good support for rich object types and connections (e.g., Postgres), or good support for history and merging (e.g., Git). There's no one system that provides both.

I like the way you put this. In case anyone's interested in brainstorming I'm dabbling in this problem with a thing called TreeBase (https://jtree.treenotation.org/treeBase/). It's still a toy at this point, but it stores richly typed data as plain text files to leverage git for history and merging and then can use SQLite (or others) for querying and analysis. A very simple database in the wild looks like this: https://github.com/treenotation/jtree/tree/master/treeBase/p...

Re: Is Git Irreplaceable? (2019)

#320

Post by mikece »

The problem with Git is that the software and API aren't separated. Like all modern software, there should be an API or interface to which all distributed source control engines comply, allowing the specific DVCS engine to an implementation detail. Want the old-school one written in C by Linus? Fine. Want a revamped version of Mercurial that uses the same commands and creates the same repository format? Cool! Want to Show HN your ability to implement the same thing in Rust with lower memory and better safety? Awesome!

But with Git this isn't possible because there's no concept of the API or interface for distributed version control being separate from the implementation -- and the discussion of "could the API be better than what it is now?" has never been had in a meaningful way.

Post reply on HN