Gregory's Server@b0rk I still refuse to accept that rebase is a legitimate operation. It has no equivalent in other VCSs even other DVCSs. It's frequently cited as a solution for all manner of problems but I've never seen a coherent single-sentence description of it. Every example is so mired in git minutiae that it's not worth pursuing. It's just safer and easier to extract critical changes, wipe a mangled repo, and reapply/merge changes than waste the time and effort deciphering git. Catering to the gratuitous complexity of the tool is not a good use of my time.
|
8 comments
 @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.  @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 https://www.amazon.com/Limits-Software-People-Projects-Perspectives/dp/0201433230 @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. @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.) |
@arclight @b0rk You're probably not looking for answers here, but you kind of *did* give a single sentence description of rebase 😂 it's exactly what you said about reapplying the changes you want, except without making a new clean repo, and it's using the original commits. Of course there's all kinds of bells and whistles and finger traps, but that's the gist.