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

471–480 of 559 posts

Re: Is Git Irreplaceable? (2019)

#471

Post by jnurmine »

wyoung2 wrote: post #439
munmaek wrote: post #387

Earlier quoted context omitted.

With the amount of information available, there is no excuse: * https://rogerdudler.github.io/git-guide/ * https://git-scm.com/book/en/v2 Also see stackoverflow. Git is a complex tool because it’s tackling a complex problem. I don’t see a way of making it “easier” without massively reducing what it can do. It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc. If somet…

> Git is a complex tool because it’s tackling a complex problem. Fossil tackles much the same sort of problem, yet it's far simpler to use. Most of Git's problems are due to purposeful choices, but they're design choices , not inherent aspects of how a DVCS must behave. We've laid out our case for the differences here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

By the way, the "one checkout per repository" is not strictly true. You can use "git worktree"; this is a lightweight way to reuse an existing git repository and have each worktree use a different branch. It's a nice feature, and I use it daily.

Also, a comment about the argumentation in "test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relation is in a sane workflow. Certainly, one can push untested stuff to the remote server by mistake; but, even so, this should be OK, because if one can push directly to important branches like master or similar without going through any reviews and other sanity checks, one has a problem... and the problem isn't really Git :)

Re: Is Git Irreplaceable? (2019)

#472

Post by lrem »

alkonaut wrote: post #228
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.

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…

Said 80/20 was the idea behind Fossil, along the "easy to learn because similar to svn". Seemed a good idea. But lost to having a famous user, which the Linux kernel obviously is.

Re: Is Git Irreplaceable? (2019)

#473

Post by WorldMaker »

wyoung2 wrote: post #386
adrianmsmith wrote: post #339

Earlier quoted context omitted.

