Email or username:

Password:

Forgot your password?
Julia's posts Post Back to profile
Top-level
Graydon

@arclight @b0rk Rebase recreates all the commits in a branch as though the branch had been created from the commit to which it is being rebased. (While leaving the originals in existence!)

Last night, I rebased to pick up a couple sprints worth of changes from other people because my particular task took way too long for Reasons. No manual conflict resolution seems like a win. Whole thing took seconds, and doesn't assume I know where the critical stuff is in other people's work.

2 Nov 2023 at 14:03 | Wall-to-wall | Open on canada.masto.host
6 comments
Graydon

@arclight @b0rk In general, it's important to remember that git was designed to handle projects that are much too big to understand. A lot of what it does makes no sense if you don't recognize that the point is to handle stuff a[n individual] person cannot understand due to volume.

2 Nov 2023 at 14:04 | Open on canada.masto.host
arclight

@graydon @b0rk And that's a big challenge for my projects; I don't have the same problems as the Linux kernel developers have so the tool really isn't suitable for my use. It's incredibly difficult to identify and isolate the relevant parts of git. You're faced with full complexity at the outset whether you need it or not. Fine for kernel devs, a nightmare for everyone else. Project scale should also be a warning sign amazon.com/Limits-Software-Peo

2 Nov 2023 at 14:31 | Open on oldbytes.space
Graydon

@arclight @b0rk Don't agree with the "nightmare for everyone else", not anymore than the shell is a nightmare. Some instruction is required. It's one of those cases where the more you know going in the more instruction is required, even; git is rough on autodidacts who want to be able to infer function. I had a lot less trouble when I started using the git-scm documentation and any workplace ought to have a "this is how we use git" explainer in wide currency.

2 Nov 2023 at 14:45 | Open on canada.masto.host
arclight

@graydon I'll agree with the latter point - a "how we use git here" guide is essential. I just remember trying to understand git in the late 2000s and how git terminology seemed to intentionally and unnecessarily differ from every other VCS. Docs were sparse and impenetrable and I wound up learning Mercurial instead because it was learnable. I hate that git is conflated with DVCS in general because it is such a niche tool that doesn't translate well outside its niche. We've had commit, branch, and merge forever - why a whole new vocabulary was needed is beyond me. But that's not surprising since I'm not a kernel developer.

@graydon I'll agree with the latter point - a "how we use git here" guide is essential. I just remember trying to understand git in the late 2000s and how git terminology seemed to intentionally and unnecessarily differ from every other VCS. Docs were sparse and impenetrable and I wound up learning Mercurial instead because it was learnable. I hate that git is conflated with DVCS in general because it is such a niche tool that doesn't translate well outside its niche. We've had commit, branch, and...

2 Nov 2023 at 15:48 | Open on oldbytes.space
Graydon

@arclight Something that is free and sufficient tends to win, and git's selling point is that your source control problem is not as challenging as the problems it was created to solve.

The terminology mostly comes in because it isn't doing commit, branch, and merge, it's using a distinct abstraction, and the words for the abstraction weren't there so people just grabbed whatever didn't run away quickly enough. I agree that the result is horrid confusing. (git-scm docs make a heroic effort.)

2 Nov 2023 at 16:16 | Open on canada.masto.host
Graydon

@arclight Which is why the "here are our standard patterns" seems so important; it gives people some place to stand on.

I've had good results from that in the past but it is definitely setup work for the people part of the dev environment.

2 Nov 2023 at 16:28 | Open on canada.masto.host
Go Up