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

381–390 of 559 posts

Re: Is Git Irreplaceable? (2019)

#381

Post by rjsw »

Ntrails wrote: post #332
alkonaut wrote: post #228

Earlier quoted context omitted.

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…

As a very basic git user, about once a month my local git repository will get into a state I cannot fix. I cannot revert, cannot reset, cannot make it just fucking be the same as origin/master. Usually I accidentally committed to local master and then did a couple other things and it's just easier to blat and re-clone than work out how to resolve. Git is hard for idiots imo, and there are a lot of us

The workflow that I have found works best is to just not change anything myself, I let other people do all the work. This way I can be sure that I won't get merge conflicts that I can't fix.

Re: Is Git Irreplaceable? (2019)

#382

Post by jorvi »

jerf wrote: post #358
DaiPlusPlus wrote: post #356

Earlier quoted context omitted.

I wish git had a “metahistory” feature to allow everyone to undo anything. A `git revert` isn’t of any help when you’ve already merged and pushed.

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.

Re: Is Git Irreplaceable? (2019)

#383

Post by Iwan-Zotow »

orf wrote: post #327
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…

There is, it's the .git directory. Both the protocol and the directory are well specified. See libgit2 for an example non-reference implementation. I think someone even built an implementation in bash, but I can't seem to find it now.

> I think someone even built an implementation in bash, but I can't seem to find it now.

someone named Linus, I guess?

Re: Is Git Irreplaceable? (2019)

#384

Post by SketchySeaBeast »

madmulita wrote: post #248
n0rbwah wrote: post #238

Earlier quoted context omitted.

If the tool you have works well for your use case, looking for and learning to use a "better tool" can be a waste of your time with little benefit.

And that's how you can get stuck in a local maximum.

With the exception of very very singular people, isn't every maximum going to be local? Even then they'll be stuck in a bunch of other local maximum's outside their own area of expertise.

Re: Is Git Irreplaceable? (2019)

#385

Post by crdoconnor »

alkonaut wrote: post #255
dragonwriter wrote: post #236

Earlier quoted context omitted.

> 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. That's what UIs (whether CLIs or otherwise) for standardized workflows like git-flow are, IMO.

It doesn't nearly go all the way there though. Why do people need to use a command line and a gui tool (usually) for git? Because it's fundamentally not written to be used with a GUI. That I think is one of its biggest flaws. Using a GUI with git always feels like you are missing vital information and just trying to poke a cli underneath to do what you want. Some design decisions also shine through like "no branch is…

Most of the guis are crap because everybody who builds them thinks that a GUI should just be a more or less a visual representation of the command line.

Re: Is Git Irreplaceable? (2019)

#386

Post by wyoung2 »

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…

> 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 the same time.

To the extent that Fossil based projects are usually more centralized than Git ones, Fossil has a better chance of solving this, but I'm still not holding my breath that Fossil will get what a person would naively understand as file locking any time soon.

> Word documents (documentation), Photoshop files (source of graphics), PNGs (icons in webapps), and so on.

You want to avoid putting such things into a VCS anyway, because it [bloats the repo size](https://fossil-scm.org/fossil/doc/trunk/www/image-format-vs-...). I wrote that article in the context of Fossil, but its key result would replicate just as well under Git or anything else that doesn't do some serious magic to avoid the key problem here.

Instead of Word files, check in Markdown or [FODT](https://en.wikipedia.org/wiki/OpenDocument_technical_specifi...). (Flat XML OpenDocument Text.) Or with Fossil, put the doc in the wiki.

Instead of PNG, check in BMP, uncompressed TIFF, etc., then "build" the PNG as part of your app's regular build process.

This has the side benefit that when you later change your mind on the parameters for the final delivered PNGs, you can just adjust the build script, not check in a whole new set of PNGs. My current web app has several such versions: 8-bit paletted versions from back before IE could handle 24-bit PNG, then matted 24-bit PNGs from the days when IE couldn't handle transparency in PNG, and finally the current alpha-blended 24-bit PNGs. It'd have been better if I'd checked in TIFF originals and built deliverable PNGs at each step.

Re: Is Git Irreplaceable? (2019)

#387

Post by munmaek »

Ntrails wrote: post #332
alkonaut wrote: post #228

Earlier quoted context omitted.

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…

As a very basic git user, about once a month my local git repository will get into a state I cannot fix. I cannot revert, cannot reset, cannot make it just fucking be the same as origin/master. Usually I accidentally committed to local master and then did a couple other things and it's just easier to blat and re-clone than work out how to resolve. Git is hard for idiots imo, and there are a lot of us

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 something happens once, it happens. If something happens multiple times then it means you’re not evaluating why it occurred in the first place and learning from it. No tool in the world can solve this problem because it’s not a problem with the tool, rather the user.

Git is really not so hard, but it requires a little reading.

Re: Is Git Irreplaceable? (2019)

#388

Post by orf »

Iwan-Zotow wrote: post #383
orf wrote: post #327

Earlier quoted context omitted.

There is, it's the .git directory. Both the protocol and the directory are well specified. See libgit2 for an example non-reference implementation. I think someone even built an implementation in bash, but I can't seem to find it now.

> I think someone even built an implementation in bash, but I can't seem to find it now. someone named Linus, I guess?

No, it was someone exploring git internals by writing a simple git implementation in bash.

Re: Is Git Irreplaceable? (2019)

#389

Post by munmaek »

brigandish wrote: post #379
vvillena wrote: post #355

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…

That is not easier than "blat and re-clone" so I think you're proving their point.

If you’re just going to blat and reclone, then you may as well use a folder system instead of git.

I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes.

Re: Is Git Irreplaceable? (2019)

#390

Post by vrsfvwae5tbh »

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.

Does this not show up in the reflog?
Post reply on HN