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

301–310 of 559 posts

Re: Is Git Irreplaceable? (2019)

#301

Post by xorcist »

adrianmsmith wrote: post #210
rileymat2 wrote: post #171

Earlier quoted context omitted.

I actually prefer SVN and HG style branches where you keep the branch history as a known formal branch, then have one merge back to Trunk. It is unclear to me how far back you are saying SVN did not have branching.

I don't remember a time when Subversion didn't support branches. I'm sure Subversion 1.0 supported branches (although I can't find evidence of that right now, but I also can't find any release notes for Subversion 1.n containing "now we support branches!") One can argue about what a branch is, for sure. Subversion branches, Mercurial branches and Git branches all have very different implementations. But the main work…

Considering CVS had branches, Subversion probably had them from the start or at least some early development version. Very different under the hood though, as you say.

Re: Is Git Irreplaceable? (2019)

#302

Post by LaGrange »

tomesch1982 wrote: post #265
peteretep wrote: post #249

Earlier quoted context omitted.

> 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…

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

That is not nice. That is way more things that might not match me, more attack surface, more irrelevant cruft I'll probably have to look up how to disable. Project management, wiki and issue tracking preferences are very personal and often don't map particularly well to specific repositories. And _blog_ and _mailing list_? Why, you're spending time on stuff most of your users will hate, not because it's bad, but because they either don't need it or would like it different.

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

Which is why Git is successful. That's by design, not accident. We want to, and sometimes _have to_, delete stuff.

Re: Is Git Irreplaceable? (2019)

#303

Post by JackMorgan »

nwallin wrote: post #84
ken wrote: post #19

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.

If I were to pie in the sky dream up a replacement for git, I'd have it store the AST of the parsed code instead of a text file. It would solve a lot of problems with refactoring crapping all over the history. Like I said, pie in the sky. Probably never gonna happen. Personally I don't see git's problems with large binary files and tens of millions of commits as being major issues. Those two alone are way less valuab…

Look into Unison, a language that stores the AST and immutable history of all functions to provide a combination of package manager, IDE, and DVCS. Once you store the AST and all history, some fascinating side effects happen!

https://github.com/unisonweb/unison

Re: Is Git Irreplaceable? (2019)

#304

Post by pja »

MaulingMonkey wrote: post #246
pja wrote: post #208

Earlier quoted context omitted.

The fact that you had a problem with github quotas isn’t really a problem with git though, is it?

The whole reason git lfs exists is to workaround git scalability problems. Its raison d'etre is problems with git. That one of - if not the - most popular tool to solve said git scalability problems, also has scalability problems in practice, is both ironic - and absolutely a problem with the git ecosystem. To be pithy - "Even the workarounds don't work." "Technically", you might say, "that specific symptom with git…

Nothing about your problems had anything to do with git & everything to do with the commercial service you were using for your source code hosting.

Github the company is not interested in providing you (or anyone else) with free storage for arbitrary data. You were unable to pay for the storage options they do provide because you did not have admin rights to the github account you wanted to work with.

None of this is a problem with git, be it GUI git clients or command line ones.

This isn’t just "technically correct". It’s the "a commercial company doesn’t have to provide you with a service if they don’t want to" kind of correct.

Re: Is Git Irreplaceable? (2019)

#305

Post by philbarr »

bhaak wrote: post #289
l0b0 wrote: post #22

It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information. - Solve at least one big problem with the…

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

Re: Is Git Irreplaceable? (2019)

#306

Post by chiefalchemist »

baud147258 wrote: post #294
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.

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.

Agreed. If the applications we built using git were as awkward as git...our users and clients would scream, or worse.

Re: Is Git Irreplaceable? (2019)

#307

Post by tialaramex »

mcv wrote: post #280
rimliu wrote: post #259

Earlier quoted context omitted.

I remember what was the go-to tool before git. It was Subversion. And CVS before that. I would not say people were happy with those tools.

I was happy with SVN because I used CVS before. I was even happy with CVS, because I had nothing before. It's hard to imagine now. Software development has seen massive improvements in the past 20 years. I see no reason why that would stop now.

Asymptotes. Sometimes it turns out we can solve a particular problem so comprehensively that "solve this problem better" is never a reasonable step. You can try it anyway, of course, but you're unlikely to get acknowledgement much less praise.

The answer to "Why doesn't my music sound as good as I wanted?" isn't going to be "CD's 44.1kHz and 16-bit PCM isn't enough". It might be "This cable has been chewed by a dog" or "These speakers you got with a cheap MIDI system in your student dorm are garbage" or even "the earbuds you're wearing don't fit properly" but it won't be the 44.1kHz 16-bit PCM.

Likewise, it is plausible that Git is done technology-wise. That doesn't mean there won't be refirements to how it's used, recommended branching strategies, auto-complete, or even some low-level stuff like fixing the hash algorithm - but the core technology is done.

Re: Is Git Irreplaceable? (2019)

#308

Post by xorcist »

rumanator wrote: post #196
hinkley wrote: post #175

Earlier quoted context omitted.

Git makes it easier to do a fork but you could certainly fork a subversion repo. I’m fairly certain you could sort of a merge process across multiple upstreams.

Git does far more than making it easy to fork: it makes it trivial and inexpensive. Meanwhile SVN supports forking in the sense that it supports copying directories.

The "fork" concept is not native to neither Subversion nor git.

You are probably thinking of branches and tags, and those are used similarly in both systems. They are a bit more convenient in git since they are created in constant as opposed to linear time.

Copies in Subversion are only metadata. Since partial clones are native to the system, it is simple to present both branches and tags as file paths. It was likely considered an easy user interface. Everything is a file and all that. In comparison, git users must learn the git object naming scheme, otherwise things can end up very confusing should you have a directory and a branch with the same name.

Re: Is Git Irreplaceable? (2019)

#309

Post by adrianmsmith »

rimliu wrote: post #262
rumanator wrote: post #143

Earlier quoted context omitted.

> 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…

Tree conflicts were only introduced in Subversion 1.6. https://subversion.apache.org/docs/release-notes/1.6.html#tr...
Post reply on HN