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

251–260 of 430 posts

Re: What comes after Git

#251

Post by dan-robertson »

pdmccormick wrote: post #100

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…

Even if you get over the bad commands, the internal model of snapshots (and eg the need for rerere) can still be unintuitive and not always line up with the behaviour one would expect

Re: What comes after Git

#252

Post by javajosh »

8n4vidtmkvmk wrote: post #111
indy wrote: post #69

Earlier quoted context omitted.

I wonder how many centuries of developer time have been wasted trying to "unfuck what I did and go back to a branch"?

hg up --clean i dont know why mercurial doesn't get more love.

hg is indeed the better tool. Just as microkernels are the better kernel design. By existing and working (which is no small feat), Linux obliterates both alternatives in the zeitgeist. This is, of course, the great downside to "worse is better".

Re: What comes after Git

#254

Post by krageon »

troppl wrote: post #141
krageon wrote: post #105

Earlier quoted context omitted.

> Am I the only one who thinks that Git's UX is fine [...] No, I think most people that use it are fine with it. But those are usually not the ones you hear :)

Are you really sure that is the case here? I think everyone that starts working with git is a bit hung up by its complexity at least for a year, if not more. It seems to me that, as it should be, every professional SW dev has managed to work with git at some point in their life, then. Because git is simply what you will most likely use nowadays. But still, everyone remembers how hard it was to start out. Which is why…

> But still, everyone remembers how hard it was to start out

I sure don't. I learned the commands I needed (branch, checkout, clone, push, pull and commit) and didn't step out of those bounds until much later. It's really no different than learning any other skill or platform. Nobody starts out a master, but that's no excuse to never start.

Re: What comes after Git

#255

Post by marginalia_nu »

pdmccormick wrote: post #100

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…

My main complaint is it's leaking abstractions. You basically need a PhD in git's internal data structures to use git. Well not the 5% of git you typically need in your day-to-day, but the other 95%, which you need when the 5% you do need somehow goes wrong, through one of the many foot-guns git offers.

A concrete example: Accidentally pushing a merge you didn't want to push and now you're stuck staring git-revert(1) which has the sentence below, scratching your head like "uh, what's a parent number?"

       -m parent-number, --mainline parent-number
           Usually you cannot revert a merge because you do
           not know which side of the merge should be
           considered the mainline. This option specifies
           the parent number (starting from 1) of the
           mainline and allows revert to reverse the change
           relative to the specified parent.
Maybe you google a bit, and find this: https://www.christianengvall.se/undo-pushed-merge-git/ ... which explains a bit, but is still confusing as all hell. The rabbit hole continues to this: https://opensource.apple.com/source/Git/Git-26/src/git-htmld... which is also... not really clear.

But you still can't find information about what a "parent number" is. It turns out, the parent number is the order they show up in within 'git show HASH'. Combining that clue with Linus Torvalds email above may let you undo the merge, if you can make sense of his Feynman diagrams. Maybe.

Re: What comes after Git

#256

Post by metta2uall »

open-source-ux wrote: post #225
sgbeal wrote: post #202

Earlier quoted context omitted.

(A long-time fossil dev here...) Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is abso…

" Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium. " I wonder why so few developers consider the scenario you describe. Git fits the development of Linux. But, a question rarely raised: why is Git considered suitable for small or medium projects?

Network effects, and that once many people get the hang of using git "well enough" they'd rather put up with it's annoyances than take the time to learn something that's marginally better..

Re: What comes after Git

#257

Post by cxr »

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…

> It sounds like you're just working around the limitations of the tools.

It can be hard to recognize, esp. since it has so much cultural inertia and approval, but doing things like splitting things into packages, recording the links in package.json (whether by hand or by tool-assist), and then introducing something like `npm install` into the workflow as a way to lazily fetch parts of a application's codebase is nothing but one massive (and massively fragile) scheme to circumvent the version control system as an consequence of unacknowledged limitations of the relevant tool.

Re: What comes after Git

#258

Post by avar »

flir wrote: post #241
pdmccormick wrote: post #100

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…

The model's basically a directed acyclic graph (not a tree), with each edge being the diff between the two nodes it connects. I think the UX could be improved if it built on the language of graphs to make that model more apparent - node, edge, etc. (I also believe the same thing about SQL and sets).

It stores a full copy of every node, not the diff. The diff is just something that's rendered on-demand, and "gc"/"repack" compaction and it being content-addressable makes sure that the storage space doesn't balloon as a result of everything being a full snapshot.

This distinction makes a difference in some cases, there are other VCSs that store diffs as a fundamental property.

About your naming suggestion: I'm not saying you're wrong, but consider that git is used by a very wide audience, and even a lot of the programmer crowd isn't familiar with the graph theory terms you're using.

So "branch", "tip" etc. is by no means perfect, but I think it's probably better.

Re: What comes after Git

#259

Post by samgranieri »

I've used Git since 2007, and mastered some of the esoteric parts of it a few years ago. I think it's gonna be here to stay for the long haul.

Granted, the learning curve can be a little steep, but once you learn it you're good to go. There's a rich ecosystem of documentation, helper tools and shell aliases you can find that can help you master the tool to get your job done.

Some of my favorite paid tools for working with git are Tower and Kaleidoscope (I'm a huge fan of native mac apps).

Re: What comes after Git

#260

Post by avar »

kruador wrote: post #217
Akronymus wrote: post #47

Earlier quoted context omitted.

Would it make sense to make one commit for the move and one for the changes?

No, it makes no difference. Git doesn't look at the full history when performing a merge, it just looks for similarity between the paths and files in the commits being merged, and the common base commit (which you can discover by running `git merge-base`). It doesn't keep any metadata about whether something was a move: as far as the actual data structures are concerned, you deleted file a/b/c and added file d/e/f, t…

The "git log" "follow renames" logic isn't the same as conceptually related merge logic.

I think there are unfortunately still cases where what the GP is suggesting improves the UX, i.e. I think some shortcuts are taken when following a file if the content doesn't change.

IIRC this matters particularly for very large renames, at some point during revision walking we'll give up trying to match your A.txt to B.txt, but if they're the same...

Post reply on HN