Live data from Hacker News

Is Git Irreplaceable? (2019)

fossil-scm.org

461–470 of 559 posts

Re: Is Git Irreplaceable? (2019)

#461
post #382
post #358

Earlier quoted context omitted.

It's called "git reflog": https://www.edureka.co/blog/git-reflog/ Though you do have to have committed. One of the things I hammer on in my tutorials for work is that if you get confused in git, make sure you commit. If you commit, you can take your problem to the other engineers and we can almost certainly get you straightened away. Fail to commit, though, and you really may lose something. Also, metapoint about git…

> make sure you commit This is not absolute gospel. If you screw up a rebase and commit, whatever you removed in the rebase is simply gone.

NO. Nothing is gone after commit. You just don't see it.

Make a git log --reflog --all and you will see all the commits you made (or rebase made) in the last 3 months.

You can than rescucitate an old branch by simply putting a branch name on it with git branch newname

Re: Is Git Irreplaceable? (2019)

#462

Earlier quoted context omitted.

The main thing that people fail to understand is that commits are immutable and the overall commit graph is immutable (with the caveat that pathways in the graph that don't end in a branch head are subject to garbage collection). A rebase does not destroy information. It creates new commits and moves the branch head to a different spot on the graph. The reason git is seen as painful is because you can't claim experti…

That GC a pretty big caveat! Combined with the fact that unreferenced objects are never pushed. reflog is like undelete in filesystems, it's a probabilistic accident recovery mechanism for an individual computer (repo checkout in this case) that you can try to use if you don't have backups.

In any case, git garbage collection isn't a common phenomenon. It usually triggers every few weeks, even in repos with high activity. The chance of hitting a GC that deletes an untracked commit you need is extremely small.

Re: Is Git Irreplaceable? (2019)

#463
post #396

Earlier quoted context omitted.

Are you saying that with knowledge of what "git reflog" is? I suspect not. I'd really need to see a sequence of commands that removes committed state from the repo to buy this. If you try to produce it, bear in mind the first thing I'm going to do is run "git reflog" on the result, so if you find your committed state is still there, then I'm going to say it's still saved. (That's not a git thing. I don't really even…

As I am not familiar with the details of reflog (I don't recall ever using it) I took a look at the article. I wasn't long until I reached what looks like a caveat: "This command has to be executed in the repository that had the lost branch. If you consider the remote repository situation, then you have to execute the reflog command on the developer’s machine who had the branch." Joe, who works on another continent,…

git log --reflog --all

is the more important imo than

git reflog

Re: Is Git Irreplaceable? (2019)

#464
post #449

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

Hey, are you a fossil dev? I haven't used nor looked at fossil in maybe 5 years, but had a couple of questions. Does fossil now have any kind of email support built in to the ticket manager? I remember when I tried to use fossil for actual production use, there was no way to trigger emails sent when, e.g. tickets were submitted, and one of the devs said to just write a script to monitor the fossil rss feed and send t…

> Hey, are you a fossil dev?

I have commit access, yes, but mainly I work on the docs.

> Does fossil now have any kind of email support built in to the ticket manager?

Yes. It was added in support of the forum feature last year, but it also applies to several other event types: https://fossil-scm.org/fossil/doc/trunk/www/alerts.md

> one of the devs said to just write a script to monitor the fossil rss feed

Probably me. :)

> seemed like a baroque and fragile (and time-consuming) solution.

A dozen lines of Perl; easy-peasy. That and a pile of CPAN modules, but that's easily fetched with `cpanm`.

> the mv/rm behavior -- affecting the file on disk as well as the repository

The default you're referring to was changed a few years ago: the old `--hard` option is now the default.

Re: Is Git Irreplaceable? (2019)

#465

Earlier quoted context omitted.

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

> 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". Yeah, try telling this to a fan of 1960s or 1970s rock. You'll get an earful about rich guitars and fat synths, which only a 100% analog, tube-amp process from studio to ear is capable of replicating.

> Yeah, try telling this to a fan of 1960s or 1970s rock. You'll get an earful about rich guitars and fat synths, which only a 100% analog, tube-amp process from studio to ear is capable of replicating.

And anyone with a basic understanding of electronics should laugh in the faces of these people. The idea that a signal can be carried on a wire or recorded on tape but can not be replicated digitally is absolute nonsense.

If someone wants to claim that their preferred format captures higher frequencies than 44.1kHz sampling allows for, that's at least plausible, but that can be solved by using higher sampling rates like 96 or 192 kHz. At that point you've exceeded the capabilities of all mainstream analog storage media.

If they are looking for specific effects created when pushing the limits of analog hardware, like the "crunch" of a tube amp, that's fine too, but they need to acknowledge that they're treating the amp as an instrument in that case and its output can still be recorded digitally just fine.

Re: Is Git Irreplaceable? (2019)

#466

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

> their thing: Sprawling, incoherent, and inefficient > our thing: Self-contained and efficient This is not biased in any way and makes me want to continue reading. /s Also, you can’t claim something to be “efficient” when it’s doing many different things like scm, issues/tickets, a web forum/ui .... Then you have non-issues like git being installed via a package manager instead of dragging and dropping a binary. Yea…

> This is not biased in any way

Of course we're biased, but every row in that table corresponds to a section below where we lay out our argument for the few words up in the table at the top.

Here's the direct link for that particular point:

https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

Now, if you want to debate section 2.2 on its merits, we can get into that.

> you can’t claim something to be “efficient” when it’s doing many different things

We can when all of that is in a single binary that's 4.4 MiB, as mine here is.

A Git installation is much larger, particularly if you count its external dependencies, yet it does less. That's what we mean when we say Git is "inefficient."

But I don't really want to re-hash the argument here. We laid it out for you already, past the point where you stopped reading.

> git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm).

It is on Windows, where they had to package 44-ish megs of stuff in order to get Git to run there.

On POSIX platforms, the package manager isn't much help when you want to run your DVCS server in a chroot or jail. The more dependencies there are, the more you have to manually package up yourself.

If your answer to that is "just" install a Docker container or whatever, you're kind of missing the original point. `/home/repo/bin/fossil` chroots itself and is self-contained within that container. (Modulo a few minor platform details like /dev/null and /dev/urandom.)

> This page needs to be rewritten to simply list the differences in neutral language.

We accept patches, and we have an active discussion forum. Propose alternate language, and we'll consider it.

> unnecessary epithets like “caused untold grief for git users”

You don't have to go searching very hard to find those stories of woe. They're so common XKCD has satirized them. We think the characterizations are justified, but again, if you think they're an over-reach, propose alternate language.

> I don’t want something that tries to do many different things all at once.

Not a GitHub user, then?

Re: Is Git Irreplaceable? (2019)

#467
post #220

Earlier quoted context omitted.

I disagree that Git's biggest flaw is its lack of scalability. Cases where git needs to scale tend to be isolated to companies that have the manpower to build a finely-tuned replacement (see: MS, Google). Git's flaws are primarily in usability/UX. But I think for its purpose, functionality is far more important than a perfect UX. I'm perfectly happy knowing I might have to Google how to do something in Git as long as…

Maybe I am a weirdo but I have always thought that git's UI is very intuitive (with some exceptions like sub modules). SVN on the other hand was an unintutive mess where I had to look up commands all the time.

Agreed - I had been looking around this thread like, " - surely I'm not the only one that finds git to be a rewarding exercise in teamwork?"

Re: Is Git Irreplaceable? (2019)

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

>> The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Agreed. Technology should converge on a best solution so we can stop chasing things and get work done. Stable open source standard solutions are what we need more of. Some anti-pattern examples are C++ and Vulcan.

> Some anti-pattern examples are C++ and Vulcan.

Are you referring to the Vulkan API? If so, why do you see it as an anti-pattern example?

I like the API and I think it is a great and necessary improvement over OpenGL. I actually hope to see Vulkan become the ‘stable open source standard solution’ for graphics.

Re: Is Git Irreplaceable? (2019)

#469
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 like a dozen Perl and shell scripts taped together with a tiny bit of Tcl on the side. It is nowhere near elegant. It's a monstrosity.

Re: Is Git Irreplaceable? (2019)

#470
post #421

Earlier quoted context omitted.

> Usually I accidentally committed to local master and then did a couple other things Create a new branch and check it out while you are on the last commit (git checkout -b my-branch), delete the master branch (git branch -D master), and pull it again (git pull -u origin master). You'll end up with a local branch with a bunch of commits that you can merge, rebase or cherrypick, depending on what you want. If you want…

Is there a reason for -D and not -d? Wouldn't -D also delete the remote branch if you accidentally pushed your changes?

`-D` doesn't involve the remote at all (unless you are using something like the intentional remote:branch syntax which this example isn't). It is a force delete in that if there were commits locally in that branch and only in that branch it should still delete that branch. It should be unlikely you need that force because the first step was to branch everything as is, so it is safer to just use `-d`, but if the intention is to "blat" it from orbit anyway, `-D` is that.
Post reply on HN