Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git rebase in depth

git-rebase.io

Post reply on HN
Print view View original

51–60 of 248 posts

Re: Git rebase in depth

#51

Post by dan00 »

Sir_Cmpwn wrote: post #45
dan00 wrote: post #44

Earlier quoted context omitted.

> No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. The same changes are still in the repo (edit: I should have said branch here), but not the same commits, because the parents and children change and therefore the hash of the commits. It is very important to be aware that the history is changed, because the previous history can not be…

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…

It is right that the previous commits are still there in the repo, but from the point of git they are garbage now and going to be removed. The point are the commits reachable now from the branch.

Re: Git rebase in depth

#52

Post by gpm »

ajross wrote: post #46
gpm wrote: post #43

Earlier quoted context omitted.

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…

So... your whole complaint is that people use "rebase" as a trick for "edit history". You'd be fine if they just put a wrapper into the project for that? Seems like not much of a complaint to me. Why not just submit it yourself? Git doesn't have "reorder patches" feature. Maybe it should. But the fact that its rebase tool can be abused to do this doesn't say anything about the interface value of "git rebase". Honestl…

No, I use rebase for "branch rebasing" (i.e. actual rebasing) too. I have no clue how you got that out of my comments.

My complaint is that git's UI is terrible to teach people, to understand it you have to understand way too many internal details of git.

Yes, making a wrapper for `git rebase -i HEAD~x` (and `git rebase -i `) would satisfy this UI nit. It wouldn't satisfy all UI nits, this is just a relevant example.

As for why not submit it myself, I'm sure I'm not the first person to complain about this, drive-by UI changes to a project are the absolute best way to get a ridiculous inconsistent UI. I don't submit it myself because I'm not willing to commit the time to become a core maintainer of git, and without being a core maintainer I don't feel right trying to push UI changes in.

Re: Git rebase in depth

#53

Post by jolmg »

gpm wrote: post #31
ajross wrote: post #20

Earlier quoted context omitted.

It's not an interface problem at all. "git rebase", with no arguments, does almost exactly what a typical user wants almost all the time. Probably 80% of the remaining cases are handled by "git rebase $BRANCH". But once outside that world, the user if faced with the problem that "rebase" is just a special case of "merge" and shared all the complexities and edge cases. And that's hard for fundamental reasons. Git has…

"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).

> which does something basically completely different (from a users point of view).

The only difference is that one's interactive and the other isn't. If you use `-i` and simply exit out of the editor, the effect is completely the same as not having used `-i`, isn't it? I think moving `rebase -i` to a completely new command could potentially make things more confusing. That new command would be an extension of `rebase` and so could be used interchangeably.

Re: Git rebase in depth

#54

Post by Sir_Cmpwn »

dan00 wrote: post #51
Sir_Cmpwn wrote: post #45

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…

It is right that the previous commits are still there in the repo, but from the point of git they are garbage now and going to be removed. The point are the commits reachable now from the branch.

git-gc will save stuff in your reflogs. It works pretty hard to avoid removing objects which are referenced by anything at all.

Re: Git rebase in depth

#55

Post by house9-2 »

ergothus wrote: post #41
gpm wrote: post #31

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…

> My current workplace has rebase as part of their flow

Not really sure what that means as rebase can be used in multiple ways, but you might want to try using:

`--force-with-lease` instead of `--force`

> This option allows one to force push without the risk of unintentionally overwriting someone else’s work

https://thoughtbot.com/blog/git-push-force-with-lease

Re: Git rebase in depth

#56

Post by guitarbill »

Sir_Cmpwn wrote: post #28
dbaupp wrote: post #19

The 'push -f' suggestion could instead recommend 'push --force-with-lease' to be less error prone in case one is accidentally pushing to a concurrently modified branch. Also, unless the diagram is confusing with the alignment, the "rebase to rebase" example seems to be implicitly assuming --onto, because the last common ancestor of 'master' and 'feature-2' includes 2 commits on that branch: the first of 'feature-1' a…

I've heard this before, but I felt that `--force-with-lease` requires a lengthier explanation in an an already intimidating article, is harder to type, and generally isn't useful for users of the Sourcehut workflow. It's definitely a useful tool, though. Maybe I should add a footnote.

I do sympathise, it's hard to keep it at a high level, but many people just copy what they see.

One thing I do in our team is provide git novices with some useful aliases, one of them being `fpush = push --force-with-lease`. It's saved a few people losing work along the years

Re: Git rebase in depth

#57

Post by dmitryminkovsky »

gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

> No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo.

They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected.

Still, glad to see people are trying to elucidate git rebase. A small subset of its functionality is fundamental part of my workflow and I wouldn't know how I'd use Git without rebasing.

Re: Git rebase in depth

#58

Post by Chazprime »

gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

This really should be the top comment here. Learning about the non-destructive nature of Git really helped me overcome the unease around using some of Git's more advanced features (especially in a team environment).

Re: Git rebase in depth

#59

Post by Sir_Cmpwn »

dmitryminkovsky wrote: post #57
gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

> No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected. Still, glad to see people are trying to elucidate git rebase. A small subset of its functionality is fundamental part of my workflow and I wouldn't know how…

git-gc will also preserve objects which are referred to in reflogs - it doesn't just have to be tree-ish. From the man page:

>git gc tries very hard not to delete objects that are referenced anywhere in your repository. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound). If you are expecting some objects to be deleted and they aren’t, check all of those locations and decide whether it makes sense in your case to remove those references.

Re: Git rebase in depth

#60

Post by gpm »

jolmg wrote: post #53
gpm wrote: post #31

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).

> which does something basically completely different (from a users point of view). The only difference is that one's interactive and the other isn't. If you use `-i` and simply exit out of the editor, the effect is completely the same as not having used `-i`, isn't it? I think moving `rebase -i` to a completely new command could potentially make things more confusing. That new command would be an extension of `rebas…

The other difference is that I'm "rebasing" onto an ancestor of the current head, as in I'm not really changing base at all.

A hypothetical new command would be a simpler version of "rebase" that comes with the restriction described above, that it's not actually changing base.

Post reply on HN