Another thing Git does not and cannot even attempt to do - file locking. The assumption behind Git is, everyone develops on their machines and/or branches, and then things are merged. This only works for files which can be merged. There are plenty of things pretty much any project wants to track which cannot be merged, for example Word documents (documentation), Photoshop files (source of graphics), PNGs (icons in we…

> Another thing Git does not and cannot even attempt to do - file locking. That's a seriously hard problem for a DVCS if you're serious about the "D". This topic turned into [the single longest thread in the history of the Fossil forum]( https://www.fossil-scm.org/forum/forumpost/2afc32b1ab ) because it drags in the CAP theorem and all of the problems people run into when they try to have all three of C, A, and P at…

> Instead of Word files, check in Markdown or [FODT]

Another fun option is to unzip the DOCX and check that in, since it is mostly a collection of XML files in a zip container. I built a tool to automate zipping/unzipping files like DOCX years ago as pre-commit/post-checkout/post-merge hooks. [1] It's an interesting way to source control some types of files if you can find a way to deconstruct them into smaller pieces that merge better. Admittedly, merging Office Open XML by hand is not a great experience (and dealing with subtly broken or corrupt internal contents is not fun, because programs like Word can fussy when things are even slightly wrong), but you get better diffs sometimes than you would expect.

[1] https://github.com/WorldMaker/musdex

Re: Is Git Irreplaceable? (2019)

#474

Post by josefx »

Frondo wrote: post #447
munmaek wrote: post #442

Earlier quoted context omitted.

Git already has layers on top of it like git porcelain or the various GUI tools that attempt to handle things smoothly. > significant time and energy All someone needs is to read through https://rogerdudler.github.io/git-guide/ , and learn a few commands. Are we seriously going to refer to “reading the manual” as “significant time and energy”? In this case you don’t even have to read the manual, just a primer on how…

Because a lot of us have used tools besides git that enable the workflow we need without that complexity, and without the fragility that often necessitates going to stackoverflow or asking on a slack channel. I have a way of picking the losing side so I've been using mercurial for everything until now, and until now Bitbucket offered hg. They're decommissioning it so I'm moving over to git and I feel like my workflow…

> Because a lot of us have used tools besides git that enable the workflow we need without that complexity

I spend ages unfucking local svn working copies and long running branches on both windows and linux. git needs some serious flaws to keep up with that experience.

Re: Is Git Irreplaceable? (2019)

#475

Post by bhaak »

jerf wrote: post #350
bhaak wrote: post #284

Earlier quoted context omitted.

None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used. Sure, not being able to rename a file easily in CVS was quite an annoyance but nothing that made it completely useless. There were always workarounds. But exactly those areas were workarounds or better tooling patches over stuff Git doesn't do are the areas that a possible successor will address.

"None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used." That's just quibbling about definitions in fuzzy English. If you want to insist they weren't "fatally flawed" at the time, fine, but they certainly are relative to 2020 even by your definition.

They still work. You can still develop with them. In that sense they aren't fatally flawed even today.

2018, 16% still used Subversion. https://insights.stackoverflow.com/survey/2018#development-p...

But that's the hope, that we have something better by 2040, that makes today's Git look as outdated as CVS/Subversion looks to us now.

Re: Is Git Irreplaceable? (2019)

#476

Post by WorldMaker »

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…

Most language ASTs don't encode unfinished or work-in-progress code very well (the difference in AST shape between missing one `{` and the fixed code can be substantial). You may think it better to always only commit working code, but your source control system is also a backup system if you need to save a work in progress branch to come back to it, and also sometimes a communications system if you want to request a coworker examine your code to help you pinpoint bugs you can't find or review work in progress.

Most language ASTs also don't encode useful-to-the-programmer but useless-to-the-compiler information like comments and whitespace. There's been good progress in that (the Roslyn AST system has some neat features), but in practice an AST is always intended more for the compiler than the user/source writer. This also is reflected often in speed, a lot of languages have a relatively slow AST generation (which would add sometimes very noticeable wall clock time to commit time, depending of course on language and hardware).

Plus, of course, all the usual bits that ASTs are extremely varied among themselves (some are weirder DAG shapes than trees, for instance).

An experiment I ran was to the use the "next step down" from full AST which is your basic tokenizer / syntax highlighter. Those designed to deal well with malformed/unfinished/work-in-progress input, and to do it very quickly. Years back I built a simple example diff tool that can do token-based diffs for any language Python's commonly used syntax highlighter Pygments supports. [1] In my experiments it created some really nice character-based diffs that seemed "smart" like you might want from an AST-like approach but just by doing the dumb thing of aligning diff changes to syntax highlighting token boundaries.

You could even use it/something like it/something based on it today as your diff tool in git if you wanted, with the hardest part configuring it for which language to use for what file. (I never did do that though, partly because the DVCS I experimented with this for didn't have a pluggable diff system like git does, nor did it support character based unidiff as a storage format which the experiment was partly to prove both ideas could be useful.)

[1] https://github.com/WorldMaker/tokdiff

Re: Is Git Irreplaceable? (2019)

#477

Post by jerf »

bhaak wrote: post #475
jerf wrote: post #350

Earlier quoted context omitted.

"None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used." That's just quibbling about definitions in fuzzy English. If you want to insist they weren't "fatally flawed" at the time, fine, but they certainly are relative to 2020 even by your definition.

They still work. You can still develop with them. In that sense they aren't fatally flawed even today. 2018, 16% still used Subversion. https://insights.stackoverflow.com/survey/2018#development-p... But that's the hope, that we have something better by 2040, that makes today's Git look as outdated as CVS/Subversion looks to us now.

You're really doubling down on applying deliberately hostile definitions to what I said, aren't you? I get to tell you what I meant. You don't get to pick the definitions I was using, especially after I told you you explicitly you picked the wrong one.

Re: Is Git Irreplaceable? (2019)

#478

Post by rumanator »

adrianmsmith wrote: post #290
rumanator wrote: post #281

Earlier quoted context omitted.

> I don't remember a time when Subversion didn't support branches. SVN's official response to branching and tagging was to copy directories around in the repository. Arguably that means it does not support branching, at least according to the concept that has been in place for the last decade.

That's true that there was no command "svn branch", there was only the command "svn copy". It's true that command could have been better named, like many Git commands could have been better named. However, don't let that confuse you. The "svn copy" command creates a new place where you can do independent development, and where afterwards merging back can occur. So it's the same as a branch by that definition. An "svn…

> That's true that there was no command "svn branch", there was only the command "svn copy". It's true that command could have been better named, like many Git commands could have been better named.

It was not a naming issue. It was a bona fide lack of support for a basic feature. The manual itself states quite clearly that in SVN land you create a branch by copying around the entire working directory within your repository. SVN's manual is quite clear on how SVN actually tracks the state of a file system, and not the state of a source code tree. By copying the working directory around the repository you're creating new revisions of your file system. That' it. Just because you can diff two directories it does not mean copying a directory around in a file system is a branch. And nor is it a tag.

Re: Is Git Irreplaceable? (2019)

#479

Post by wyoung2 »

jnurmine wrote: post #471
wyoung2 wrote: post #439

Earlier quoted context omitted.

> Git is a complex tool because it’s tackling a complex problem. Fossil tackles much the same sort of problem, yet it's far simpler to use. Most of Git's problems are due to purposeful choices, but they're design choices , not inherent aspects of how a DVCS must behave. We've laid out our case for the differences here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

By the way, the "one checkout per repository" is not strictly true. You can use "git worktree"; this is a lightweight way to reuse an existing git repository and have each worktree use a different branch. It's a nice feature, and I use it daily. Also, a comment about the argumentation in "test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relat…

> By the way, the "one checkout per repository" is not strictly true.

You must be referring to just the table at the top, not to the detailed argument below, which mentions git-worktree and then points you to a web search that gives a bunch of blog articles, Q&A posts, project issue reports and such talking about the problems that come from using that feature of Git.

I suspect this is because git-worktree is a relatively recent feature of Git (2.5?) so most tutorials aren't written to assume use of it, so most tools don't focus on making it work well, so bugs and weaknesses with it don't get addressed.

Fossil is made to work that way from the start, so you can't run into these problems with Fossil. You'd have to go out of your way to use Fossil in the default Git style, such as by cloning into ~/ckout/.fossil and opening that repo in place.

> test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relation is in a sane workflow.

That just brings you back to the problems you buy when separating commit from push, which we cover elsewhere in that doc, primarily here: https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...

Re: Is Git Irreplaceable? (2019)

#480

Post by wyoung2 »

WorldMaker wrote: post #473
wyoung2 wrote: post #386

Earlier quoted context omitted.

> Another thing Git does not and cannot even attempt to do - file locking. That's a seriously hard problem for a DVCS if you're serious about the "D". This topic turned into [the single longest thread in the history of the Fossil forum]( https://www.fossil-scm.org/forum/forumpost/2afc32b1ab ) because it drags in the CAP theorem and all of the problems people run into when they try to have all three of C, A, and P at…

> Instead of Word files, check in Markdown or [FODT] Another fun option is to unzip the DOCX and check that in, since it is mostly a collection of XML files in a zip container. I built a tool to automate zipping/unzipping files like DOCX years ago as pre-commit/post-checkout/post-merge hooks. [1] It's an interesting way to source control some types of files if you can find a way to deconstruct them into smaller piece…

Yes, I cover that option for Fossil at the end of the pointed-to document. I did it in terms of Makefiles rather than commit hooks, but whichever...
Post reply on HN