81–90 of 248 posts
Regarding the rewriting of history: can't the git history itself be stored in git somehow, so its change over time (and e.g. by tools such as git-rebase) is properly tracked? Of course you'd need a meta tool to change the history of the history, but perhaps it's not needed?
Earlier quoted context omitted.
No, gwright is correct, and my guide fails to capture the nuance of this detail. Each commit has a link to its parent, and represents the tip of a linked list. .git/objects is a heap of all commits (and other objects), and .git/refs contains a list commit IDs that define each head (e.g. master). git rebase will often introduce new versions of a commit to the heap and update the heads to reference new histories, but t…
the old commits stick around They kinda are, but that's like saying that deleted files are not deleted, but stick around for a while. While technically true, for most practical purposes _rm _ deletes the file. The fact that each and every "git 101" manual has to explain how to recover deleted commits, means something is wrong. It's like saying: "Here's the key, and in case it doesn't work there's a pry bar in the gar…
Git has a very good safety net when you know how to use it. The problem is knowing how to use it, not that it’s not there.
It’s a legitimate point that git’s UI sucks, that’s what’s wrong, and everyone agrees. But learn how to use the reflog and you will see the light!
> One of Git's core value-adds is the ability to edit history I didn't make it past this line. git is extremely good at keeping history immutable; it's also good at creating new, alternative histories and moving between them.
Earlier quoted context omitted.
No, gwright is correct, and my guide fails to capture the nuance of this detail. Each commit has a link to its parent, and represents the tip of a linked list. .git/objects is a heap of all commits (and other objects), and .git/refs contains a list commit IDs that define each head (e.g. master). git rebase will often introduce new versions of a commit to the heap and update the heads to reference new histories, but t…
the old commits stick around They kinda are, but that's like saying that deleted files are not deleted, but stick around for a while. While technically true, for most practical purposes _rm _ deletes the file. The fact that each and every "git 101" manual has to explain how to recover deleted commits, means something is wrong. It's like saying: "Here's the key, and in case it doesn't work there's a pry bar in the gar…
Someone who has never done it before won’t know how to retrieve them, but that’s hardly a surprise.
Earlier quoted context omitted.
"git rebase" does exactly what you want, except when it's totally unrelated to what you want because what you actually want is "git rebase -i HEAD~3" which does something basically completely different (from a users point of view).
This is probably where I foul up. My last few workplaces were either not git, or relied on git pull w/o rebase. My current workplace has rebase as part of their flow, and I find that, like, 60% of my PRs require force push, which bothers me greatly. Everyone else just shrugs and considers it part of business, but I know what I WANT to do should be nicely aligned and not encounter that problem. Unfortunately, every ex…
Earlier quoted context omitted.
the old commits stick around They kinda are, but that's like saying that deleted files are not deleted, but stick around for a while. While technically true, for most practical purposes _rm _ deletes the file. The fact that each and every "git 101" manual has to explain how to recover deleted commits, means something is wrong. It's like saying: "Here's the key, and in case it doesn't work there's a pry bar in the gar…
Comparing lost commits to rm isn’t a good analogy. Git has a very good safety net when you know how to use it. The problem is knowing how to use it, not that it’s not there. It’s a legitimate point that git’s UI sucks, that’s what’s wrong, and everyone agrees. But learn how to use the reflog and you will see the light!
The warning regarding "public, shared, or stable branches" is always warranted, but I think those warnings end up reverberating where they needn't. Before interacting with anything public or shared — when working solo or locally — `rebase` can be hugely helpful. When starting out with something complicated, I often make separate commits for different files or steps; using rebase to reorder commits or amend can make t…
Earlier quoted context omitted.
No, gwright is correct, and my guide fails to capture the nuance of this detail. Each commit has a link to its parent, and represents the tip of a linked list. .git/objects is a heap of all commits (and other objects), and .git/refs contains a list commit IDs that define each head (e.g. master). git rebase will often introduce new versions of a commit to the heap and update the heads to reference new histories, but t…
the old commits stick around They kinda are, but that's like saying that deleted files are not deleted, but stick around for a while. While technically true, for most practical purposes _rm _ deletes the file. The fact that each and every "git 101" manual has to explain how to recover deleted commits, means something is wrong. It's like saying: "Here's the key, and in case it doesn't work there's a pry bar in the gar…
Earlier quoted context omitted.
I've heard this before, and it seems reasonable on the surface. The argument I make against this viewpoint is: "git rebase gives us powerful tools that allow us to curate a good commit history in the same way we use refactoring to uphold good software design practices."
Most shops don't follow good software design practices, so how likely is it to get a practice one-step-removed from that, with a difficult UI to boot, adopted?
Earlier quoted context omitted.
OK... And what is your suggestion for a proper and obvious interface choice for that? FWIW: the line noise you typed means "Make a list of the changes since three commits ago, let the user edit the list, then apply them". Other than -i step and the length of the list, this is basically a noop -- you're rebasing on an ancestor of HEAD! I mean, yeah, git lets you do that, but I don't know why you expect the syntax for…
How about, `git edit-history 3`? Just stop calling it rebase. The "line noise" I typed is an extremely common command that is used to clean up commit history, e.g. squash all your "WIP" commits into a few nice ones. Yes the idea of rebasing onto the same branch is just weird, that's kinda my point, since it's the only way to edit history that git supports (as far as I, or anyone I've ever seen answer a question about…
Also, emacs magit makes this even easier, if you don't mind a more GUI-like interface.