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

221–230 of 248 posts

Re: Git rebase in depth

#221

Post by Vinnl »

Nullabillity wrote: post #167
gwright wrote: post #166

Earlier quoted context omitted.

It isn't lying. Advocates of rebase are always talking about a work flow where you are curating a set of proposed changes before merging into your "public" branches (.e.g, development or master). No one is advocating that you use rebase on your public branches or basically any branch that has been "published". We are talking about feature branches or spikes or branches that exist just on one developer's machine.

You're lying about the path that you took to get to that point, and you're creating a lot of (public) nonsense commits on the way there (unless you're very careful, and/or overly squash-happy). Whether you've published the true history earlier is irrelevant to that discussion.

But you lie all the time, by that definition! If I write code, make a mistake and press Ctrl+Z before committing that code, I've just "rewritten" my history without my team mates being able to tell.

Your commit history is just a somewhat arbitrary recording of your code at certain points in time that you choose. Rebasing simply makes that less arbitrary, allowing you to document the way your code is built up in a structured way. Rather than having to decide on the spot whenever a certain combination of code is a good candidate for a single, atomic commit, you can make that judgment with the benefit of hindsight.

Re: Git rebase in depth

#222

Post by Vinnl »

u801e wrote: post #165
greyskull wrote: post #156

Earlier quoted context omitted.

+1. Interactive rebase to squash your feature branch, then ff merge into master/mainline. Years ago when I was just reading about git instead of using it, I saw sentiments along the lines of "always use feature branches and merge them so your thoughts and process can still be looked at later". In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own…

> In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own code or someone else's. I've found that ambiguities and clarifications can and are caught during the code review process. One command I often use is git blame which allows me to find the commit that's associated with a particular line of code. Then I can look at the commit message and the dif…

Yes, that's exactly my main motivation for rebasing too: properly thought-out commits can give more context to the lines of code I'm looking at. (I wrote these thoughts up in more detail here: https://vincenttunru.com/Spend-effort-on-your-Git-commits )

Re: Git rebase in depth

#223

Post by fulafel »

gwright wrote: post #175
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…

I really don't understand why you are choosing to use the word "lying". Us mere humans make mistakes all the time. Typos, omissions, false starts, and so on. What is the value of throwing that raw set of events at a reviewer or complicating the understanding of the changes when viewed in retrospect from the future? What is the reason you call curating the work into a more polished form "lying"? Why do you think the t…

But reviewers in most Git workflows mainly look at PRs. Then if as a reviewer you want to see how the sausage was made, you can zoom in on the commits, including all the messy reality of how the work was done. In some circumstances you might of course want to hide this, but in an open and safe collegial environment this lets the reviewer understand your thought and work process.

Re: Git rebase in depth

#224

Post by raimue »

fulafel wrote: post #223
gwright wrote: post #175

Earlier quoted context omitted.

I really don't understand why you are choosing to use the word "lying". Us mere humans make mistakes all the time. Typos, omissions, false starts, and so on. What is the value of throwing that raw set of events at a reviewer or complicating the understanding of the changes when viewed in retrospect from the future? What is the reason you call curating the work into a more polished form "lying"? Why do you think the t…

But reviewers in most Git workflows mainly look at PRs. Then if as a reviewer you want to see how the sausage was made, you can zoom in on the commits, including all the messy reality of how the work was done. In some circumstances you might of course want to hide this, but in an open and safe collegial environment this lets the reviewer understand your thought and work process.

The reviewer also won't see all the things the author tried without ever committing these states. They don't need to see all the messy steps, or they would have needed to look over the authors shoulder all the time.

I rather review the final patch series with changes in logical order and not necessarily in the order the code was written or with intermediate work that was later reverted or changed again. I do look at commits, because also every commit message counts and is supposed to explain the individual change.

Re: Git rebase in depth

#225

Post by gbacon »

kohtatsu wrote: post #149
shandor wrote: post #146

Earlier quoted context omitted.

This is also why commiting very often is a very good idea. I often try to reassure people new to git that "if you'll just commit often, there's basically no way you can lose work so that I can't help you get it back. Apart from deleting the whole repo folder. Don't delete the repo folder.". I also have the habit of preventing non-fast-forward pushes on origin/master, which also helps when I can tell my team that they…

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

When cleaning up my own feature branch for review

    git merge —-squash
When merging into the baseline

    git merge —-no-ff
The reason for the latter is subtle. Yes, a perfectly linear history is nice in the aesthetic sense. However, the merge commits are artifacts of reviews that are useful in process audits, which QA and QC like to preserve.

Re: Git rebase in depth

#226

Post by fulafel »

raimue wrote: post #224
fulafel wrote: post #223

Earlier quoted context omitted.

But reviewers in most Git workflows mainly look at PRs. Then if as a reviewer you want to see how the sausage was made, you can zoom in on the commits, including all the messy reality of how the work was done. In some circumstances you might of course want to hide this, but in an open and safe collegial environment this lets the reviewer understand your thought and work process.

The reviewer also won't see all the things the author tried without ever committing these states. They don't need to see all the messy steps, or they would have needed to look over the authors shoulder all the time. I rather review the final patch series with changes in logical order and not necessarily in the order the code was written or with intermediate work that was later reverted or changed again. I do look at…

Sure, it's not a perfect record. But as in most things, perfect is the enemy of good.

The messy reality is valuable, when talking with your teammates about how the work was done and what kind of bumps were along the way. It's not about looking over their shoulders, it's about using data to develop together as a team, eliminating hinderances, etc - if you have the mutual trust to do that. And of course you yourself can go back and look for patterns of mistakes or problematic areas in code based on your history.

Like I said, to judge the change its, the whole PR diff is usually the most useful unit of inspection when you just want to see what happens. And if it's a big pr, you can of course always merge child PR's or branches against the big PR/branch, and look at the merge diffs.

Re: Git rebase in depth

#227

Post by gbacon »

malingo wrote: post #124

My eyes were opened on git-rebase when I read https://matthew-brett.github.io/pydagogue/rebase_without_tea... The full version of the command as $ git rebase --onto new-base start end takes the commit range (start,end] and re-commits them on top of the new-base commit. The commit range doesn't have to be a full branch and you don't even need to be on the branch to run the command this way. It's very intuitive and I n…

I’ll sometimes do the same for a rebase that looks like it will be hairy, and I like to call the bookmarks, for example,

    git branch my-branch-mulligan

Re: Git rebase in depth

#228

Post by JshWright »

Nullabillity wrote: post #167
gwright wrote: post #166

Earlier quoted context omitted.

It isn't lying. Advocates of rebase are always talking about a work flow where you are curating a set of proposed changes before merging into your "public" branches (.e.g, development or master). No one is advocating that you use rebase on your public branches or basically any branch that has been "published". We are talking about feature branches or spikes or branches that exist just on one developer's machine.

You're lying about the path that you took to get to that point, and you're creating a lot of (public) nonsense commits on the way there (unless you're very careful, and/or overly squash-happy). Whether you've published the true history earlier is irrelevant to that discussion.

In that case I assume you have also removed the backspace key from your keyboard?

Re: Git rebase in depth

#229

Post by gbacon »

rich-tea wrote: post #36
jaequery wrote: post #23

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

What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge. But maybe you use your history for something else that I haven't considered.

There’s a vast middle ground between those two extremes. Some history is worth keeping, and some is not. Noise commits are of the form “forgot a closing paren,” “comment/uncomment section while debugging,” “finally got it to compile,” “checkpoint,” “fix typo,” or “going home for the day.”

Code and by extension history should be easy for humans to read. For that reason, the signal is very much worth keeping and polishing, but the noise is not. Documentation of false starts, appealing but ultimately problematic design choices, and “why” information belong in comments, commit messages, or design documents — explicit rather than implicitly littered around the history.

Re: Git rebase in depth

#230

Post by chrismorgan »

A few markup errors:

• In a number of code blocks, angle brackets are not escaped, and so text doesn’t appear in the end result.

• `#include &ltstdio.h>` lacks the semicolon

• The paragraph immediately after the #conflicts heading lacks its

.

I also think it would be worthwhile mentioning in the first footnote a hazard of empty commits: that they will be dropped by default when rebasing.

Post reply on HN