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

351–360 of 559 posts

Re: Is Git Irreplaceable? (2019)

#351

Post by smt88 »

mathw wrote: post #204
smt88 wrote: post #97

Earlier quoted context omitted.

Git is extremely user-unfriendly from the command line. It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space.

I tend to think that it's fine, because I remember what it used to be like... what we have now is the "easy" UI! And they do occasionally put some new stuff in that helps. Like the recent version which adds new commands to split out the two completely different uses for `git checkout` (making/switching branches and reverting files).

Between CVS and git, Canonical releases an excellent DVCS called Bazaar that I loved. I think we all ended up with git because of GitHub.

Re: Is Git Irreplaceable? (2019)

#352

Post by smt88 »

jack_h wrote: post #165
smt88 wrote: post #97

Earlier quoted context omitted.

Git is extremely user-unfriendly from the command line. It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space.

> It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space. In my opinion this is a problem with programming languages rather than version control. Namely we mix presentation and representation when using text as our source code. In the case of whitespace we have an infinite number of syntactic presentations which all correspond to the same seman…

> Git itself even has to deal with this because of platform differences, i.e. LF and CRLF.

I loathe this about git. It has caused my team members so many problems, like images marked as changed.

git should either be dumb about content or smart, not secretly in between.

Re: Is Git Irreplaceable? (2019)

#353

Post by rkangel »

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

I associate that particular madness with Bazaar rather than Mercurial. It stopped being standard practice a while ago, and those old tutorials should be updated or removed.

Re: Is Git Irreplaceable? (2019)

#354

Post by adrianmsmith »

ivanbakel wrote: post #345
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…

You can set up custom merge drivers for different file types. More importantly, if you've got stuff in your decentralised repo that shouldn't be decentralised, that's not the fault of the DVCS you're using, it's your fault. That everything looks like a nail does not speak against the value of a hammer.

> You can set up custom merge drivers for different file types

True, but there are inevitably some files which still cannot be merged, so the problem remains.

> More importantly, if you've got stuff in your decentralised repo that shouldn't be decentralised, that's not the fault of the DVCS you're using, it's your fault.

Indeed, if you want to store the history of your files - the whole software including the icons it uses, so that you can go back to any previous version and build it - and you chose a DVCS like Git, I would agree the fault was yours.

That's basically what I was arguing, that Git is the wrong choice if you have any binary assets like icons (even if those assets have small filesize) due to the lack of locking, sorry if I was unclear.

Re: Is Git Irreplaceable? (2019)

#355

Post by vvillena »

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

> 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 to learn more about git in a practical way, there's an awesome book called Git Recipes.

Re: Is Git Irreplaceable? (2019)

#356

Post by DaiPlusPlus »

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

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.

Re: Is Git Irreplaceable? (2019)

#357

Post by eyegor »

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

Harkening back to my early days of git, I have a rough guess as to what you can do to fix that. If all you want is remote master,

  git stash
  git checkout master
  git stash
  git fetch origin
  git reset --hard origin/master
and maybe a 'git rm -r --cached .' in case you have staged files you didn't intend to which stash failed to drop.

Re: Is Git Irreplaceable? (2019)

#358

Post by jerf »

DaiPlusPlus wrote: post #356
Ntrails wrote: post #332

Earlier quoted context omitted.

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

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: While I won't deny its UI carries along some dubious decisions carried over from the very first design, in 2020, basically, if you thing "Git really ought to be able to do [this sensible thing]", it can. It has that characteristic that open source software that has been worked on by a ton of contributors has, which is that almost anything you could want to do was probably encountered by somebody else and solved five years ago. It just may take some searching around to figure out what that is. (And on the flip side, when you read the git man pages and are going "Why the hell is that in there?", the answer may well be "a problem that you're going to have in six months".)

Re: Is Git Irreplaceable? (2019)

#359

Post by DaiPlusPlus »

Ace17 wrote: post #158
kemitche wrote: post #120

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…

I work for a 40-people game studio. A major limitation of git is how it deals with many "big" (~10Mb) binary files (3D models, textures, sounds, etc.). We ended up developing our own layer over git, and we're very happy ; even git-lfs can't provide similar benefits. This technique seems to be commonplace for game studios (e.g Naughty Dog, Bungee), so certainly git has room for improvement here.

Aren’t game studios and other creative studios meant to use “asset management” systems instead for their large binaries?

Diffing a PSD as a binary is impossible - whereas proper asset management tools will deconstruct the PSD’s format to make for a human-readable diff (e.g. added/removed layers, properties, etc).

Re: Is Git Irreplaceable? (2019)

#360

Post by cmrdporcupine »

ldiracdelta wrote: post #344
baud147258 wrote: post #343

Earlier quoted context omitted.

>the interface makes a lot more sense if you understand the underlying data structure Except that I don't have to understand the underlying data structure to use a more basic VCS like Mercurial. What makes git so special that I would have to do that before being able to use it? And for recovery from mistakes, I meant stashing the changes somewhere, deleting the repository and downloading a clean copy to start again,…

You also don't have to understand the underlying structure for a similarly powerful DVCS like bitkeeper. Yes, it isn't open source, but git was a major step back in usability for my group from bk to git.

Yes, this. I actually tried bk before git, and actually used bazaar and then mercurial before git as well. I was stunned at how arcane the UI in git was made (And how arrogant the community of users around it could be, too). Bk was clean and elegant frankly. I'm no idiot when it comes to the concepts -- but git's CLI interface is just awful.

Bitkeeper is in fact open source now, BTW. Too late, but it is.

Post reply on HN