151–155 of 155 posts
I’ve used Git for 20 years now and wrote a book about it. The biggest mistake most sources make when teaching about history rewriting is omitting these two lessons first: - it’s easy to lose uncommitted data in Git and hard to lose committed data - given this, learn how to use ‘git reflog’ to see what you’ve done and how to undo/redo it (as this post recommends but, even then, a little too late) If you just get in th…
Earlier quoted context omitted.
Have you ever read any of the introductory material that the git project itself maintains for teaching how to use the tool? - https://git-scm.com/docs/gittutorial - https://git-scm.com/docs/giteveryday - https://git-scm.com/docs/gitworkflows - https://git-scm.com/docs/gitfaq - https://git-scm.com/cheat-sheet Or if you want to sit down and really learn the nuts and bolts - https://git-scm.com/book/en/v2
Looks like an incredibly dull way to waste hours of my finite life for microscopic benefit.
It really won't take hours. You probably read more than that just looking at HN for like 20 minutes.
I use interactive rebases frequently, but even then, I think conflicts happening during a rebase are often somewhat cryptic. I think I know what happens in principle (each step of a rebase does a merge of the commit from the list with the last rebased commit) but it's still often hard to understand which side of the conflict represents what, and what would be the desired outcome for that step in the history . So I te…
I use it often as well, but if I'm rebasing more than a handful of commits it becomes very annoying and confusing if there's a conflict. For example, I often run into the situation where I'll get a conflict, I resolve that conflict on the first rebase step, but then the same conflict keeps popping up. Where did the resolution I just did disappear to? Why do I have to keep redoing the resolution?
Wsc891 https://news.ycombinator.com/user?id=wsc981 has a good resolution for this in the comment directly above: 1) rebase -i onto your own history and squash 2) rebase onto the new branch.
Why isn't the 'edit' command mentioned? It's one of the most useful features. It can be used for splitting commits, for example. Mark the commit you want to split to be edited. The commit replay is going to stop after that commit. Now: git reset HEAD^1 (NO --hard!) git commit --patch ... git rebase --continue You want to add some pending changes to the previous commit? No problem: git commit --patch --amend ... You w…
(jj of course has its own warts as well)