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

391–400 of 559 posts

Re: Is Git Irreplaceable? (2019)

#391

Post by chousuke »

jorvi wrote: post #382
jerf wrote: 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.

How would it be gone? You can't rebase onto a dirty working directory so you can't blow away uncommitted changes accidentally and any state prior to and during the rebase is always recoverable via the reflog.

It takes trying to do anything that's not easily recoverable as long as you commit before you start messing around and don't rm -rf .git.

Re: Is Git Irreplaceable? (2019)

#392

Post by afiori »

u801e wrote: post #337
mikece wrote: post #320

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…

Git has a low level plumbing layer and a high level porcelain layer. The design allows for writing alternative porcelain layers. I believe magit is an example of this.

Magit is the only example of this

Re: Is Git Irreplaceable? (2019)

#393

Post by munmaek »

adrianmsmith wrote: post #339
saurik wrote: post #279

Earlier quoted context omitted.

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

You should not be checking in binary files into git. That defeats the entire purpose and bloats the repo size enormously.

Git LFS should be used instead. Or storing a Sha256sum and putting the file elsewhere.

Re: Is Git Irreplaceable? (2019)

#394

Post by wyoung2 »

jat850 wrote: post #361
barrkel wrote: post #316

Earlier quoted context omitted.

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…

Can you explain what you mean by fossil being a competitor for github, rather than git? Fossil is a scm with additional features for usage, but (the last I used it, and to my memory) it was just the command line fossil very much like git, and that's how I used it. What makes it the case that fossil cannot be a competitor to git (or hg), in that they are both a vcs? edit I haven't had a lot of sleep. What I'm trying t…

You can, though I suspect the OP's focus on speed means you'd want to turn off Fossil's autosync feature, which makes it operate more like Git: checkins go only the local repository initially, and then you must later explicitly push them to the repo you cloned from.

This is why Subversion was "slow": your local working speed was gated by the speed of the central repo, which could be slow if it was under-powered or overloaded, as was common with the free Subversion hosts of the day. At least with Git, you can batch your local changes and push them all at some more convenient time, such as when you were going off for a break anyway.

Re: Is Git Irreplaceable? (2019)

#395

Post by rohansingh »

jorvi wrote: post #382
jerf wrote: 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.

It's definitely not gone. Just `git checkout ORIG_HEAD` and you'll be back to whatever the tree was before you rebased.

Re: Is Git Irreplaceable? (2019)

#396

Post by jerf »

jorvi wrote: post #382
jerf wrote: 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.

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 want some sort of hypothetical source control system that literally tracks every change I make. It's technically conceivable and should be practical to what would at least be considered a "medium sized" project in the git world, but I'd just be buried in the literally thousands of "commits" I'd be producing an hour. Failing that sort of feature, a source control system can't help but "lose" things not actually put into it.)

Re: Is Git Irreplaceable? (2019)

#397

Post by tzury »

Bazaar and Mercurial are dying... Bazaar is dead, and Mercurial is near death.

Linus wrote the Linux kernel and it became the "de-facto standard" for web application stack servers (and phones, and watches, and Chroemcast and all sort of `Internet things`)

Linus wrote git and it became the "de-facto standard" for version control.

If a world had 23 more Linuses, we would have full control over our SaaS and "Clouds" and not locked-in as we are at the moment.

But we have only one like him.

Re: Is Git Irreplaceable? (2019)

#398

Post by sergiosgc »

jorvi wrote: post #382
jerf wrote: 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.

It won't be gone until you actively prune dangling commits. The commit may not be reachable from the HEADs of existing branches, but go through the reflog and your commits will be there. You can then create a branch to make the commit reachable.

Re: Is Git Irreplaceable? (2019)

#399

Post by jordigh »

coldpie wrote: post #347
rkangel wrote: post #341

Earlier quoted context omitted.

Mercurial does absolutely not require you copying at the fs level. You're not the first person to be caught out by that tutorial, which I think would serve us best by being deleted. The 'original' branching method for Mercurial is called Named Branches. The big difference with Git is that every commit is labelled with what branch it is on. This has advantages - if you imagine looking at the train track of 'master' in…

It's not just that tutorial, see also [1,2]. I think this is/was really an "official" way to do branching, and it seems utter madness to me :) [1] Sadly the popular hginit.com seems dead, this was my first introduction to Mercurial. https://web.archive.org/web/20180722012242/http://hginit.com... [2] https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m...

Branching by cloning was copied from bitkeeper. It was also early git's only branching mechanism. If you listen to Linus's talk when he introduced git at Google, you'll hear him conflate "branch" with "clone" because that's what he was thinking of at the time.

https://www.youtube.com/watch?v=4XpnKHJAok8

Re: Is Git Irreplaceable? (2019)

#400

Post by philwelch »

cousin_it wrote: post #263
rumanator wrote: post #140

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

By that logic we'd all be using Lotus Notes.
Post reply on HN