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

61–70 of 248 posts

Re: Git rebase in depth

#61

Post by dahart »

dan00 wrote: post #44
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. 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…

> previous history can not be without issues merged with the new one

I don’t understand what you mean. Why would you rebase a branch and then merge the rebased version with the old version of that branch? I don’t think that’s a common workflow, that is a specific case you should avoid.

Typical use of rebase to clean up the unpushed portion of a personal repo before pushing doesn’t normally cause any problems. The main thing that pops up for me is trying to re-order my own dependent commits when I forget that one commit touched the same code as another. Squashing them during the rebase is the easy fix.

Re: Git rebase in depth

#62

Post by dan00 »

Sir_Cmpwn wrote: post #54
dan00 wrote: post #51

Earlier quoted context omitted.

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.

Ah ok, the point about reflog makes sense. Thanks!

Re: Git rebase in depth

#63

Post by luhn »

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…

I'm familiar with the reflog and use `head@{n}` on occasion, but it never occurred to me that you could use that same syntax with branches. It seems obvious in retrospect—I feel silly.

Re: Git rebase in depth

#64

Post by AlexTWithBeard »

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…

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 garage". This is usually a pretty good indicator that the lock is broken.

Re: Git rebase in depth

#65

Post by guitarbill »

Espressosaurus wrote: post #25
Sahhaese wrote: post #18

Earlier quoted context omitted.

But those high level tasks could also be exposed directly. There's nothing to stop there being more commands which more directly accomplish the desired tasks. The idea that git is good because it is difficult to use is just "git snobbery", as is the idea that it must be difficult because it's a DVCS. There's nothing to stop git having two levels of the API, one exposed for tools to build off of with the full complexi…

Mercurial's interface is just fine, and these days it's just as powerful as Git. Things could be better. There's an existence proof. It just lost the mindshare war and so now we're stuck with Git, which I still have to look up basic syntax for because its command set is contradictory and makes no sense. (Is it git ? git --x? git ? Something else entirely? Who knows!)

I used to agree with this, now I've stopped worrying. Because if git is the worst part of your workflow, that's a great problem to have. But at many places, git is the best part.

(I've also had to work with various IBM CVS, and they are universally garbage. When I get frustrated at git, all I have to do is think back to those.)

So yes, Mercurial is better, but is it worth the effort? Not in my experience.

Re: Git rebase in depth

#66

Post by Sir_Cmpwn »

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…

I just added a mention right after the big scary warning about how everything you do in git is non-destructive. Thanks for the suggestion!

Re: Git rebase in depth

#67

Post by mixmastamyk »

nothrabannosir wrote: post #33
jaequery wrote: post #23

FWIW i've never really needed rebase. i am pretty happy with seeing all the commits that ever happened.

Fixing history enables powerful second level tools , such as bisect and cherry pick. Being able to pinpoint a problem to an exact commit is incredibly powerful for debugging, but it does require your commits to be as healthy as possible. If you fix a bug 10 commits after it was introduced , now the 10 commits between them are harder to work with; you always have to keep in mind that unrelated bug. And cherry picking…

Bisect still works anyway. For non-huge projects, all this obsession with tool minutiae is a waste of time.

As mentioned by another poster, the fact that a whole website is needed to explain the concept illustrates the design and UI failure.

This is an uphill battle that can't be won until a next-generation interface becomes usable by mortals. If that can't be done due to complexity, it's a lost cause for average developers paid for delivering business value.

Re: Git rebase in depth

#68

Post by dahart »

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.

What’s the matter with reachable and unreachable commits? Commits no longer needed should be unreachable and cleaned eventually, that’s a feature. Git is fantastic about keeping the unreachable commits for long enough that should I actually need them for any reason, they’re usually there. The default is 90 days. The number of times I need to dig into the reflog for any reason is very low, and always because I made a mistake. The number of times I’ve lost a commit irrevocably because it was cleaned before I needed it is 0.

Re: Git rebase in depth

#69

Post by limxto0 »

All the git-rebase-fu I have ever needed while working with pull requests, I have found in this well written guide: https://github.com/susam/gitpr

Quoting from this document below.

  # Rebase topic branch on the main development branch (optional).
  git checkout TOPIC-BRANCH
  git rebase master

  # Edit commits, e.g., last 3 commits in topic branch (optional).
  git checkout TOPIC-BRANCH
  git rebase -i HEAD~3

  # Force push rebased/edited commits to the pull request (optional).
  git push -f origin TOPIC-BRANCH

Re: Git rebase in depth

#70

Post by AlexTWithBeard »

dahart wrote: post #49
Sahhaese wrote: post #18

Earlier quoted context omitted.

But those high level tasks could also be exposed directly. There's nothing to stop there being more commands which more directly accomplish the desired tasks. The idea that git is good because it is difficult to use is just "git snobbery", as is the idea that it must be difficult because it's a DVCS. There's nothing to stop git having two levels of the API, one exposed for tools to build off of with the full complexi…

Git does have two levels of the API explicitly, one for tools (“plumbing”) and one for every day use (“porcelain”). I don’t think the argument is that the difficulty is a virtue, nobody is trying to be snobby, so try to avoid jumping to that conclusion. Git just has some inherent complexity. Git does have a steep learning curve that is the root of a UX problem. But it’s not clear what better abstractions there are or…

The main problem with git is that it tries to be two things at once: a change management system and a version control system.

For the former you want flexible history, distributed repos and freedom to do whatever you want.

For the latter the history should be sacrosanct and the repository is better be more or less centralized.

git tries to sit on both chairs and therefore has to adapt a quite awkward position.

Post reply on HN