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

201–210 of 248 posts

Re: Git rebase in depth

#201

Post by u801e »

sktrdie wrote: post #6

Weird they don't talk of the `git commit --fixup=` command. And then `--autosquash` when rebasing.

You can achieve the same thing by just titling the commit:

  fixup! Exact title of commit
We actually use that workflow during PR reviews on Github. That is, someone comments on a PR and the person who opened the PR will make a fixup commit with the appropriate title and reply to the comment stating that it was addressed and link the fixup commit by its abbreviated sha1 value.

At the end of the PR review, the person who will merge the PR will run:

  git fetch origin
  git rebase -i --autosquash origin/master
  git diff @{u}..
This basically updates the remote tracking branches (including origin/master), rebases the feature branch on top of the remote tracking branch for master, and then checks if any changes were introduced in the rebase process by running a diff against the remote tracking branch.

If there is no diff or the diff only shows changes made on the upstream master branch since the feature branch was created, then they can run:

  git push -f origin feature-branch-name
and then merge the PR.

Re: Git rebase in depth

#202

Post by int0x80 »

Nullabillity wrote: post #196
avar wrote: post #194

Earlier quoted context omitted.

Are you lying to your co-workers when you draft an E-Mail to them, read it over, and decide to delete a paragraph or write it again from scratch? If your E-Mail client automatically saves drafts that's basically the equivalent of "rebase". I made a typo when writing this reply, and pressed backspace to correct it. Is use of the backspace key lying? I think you're placing a value on "history" that doesn't map onto all…

No, if you only merge changes then you're just summarizing. The true problems begin once you start creating commits that represent repository trees that you never tested or reviewed, for example by editing past commits (invalidating any testing you've done of commits after that point), deleting past commits (aside from squashing an unbroken sequence of commits, or deleting them if the squash would result in a no-op),…

That kind of rebase is just to refresh your work against updated masters etc. Of course you have to test against the refreshed (rebased) work again!! That doesn't mean you can't rebase. It means you can't randomly push untested work. If you know what rebase means you will understand that there are very likely new interactions with your code and you have to test your updated changeset. Exactly the same as if you merge. You have to retest the resulting tree.

Re: Git rebase in depth

#203

Post by chrisweekly »

u801e wrote: post #137
brandmeyer wrote: post #110

Earlier quoted context omitted.

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-bran…

Yes, git stash is awesome! I use it all the time to "snapshot" my WIP and/or to quickly get a clean working tree when taking an interrupt to work on something in a different branch. (`gs` alias for `git stash save -u`, along with `grs` for `git reflog show stash` -- which shows the commitish for each stash...)

I see the stash as kind of like a private remote, in that I can freely put whatever messy or experimental or half-baked WIP I like, gaining the benefits of a commit without inflicting it on anyone else.

Re: Git rebase in depth

#204

Post by scrollaway »

Nullabillity wrote: post #178
eshch wrote: post #174

Earlier quoted context omitted.

do you want to know all my wrong tries to make a thing work? why are you sure that all the commits i did are not nonsense? i look at the history as a way to 1) divide my work into reusable pieces of changes 2) document my changes to read for other developers.

> do you want to know all my wrong tries to make a thing work? Yes. A failed attempt is still a useful signal that people shouldn't try to simplify back to that way in the future (and why not). It's also a useful starting point in case the reasons it failed no longer apply.

It's very rare that "failed attempts" are a useful signal. When it is the case, it's better to document it (eg. as part of the commit message, PR, or the dev documentation itself).

Commit histories littered with commits that get back-and-forth reverted are frickin unreadable though. Extremely annoying to bisect, painful to comb through when looking for changes, noisy in git blame, etc. There's a ton of downsides for what in practice is very rarely even an upside.

Re: Git rebase in depth

#205

Post by meribold »

int0x80 wrote: post #202
Nullabillity wrote: post #196

Earlier quoted context omitted.

No, if you only merge changes then you're just summarizing. The true problems begin once you start creating commits that represent repository trees that you never tested or reviewed, for example by editing past commits (invalidating any testing you've done of commits after that point), deleting past commits (aside from squashing an unbroken sequence of commits, or deleting them if the squash would result in a no-op),…

