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

481–490 of 559 posts

Re: Is Git Irreplaceable? (2019)

#481

Post by hinkley »

roca wrote: post #247
hinkley wrote: post #183

Earlier quoted context omitted.

Bob Martin claims at various points in time that half of all developers have less than five years experience, and attrition and expansion of CS degrees has maintained this. Five years after introducing a replacement you could have half a team that never used it at all, just like SVN is now.

Only if those people never have to learn git in those five years. Maybe in some niches they wouldn't have to, but lots would.

So you think git will be different from SVN when a new contender comes along?

Re: Is Git Irreplaceable? (2019)

#482

Post by alkonaut »

jnurmine wrote: post #432
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…

Maybe for your particular problem it's worthwhile to setup a CM policy for the (topic) branch naming. For example in your case something like: topic/alkonaut/version-1.0/foo or topic/alkonaut/master/bar. Or use something like: git log --all --graph --oneline One tip for "zigzag spiderweb" is to always rebase your topic branch to the target branch prior to a fast-forward merge to the target branch (e.g. master). To cl…

Rebase + FF solves the spiderweb problem by removing the branches. But some insist on keeping the branches and I don’t get why a “git log” doesn’t have (and default) to showing important branches as straight lines.

Also with dozens of tiny commands but only a handful of actual desired outcomes, the high operations should be explicit commands. E.g “rebase this branch on master and then squash it and commit on master”.

A lot of the local/remote could also be hidden. The number of times I want to rebase on my local master which is behind origin by 2 commits is... zero.

Re: Is Git Irreplaceable? (2019)

#483

Post by alkonaut »

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…

I’d guess not one user in 100.000 uses git decentralized (as in, doesn’t have a blessed “central” repo). It’s the disabling of locking that should be the special case! The big problem with git is that you can’t mark a repo as a master repo/blessed repo (which would be the one where lockfiles are stored). A lot of functionality would be helped if the commands could know which end is the important/central one.

Re: Is Git Irreplaceable? (2019)

#484

Post by u801e »

munmaek wrote: post #387
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

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…

> It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc

A far better analogy is:

It's like saying we should reduce a programming language so people can use it without reading up on it, etc.

Re: Is Git Irreplaceable? (2019)

#485

Post by lodi »

DaiPlusPlus wrote: post #359
Ace17 wrote: post #158

Earlier quoted context omitted.

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

Separate version control for code vs assets leads to a world of pain. Also you can use whatever diff tool you want; doesn't have to be the built-in textual diff.

Re: Is Git Irreplaceable? (2019)

#486

Post by wyoung2 »

alkonaut wrote: post #483
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…

I’d guess not one user in 100.000 uses git decentralized (as in, doesn’t have a blessed “central” repo). It’s the disabling of locking that should be the special case! The big problem with git is that you can’t mark a repo as a master repo/blessed repo (which would be the one where lockfiles are stored). A lot of functionality would be helped if the commands could know which end is the important/central one.

> I’d guess not one user in 100.000 uses git decentralized

I understand your sentiment, but the denominator in that fraction is probably much lower than your guess.

Consider even simple cases like the disconnected laptop case. You may work at a small office with only local employees, and so you have one central "blessed" repo, but if one person locks a file and then goes off to lunch, working on the file while at the restaurant, you still have a CAP problem:

CA: Because the one guy with a laptop went off-network, you have no full quorum, so no one can use the repo at all until he gets back and rejoins the network. (No practical DVCS does this, but it's one of the options, so I list it.)

CP: When the one guy went off to lunch, we lost the ability to interact with his lock, and that will continue to be the case until he gets back from lunch. Also vice versa: if someone still at the office takes out a lock, the guy off at lunch doesn't realize there is lock, so he could do something bad with the "locked" file. (This is the mode DVCSes generally run in by default.)

AP: No locking at all, thus no consistency, thus your original problem that inspired the wish to have file locking.

Re: Is Git Irreplaceable? (2019)

#488

Post by ori_b »

debaserab2 wrote: post #418
ori_b wrote: post #374

Earlier quoted context omitted.

I also can't figure out why it doesn't: An empty tree object should be sufficient to do the job. I actually had to write extra code in git9[1] to avoid accidentally allowing empty directories. [1] https://github.com/oridb/git9

According to this[1], which I think might be an official FAQ: > Currently the design of the Git index (staging area) only permits files to be listed, and nobody competent enough to make the change to allow empty directories has cared enough about this situation to remedy it. [1] https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty...

Hm. I should see how git behaves when it gets a repository with empty directories. If it doesn't blow up, I may just add support -- it'd be useful for me.

Re: Is Git Irreplaceable? (2019)

#489

Post by l0b0 »

glandium wrote: post #153
l0b0 wrote: post #22

It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information. - Solve at least one big problem with the…

- Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism. https://github.com/git/git/blob/master/Documentation/technic...

Thanks; admittedly the last time I looked into this was a few years ago. Glad to see it gaining traction!

Re: Is Git Irreplaceable? (2019)

#490

Post by blt »

romwell wrote: post #58

When people talk about killer features missing in Git, there is more beyond the UX and mono/poly repo. One thing is code review. There is no code review in Git. What I expect in 2020 is that I should be able to specify reviewers for the commit (which I pick out of a list of people who can approve it). These people should be able to leave comments on the commit. I should be able to both respond to comments and modify…

Sounds like the Google workflow.
Post reply on HN