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

Git: Using Advanced Rebase Features for a Clean Repository

mtyurt.net

Post reply on HN
Print view View original

41–50 of 87 posts

Re: Git: Using Advanced Rebase Features for a Clean Repository

#41

Post by kobeya »

burntsushi wrote: post #38
ekidd wrote: post #18

Editing git history makes sense in several cases: 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers. 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge. Editing git history makes less sen…

> I always twitch a bit when I see a 10-page blog post describing a "git workflow", with all sorts of complicated branching rules and heavy use of rebasing. That can make sense in certain specialized situations, but it shouldn't be considered a "best practice" that everybody needs to emulate. I tend to justify this based on a simple observation: writing clean code that is easy for others to understand is also hard. I…

How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git histories does.. what exactly?

Re: Git: Using Advanced Rebase Features for a Clean Repository

#42

Post by burntsushi »

kobeya wrote: post #41
burntsushi wrote: post #38

Earlier quoted context omitted.

> I always twitch a bit when I see a 10-page blog post describing a "git workflow", with all sorts of complicated branching rules and heavy use of rebasing. That can make sense in certain specialized situations, but it shouldn't be considered a "best practice" that everybody needs to emulate. I tend to justify this based on a simple observation: writing clean code that is easy for others to understand is also hard. I…

How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git histories does.. what exactly?

Uh, I read commit history all the time. (My initial comment assumes you believe the idea that a clean history is useful, because that's the context of ekidd's comment. So I really don't feel like debating that particular point, if that's what you're getting at. It's been re-litigated hundreds of times.)

Re: Git: Using Advanced Rebase Features for a Clean Repository

#43

Post by 0xcoffee »

radiospiel wrote: post #11

I personally almost never rebase and/or squash, since I think that the information that gets lost (like: when was it started, what were mistakes along the lines) might be useful for future understanding of how the project work evolved over time, and what adjustments should/could be made to the development process. But I understand that a screen as shown in the article is not immensely usuful. But if it comes down on…

I wish there was some happy medium, like that I can merge a branch and it gets squashed into a single commit, but then if needed I can 'expand' that commit to see its contents, even after the other branch is deleted.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#44

Post by exDM69 »

kobeya wrote: post #39
ekidd wrote: post #18

Editing git history makes sense in several cases: 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers. 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge. Editing git history makes less sen…

> 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers. This seems like an instance of adapting development practices to bad tooling, whereas we could be fixing the tool itself. Shouldn't there simply be a "tree aware" git-bisect that can intelligently h…

> Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges?

Afaik, git-bisect is aware of branches and merges.

But there are two drawbacks to not rebasing/squashing: 1) the number of extra commits. Although bisecting is O(log N), it still adds up if it takes a long time to run the tests. 2) if there are any commits that don't build or have to be skipped (git bisect skip) because of other reasons, the number of steps to bisect increases.

It's a good idea to ensure that any commit that goes to master branch will pass all tests or at least compile. Failure to do so will make git-bisect a lot less useful.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#46

Post by mikegerwitz »

kobeya wrote: post #41
burntsushi wrote: post #38

Earlier quoted context omitted.

> I always twitch a bit when I see a 10-page blog post describing a "git workflow", with all sorts of complicated branching rules and heavy use of rebasing. That can make sense in certain specialized situations, but it shouldn't be considered a "best practice" that everybody needs to emulate. I tend to justify this based on a simple observation: writing clean code that is easy for others to understand is also hard. I…

How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git histories does.. what exactly?

> No one ever sees the history, honestly.

Then you wouldn't see value in rewriting. Unless you're not reading the history because it's a pain to read because it's messy.

I use `git blame` relatively frequently to understand the rationale and history behind the code I'm working on, or to track down bugs. Of course, this also requires writing decent commit messages---something that I encourage developers to do so that those maintaining their code in the future have some direction. Commit messages are a bit different than software documentation, not a substitute.

I bisect looking for bugs, where a clean history with small commits _that actually build_ is essential to quickly finding a bug. That can even be automated if you can create a script that can run a test suite or some other test to check for success.

This becomes increasingly important the more code and complexity you're dealing with. There are other cases where I look at history, but those are significant examples.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#47

Post by Zitrax »

kobeya wrote: post #41
burntsushi wrote: post #38

Earlier quoted context omitted.

> I always twitch a bit when I see a 10-page blog post describing a "git workflow", with all sorts of complicated branching rules and heavy use of rebasing. That can make sense in certain specialized situations, but it shouldn't be considered a "best practice" that everybody needs to emulate. I tend to justify this based on a simple observation: writing clean code that is easy for others to understand is also hard. I…

How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git histories does.. what exactly?

No one ever sees the history?

Really ? To me the need for checking history is extremely common. Many projects have multiple delivery, maintenance and other branches, patches need to be applied here and there. Bugs are found and the versions affected needs to be identified.

Not maintaining a clean history would cause severe pain.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#48

Post by wry_discontent »

I vastly prefer rebasing and squashing. Just yesterday I had to review some history, and reading the blames was incredibly frustrating.

> Clean up style

What was this code committed with? What other changes came along with it.

Git, for me, has 2 functions. When I'm developing, it's to save my work in an incremental way that I can reverse. It's to make notes about what I'm doing. After I'm done, it serves as a way to lay blame on me for what I changed and to track those changes in Github. "Who wrote this? What was it committed with?"

I want my PR to be encapsulated in 1 commit after it's been merged. At that point, there is no reason to read the internals of what I changed.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#49

Post by Tade0 »

chii wrote: post #35
jeff_vader wrote: post #25

Earlier quoted context omitted.

Say we work together. Why would you want to see my 5 solutions to a problem in `master`, of which 4 actually never really ran in production? I do commit often, things that I try and later throw away are in the history. Once rebased and squashed, only final solution is in `master` history.

> 4 actually never really ran in production? but the history showed that it was tried (and perhaps the commit message can have a short note on why it wasn't selected). without the git history, you'd have to rely on human memory to know this. Or a separately maintained documentation (which, lets face it, is never going to get updated).

Or store it in another branch - that's the approach we had been using in one company I worked at.
Post reply on HN