That kind of rebase is just to refresh your work against updated masters etc. Of course you have to test against the refreshed (rebased) work again!! That doesn't mean you can't rebase. It means you can't randomly push untested work. If you know what rebase means you will understand that there are very likely new interactions with your code and you have to test your updated changeset. Exactly the same as if you merge…

A merge of a branch with N unique commits creates one new, yet-to-be-tested commit/tree. A rebase creates N. I doubt that it's common that people replay all the new history after a rebase and test each new commit/tree.

Re: Git rebase in depth

#206

Post by bonzini »

Nullabillity wrote: post #173
gwright wrote: post #169

Earlier quoted context omitted.

Let me try again. I'm advocating that you use rebase to improve the quality of your changes that will be reviewed before merging or even before being reviewed at all. If I make three commits and then realize that I should have included something in the first commit, I use rebase to create a new sequence of three commits that has the corrected version of the first commit. I haven't shared those commits with anyone, th…

Yes, it is lying. You can mitigate most of the damage if it is convincing enough (for example, go through B' and C' and make sure everything still makes sense at each point), but realistically nobody is going to do that, because it's pretty inefficient way to spend your time. And even then, you're still removing context (unless you're just fixing a typo). > I'm advocating that you use rebase to improve the quality of…

> realistically nobody is going to do that, because it's pretty inefficient way to spend your time.

Of course you do! And it's not am inefficient use of your time, because it helps reviewers now, and yourself when you're bisecting later.

> And even then, you're still removing context (unless you're just fixing a typo).

You place that context in the commit message.

Re: Git rebase in depth

#207

Post by fulafel »

bonzini wrote: post #206
Nullabillity wrote: post #173

Earlier quoted context omitted.

Yes, it is lying. You can mitigate most of the damage if it is convincing enough (for example, go through B' and C' and make sure everything still makes sense at each point), but realistically nobody is going to do that, because it's pretty inefficient way to spend your time. And even then, you're still removing context (unless you're just fixing a typo). > I'm advocating that you use rebase to improve the quality of…

> realistically nobody is going to do that, because it's pretty inefficient way to spend your time. Of course you do! And it's not am inefficient use of your time, because it helps reviewers now, and yourself when you're bisecting later. > And even then, you're still removing context (unless you're just fixing a typo). You place that context in the commit message.

IME this is a very rare level of sophistication in use of rebase.

And how do you detect that you forgot / was too busy to do it, when you go back 6 months later? It's fragile, "fail-open".

Re: Git rebase in depth

#208

Post by mkesper »

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.

Create a backup branch before:

    git branch local/foo
If you mess up too hard, check it out again.

Re: Git rebase in depth

#209

Post by bonzini »

fulafel wrote: post #207
bonzini wrote: post #206

Earlier quoted context omitted.

> realistically nobody is going to do that, because it's pretty inefficient way to spend your time. Of course you do! And it's not am inefficient use of your time, because it helps reviewers now, and yourself when you're bisecting later. > And even then, you're still removing context (unless you're just fixing a typo). You place that context in the commit message.

IME this is a very rare level of sophistication in use of rebase. And how do you detect that you forgot / was too busy to do it, when you go back 6 months later? It's fragile, "fail-open".

You would be surprised. For example, this is a guide my colleague wrote to describe his git workflow:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo...

Re: Git rebase in depth

#210

Post by mikekchar »

shandor wrote: post #152
kohtatsu wrote: post #149

Earlier quoted context omitted.

Which merge strategy do you recommend? # Merge commit git merge --no-ff -m # Squash and merge git merge --no-commit --squash git commit -m # Rebase and merge git rebase --force-rebase From https://stackoverflow.com/a/52301456

I...have to admit that my merge strategy, and what I teach my teams, is "don't" :) (only slightly tongue-in-cheek) I believe in clean, linear history, and strongly prefer rebase-based workflows to merges. That's actually one of the reasons I chose Phabricator for my current place, as it is also very opinionated towards the same way of working. Edit: oh, and to answer your actual question, the third one.

The trick is you have to pick one of "merge always and avoid rebase" or "rebase always and avoid merging". If you take a branch, merge master into it, do some more development and then rebase it onto master, you are asking for trouble. If you have a revert in there (and especially a revert on a merge commit), it's a world of hurt.

But either way works fine. It just gives you a different history. My team likes merging because they don't understand exactly what happens when rebasing. In that environment `git log --topo-order` is practically a necessity, though.

Post reply on HN