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

131–140 of 248 posts

Re: Git rebase in depth

#131

Post by dahart »

ZeroGravitas wrote: post #113
dahart wrote: post #68

Earlier quoted context omitted.

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…

> The number of times I need to dig into the reflog for any reason is very low, and always because I made a mistake. A good UI should allow you to recover from mistakes. Like the trashcan vs rm example everyone is using. It's good that git doesn't permanently delete stuff, it's bad that you need to be a relative expert to know that. If git branch showed rebased branches and told you they would disappear in x days the…

This is a little hyperbolic though, because git does have UI above the reflog designed for catching the most common mistakes. The reflog is a powertool, it is not the default UI, and most people never need to look at the reflog.

git rebase has an "abort" feature when you need to redo it. git has tag & branch & stash features if you want to save what you're doing before you rebase. The problem with keeping and showing rebased branches are that 1- you don't need them after the rebase is successful. You only need them when the rebase is going badly, and 2- you'd have a lot of unnecessary noise pile up. I often rebase multiple times before every push. I don't want to see them all, you probably don't either.

That said, I fully agree that git's UI could be better and help beginners feel less fear!

Re: Git rebase in depth

#132

Post by Stratoscope »

brandmeyer wrote: post #110
jrockway wrote: post #80

Earlier quoted context omitted.

There is the reflog for that. https://www.atlassian.com/git/tutorials/rewriting-history/gi...

This is technically true, and a common reposte when talking about preservation of history edits. Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over. It also just so happens that its when an interactive re…

SmartGit does a brilliant job of integrating the reflog and stashes into the rest of Git. The history log window has a Branches panel, which is a tree view with subtrees for your local and remote branches. Below those is another subtree of any stashes you have saved, and then a Recyclable Commits checkbox.

When you turn on Recyclable Commits, every commit in the reflog shows up in the history tree just like any other commit. You can see exactly where they diverge from your other branches and can work with them as you normally work with any commit.

Same thing for stashes: check one and it just shows up as part of the commit tree as if it were a normal commit.

I've used SmartGit for years and highly recommend it over the Git command line for the way it gives you so much more insight into the state of your repo.

Re: Git rebase in depth

#133

Post by MichaelMoser123 »

Buttons840 wrote: post #102
Chazprime wrote: post #58

Earlier quoted context omitted.

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

Yep. Specifically, git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. I suppose there may be some arcane commands to force a deletion, but it wont happen by accident or by normal usage. Like you, I felt much more comfortable using git after learning this.

How comes that I see older commits with git log -p ? I can even see what the commit changed.

Re: Git rebase in depth

#134

Post by humblebee »

Dayshine wrote: post #72
dmitryminkovsky wrote: post #57

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. 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 really don't understand why git doesn't create a tag when you rebase in case things go wrong, or more generally when doing potentially gc-able actions. Pretending the average user will know how to get things back to how they are is silly.

feature-branch@{1} is the branch prior to the rebase.

https://www.git-scm.com/docs/gitrevisions#Documentation/gitr...

Re: Git rebase in depth

#135

Post by ZeroGravitas »

chris_mc wrote: post #87
Amorymeltzer wrote: post #24

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…

I use `--force-with-lease` instead of `--force` or `-f` because it ensures that if someone happened to push before me it would fail and I could manage that manually. Even on branches that no one "should" be touching other than me, it seems safer to type the extra characters `-` and `orce-with-lease` around the `-f`.

This was new to me, and makes me feel better about force pushing. However, while googling to find out if I could set this as the default behaviour I found an Stack Overflow answer that as well as saying "no" points out a very git-like gotcha:

https://stackoverflow.com/questions/30542491/push-force-with...

Apparently it will think you know about the changes if you've fetched them, even if you've not merged them. And some systems auto fetch in the background.

Re: Git rebase in depth

#136

Post by humblebee »

gwright wrote: post #91
rusk wrote: post #76

Earlier quoted context omitted.

I'd suggest creating the branch before the rebase: $ git co feature-branch $ git branch before-rebase-feature-branch $ git rebase develop

Worthwhile if you anticipate something going wrong, but usually things are just fine or a `git rebase --abort` will get you back to a safe place (if you are using an interactive rebase).

Or git `reset --hard ORIG_HEAD`

> HEAD names the commit on which you based the changes in the working tree. FETCH_HEAD records the branch which you fetched from a remote repository with your last git fetch invocation. ORIG_HEAD is created by commands that move your HEAD in a drastic way, to record the position of the HEAD before their operation, so that you can easily change the tip of the branch back to the state before you ran them.

https://www.git-scm.com/docs/gitrevisions#Documentation/gitr...

Re: Git rebase in depth

#137

Post by u801e »

brandmeyer wrote: post #110
jrockway wrote: post #80

Earlier quoted context omitted.

There is the reflog for that. https://www.atlassian.com/git/tutorials/rewriting-history/gi...

This is technically true, and a common reposte when talking about preservation of history edits. Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over. It also just so happens that its when an interactive re…

> Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over.

When you run git reflog after rebasing, you will see lines like the following:

  29d82ac HEAD@{6}: rebase -i (finish): returning to refs/heads/your-branch
  29d82ac HEAD@{7}: rebase -i (fixup): Commit message 2
  4f8e996 HEAD@{8}: rebase -i (pick): Commit message 2
  f3a954e HEAD@{9}: rebase -i (pick): Commit message 1
  f74b8a5 HEAD@{10}: rebase -i (start): checkout origin/master
The line listed after the one that has rebase -i (start) is the commit you were on before you started the rebase. If I screw up a rebase, then I will stash any uncommitted changes and run a git reset --hard to the commit listed below the rebase -i (start) commit I see in the reflog and start the rebase again.

Re: Git rebase in depth

#138

Post by munk-a »

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 disagree, I'd suggest just including the plain `--force-with-lease` since it's generally a tool that stops breaking stuff to happen. In particular, the assumption that your branch isn't publicly used is usually wrong if `--force-with-lease` fails.

Re: Git rebase in depth

#139

Post by tomcatfish »

MichaelMoser123 wrote: post #133
Buttons840 wrote: post #102

Earlier quoted context omitted.

Yep. Specifically, git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. I suppose there may be some arcane commands to force a deletion, but it wont happen by accident or by normal usage. Like you, I felt much more comfortable using git after learning this.

How comes that I see older commits with git log -p ? I can even see what the commit changed.

Those commits are referenced. Parent comment is talking about commits that have no references to them (ie. You make a commit then remove all traces of it, it is not gone completely until after a certain amount of time).

Re: Git rebase in depth

#140

Post by irrational »

mixmastamyk wrote: post #77
Dayshine wrote: post #72

Earlier quoted context omitted.

I really don't understand why git doesn't create a tag when you rebase in case things go wrong, or more generally when doing potentially gc-able actions. Pretending the average user will know how to get things back to how they are is silly.

Yep, it was designed by and for linux kernel development, that average users are using it is an accident of history.

So what are the chances that a version of Git, or something like Git, will be developed that is suitable for the average user? Someone above made a comment about how easy it is to do X in Git, and then preceded to write lines of Git commands that are as arcane as anything an alchemist could come up with. If that is easy Git, I'd hate to see what hard Git looks like.
Post reply on HN