Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What comes after Git

matt-rickard.com

Post reply on HN
Print view View original

91–100 of 430 posts

Re: What comes after Git

#91

Post by hackernewds »

enasterosophes wrote: post #52
tedk-42 wrote: post #30

Oh god this author again going after clicks for hit pieces on technology without providing any alternatives. If you think you can do it better then go ahead and try build the product and then pitch it.

I didn't recognize the author, but came here to say the same thing: where are the ideas on how these improvements would be implemented? Without making an attempt at implementation, you (the generic you, not the person I'm replying to) have no idea what the real issues are. Even failed or partial implementations are more instructive than armchair criticisms, or thought experiments where you can just handwave away all…

The skills necessary to solve a problem, are also the skills necessary to realize there is one in the first place.

Re: What comes after Git

#93

Post by gspr »

funklute wrote: post #43
gspr wrote: post #27

Earlier quoted context omitted.

With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed. And do you seriously not see the need of rebasing? Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.

> And do you seriously not see the need of rebasing? Rebasing isn't actually necessary, and there's a good argument to be made that you should never rebase. Fossil (the version control system used by the sqlite team) doesn't have any rebasing mechanism: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... (there are of course also very good arguments in favour of rebasing, but my point is simply that it is…

Of course it isn't necessary. It's just extremely useful. Of course it rewrites history, and I abhor rewriting shared history, but it's extremely useful to be able to rewrite your own private history!

Re: What comes after Git

#94

Post by parasti »

silisili wrote: post #66

Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and…

Git has a terrible UI from a learning point of view. You can't learn Git by using its commands. You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Because Git is really just a brilliantly simple data structure manipulated by dozens of ad-hoc commands.

Re: What comes after Git

#95

Post by CannisterFlux »

silisili wrote: post #66

Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and…

I find few of my fellow coworker devs know about or use gitk, and it is an awesome tool for visualizing where all the branch madness is. A lot of things that require good command-line git knowledge are a few mouse clicks or a menu option away with gitk. Undoing a merge for example (a classic "oh no, I pulled on the wrong branch and now it's all fucked up"), I've no idea how you'd do that with the command line, but in gitk it's just right click the parent commit and choose "reset the branch here".

Re: What comes after Git

#96

Post by sshine »

bmitc wrote: post #85
alexchamberlain wrote: post #76

Earlier quoted context omitted.

I feel like you may be blaming the tool for a social problem there. We have a simple rule: no changes to package* in a feature PR. Adding a dependency? Cool, upgrade everything first, then add it fresh. (Be reasonable there- the idea is that the add should be clean, so if that can be done without doing a major upgrade, that is of course fine.)

It sounds like you're just working around the limitations of the tools. Edit: I think it's possible that I misunderstood, given the downvotes. I thought they meant that a dependency should be added in one PR, and then the feature needing that dependency in a separate PR. What I think they actually meant is that if adding a dependency requires upgrades of other dependencies, then upgrade the existing dependencies in o…

Or a limitation of the human mind.

If you jam too many unrelated changes into one diff, people stop paying attention, because now reviewing it requires many minutes and note-taking.

Since hundreds of line changes can have little or no effect, but a single line change somewhere else can have drastic effects, it is essential to separate the unimportant from the important.

Changes in dependencies is a not unimportant change, but they tend to get treated like noise because those changes are associated with automated tooling, like the package tool. Updating dependencies separately solves a social problem, not a technical one.

Re: What comes after Git

#97

Post by vlovich123 »

nine_k wrote: post #38
5e92cb50239222b wrote: post #31

Earlier quoted context omitted.

> Git is slow on large repos, even on an SSD. Maybe on Windows, but then everything is slow on Windows. On my 2015-era machine `git pull` on the Linux kernel source tree is nearly instantaneous after the remote objects are downloaded. Same with `git status`, `git diff`, etc. I mean, that's what it was developed for, because everything else was slow.

How about `git status`? The first SSD I bought back in 2008 was to put a large git repo on it; it helped. With much larger repos, like those I had to work with at Facebook, even an NVMe drive becomes a bit uncomfortable, and one has to use something like Watchman [1] to track changes without a rather noticeable delay. [1]: https://github.com/facebook/watchman

Facebook uses mercurial across the board, at least from what I saw a couple years back. A good chunk of the large file / large repo has been open sourced as EdenFS [1] which uses file notifications to update the status as you make changes to amortize the cost so that it’s already computed by the time you query (watchman is integrated). That being said, very few code bases grow to this size unless you are a major tech company and have a single mono repo (with a few major OSS projects as notable counter examples).

[1] https://github.com/facebookexperimental/eden

Re: What comes after Git

#98

Post by bmitc »

relyks wrote: post #80
silisili wrote: post #66

Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and…

You and me both. Git's interface has been very hard for me to understand (especially coming from Mercurial). I ended up finding Gitless ( https://gitless.com ), a wrapper around Git with a better interface, and loving it. The original author hasn't updated it in a long time, but I've been using a maintained fork that's been pretty sweet: https://github.com/goldstar611/gitless

I came to Git from Perforce and have also had a tough time. Perforce had well-named actions. I was able to learn it quickly and even do custom devops things with its API. For Git, I do the absolute bare minimum in terms of workflow because very little of it is well-designed or makes sense. There's also a lot of snark in its language. I think I was wanting to try to interactively add on the command line, but got out because it was impossible to use without reading a manual and didn't appreciate "what now" and other such things.

There are also very few use cases that require its complex distributive model.

Re: What comes after Git

#99

Post by shikoba »

saxonww wrote: post #36
kadoban wrote: post #25

Earlier quoted context omitted.

That's just a convenience command. Git doesn't actually record moves as anything different from a delete and an add. Many of the querying commands (eg `git log`) use heuristics to show moved files, but they end up wrong fairly often, especially if you don't mess with the parameter(s) of the heuristics.

In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused. I think it's reasonable to argue that git shouldn't get confused in this scenario, but you could also do your renames in one commit and your changes in another.

> It's when you move a file and make substantial edits that it gets confused.

It's your POV that it's the same file. One could argue that it's a new file and the content of the old one embed in the file. That's the huge problem with git users, people cling desperately to the idea of changes, when git is just about snapshots.

Re: What comes after Git

#100

Post by pdmccormick »

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though.

What's the lesson, that you can learn anything eventually, or that familiarity means you will lose the ability to accurately evaluate something?

Post reply on HN