Live data from Hacker News

Is Git Irreplaceable? (2019)

fossil-scm.org

261–270 of 559 posts

Re: Is Git Irreplaceable? (2019)

#261

Earlier quoted context omitted.

I think the distinction you're drawing between code history and paperwork history is more arbitrary than you give it credit. If all we cared about was code history, a super pure "version control" system would have one trunk, no branches, and a sequentially increasing version number with no commit messages or author information. But if you can annotate an entire commit with a descriptive message, why not annotate a sp…

> I think the distinction you're drawing between code history and paperwork history is more arbitrary than you give it credit. I don't agree. The responsibility of a version control system is to manage the changes made to the source code. The paperwork that goes with it is an entirely different, and separate, responsibility, just like ticketing systems and keeping track of tasks, epics, sprints, etc. > If all we care…

If you can annotate an entire commit with a message, why not allow annotating parts of a commit (file/span) with a message, and why not allow those messages to form threads?

At which point you get code review that is logged entirely in the history of the repo. Which is a very useful feature, and a huge value proposition of GitHub over raw git - git blame gives you the commit, but GitHub will also gives you the pull request for that commit, and you can go and look at the comments there to understand why it was done the way it was.

Re: Is Git Irreplaceable? (2019)

#262
post #29

Earlier quoted context omitted.

But did you think that RCS, CVS, or SVN were also good enough? Or is this new?

> But did you think that RCS, CVS, or SVN were also good enough? SVN required a centralized server and didn't even supported branching, so no.

Subervsion did support branching but it was so fragile (especially before version 1.5 or 1.6 I don't remember) that some went out of the way just to avoid using branches in SVN. Those dreaded tree conflicts…

Re: Is Git Irreplaceable? (2019)

#263

Earlier quoted context omitted.

I think the distinction you're drawing between code history and paperwork history is more arbitrary than you give it credit. If all we cared about was code history, a super pure "version control" system would have one trunk, no branches, and a sequentially increasing version number with no commit messages or author information. But if you can annotate an entire commit with a descriptive message, why not annotate a sp…

> I think the distinction you're drawing between code history and paperwork history is more arbitrary than you give it credit. I don't agree. The responsibility of a version control system is to manage the changes made to the source code. The paperwork that goes with it is an entirely different, and separate, responsibility, just like ticketing systems and keeping track of tasks, epics, sprints, etc. > If all we care…

I kind of agree with grandparent, though. When the IDE, source control, code review and task tracking work together seamlessly, it's glorious. If your software says "it's not my job", it will be outcompeted by software that says "heck yeah it's my job".

Re: Is Git Irreplaceable? (2019)

#264
post #29

I am happy to use whatever everyone else starts using, provided it works at least as well. But I also do not have many problems that git won't solve, so I don't feel a burning need to switch. I think git is good enough that source control is no longer a very interesting problem.

But did you think that RCS, CVS, or SVN were also good enough? Or is this new?

One big thing that DVCS brought to the table were local serverless repos. Now you could version all the things, with very little effort, and promote it to a "proper" repo later.

The other big thing was free cloud hosting for the repos.

Neither of these are unique to Git, obviously, or even introduced by it. It just happened to be the right combination of features and speed at the right time to become the winner of the popularity contest. Kinda like C.

And, just as C is still around, for all its numerous horrible quirks, Git will likely be around for a long time as well.

Re: Is Git Irreplaceable? (2019)

#265

Earlier quoted context omitted.

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.

> way better tools I work with a group of people who all know enough git that we're productive, and a few of us know enough git to solve complicated problem. I've not seriously considered fossil or mercurial -- what are the top three tangible benefits I'd get from them getting our team to switch?

That is exactly the point. For git you need the ecosystem to cope with it's shortcomings and in addition some experts to help you out of the pickles this software gets you into.

I mainly use fossil for personal projects.

Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management. The setup is ridiculously easy and everyone always has everything in the repository.

In addition fossil never looses data, unlike git which can easily destroy branches that are not pushed, delete stuff while stashing or unstashing, delete stuff when rebasing and so on.

And fossil has a sane command-line interface so that everyone in the team is expert enough to work with it. No need for heroes that save the day from git fricking everything up.

Re: Is Git Irreplaceable? (2019)

#266

> Microsoft's long-term stalwarts Windows and Office are dying Judged on what metric? Office's paying monthly active users and revenues have consistently grown, measured both quarter on quarter, and year on year

I would probably think the same if I were stuck in my Linux bubble, but $WORK allows me to observe the average computer worker. They're incredibly deep in the Microsoft ecosystem and not at all interested in switching.

Re: Is Git Irreplaceable? (2019)

#267

The git internals are good for some kinds of projects but for the actual majority of projects git is a very bad fit. Most people don't get that because they are blind for the much better tools like mercurial and fossil. The git UI/UX on the other hand is the worst piece of crap ware known to man. This piece of shit has probably destroyed more data than any other tool ever written. People who think that git is any goo…

How funny, it was actually mercurial that destroyed my repo. Never looked at it again. Also, it is very hard to "destroy data" in git.

Re: Is Git Irreplaceable? (2019)

#268
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.

But this doesn't hold for things like languages, adoption of new tech over old (no matter how prominent it is) happens all the time, but it usually starts at the small scale, like start-ups. It definitely takes a hell of a long time, and it would probably never usurp 100% of gits usership (or even 50%), but it will probably be used in some capacity. Of course Java's still as big as ever, but we have seen an uptick in…

There was always an "uptick in relatively new languages coming into use", as long as I remember. The problem is that most of them die before they mature, and some achieve a "peak cool" but then fade into obscurity, or find a relatively small niche. Very few new languages ever get popular enough to get into the top 10 on a permanent basis, and even fewer displace a large player that was previously popular. Meanwhile, most code running on any given computing device is still written in C, C++, or Java.

The article is basically arguing that we're likely to see the same state of affairs in VCS land. Sure, there will still be new ones coming into use, and fading out, or finding small niches - but Git will remain dominant for decades to come.

Re: Is Git Irreplaceable? (2019)

#269
post #48

Git's biggest flaw is that it doesn't scale. If a new system can fix that without sacrificing any of Git's benefits, I think it can topple Git. It's ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos. There have been some attempts to work around this. Google's `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it's a (very) le…

I'd say the number of git repos on Earth that would encounter problems of that nature would be a vanishingly microscopic minority. Sure, it's a problem for those companies but it's not a problem for anyone else.

This reads to me as a failure of imagination. Any mid size game development shop is going to feel this pain - not just giants like Microsoft and Google. I believe the Unity Game Engine has a user base in the millions? Even a subset of that may be small in comparison to the entire developer population but by no means microscopic.

Re: Is Git Irreplaceable? (2019)

#270
post #44

I really doubt Git is going anywhere for the foreseeable future, but I could imagine a more approachable VCS catching on. Git is extremely opaque to most new developers and even for experienced devs looking up a new command. Sometimes I look up how to perform an unfamiliar task with Git and find 4-5 competing answers on Stackoverflow with no real clear explanation of why one is better than another. If an easier VCS c…

I wonder how possible it is to retain the Git data model, but completely replace the CLI? Git gets some flak for its conceptual decisions (e.g. what "branch" means), but IMO most of the real-world friction comes from numerous little inconsistencies and general weirdness.
Post reply on HN