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

71–80 of 87 posts

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

#71

Post by AstralStorm »

talkingtab wrote: post #57

git rebase -i on a master with no changes. As a sole developer, I am pulled in two different directions when using git feature-branch style. I want to make sure I never lose my work so I check in frequently- any time I start a change that might ultimately fail, I commit my current code so I can recover it. But I also want a clean, concise and useful history. After reading this article I tried 'git rebase -i master' o…

The only potential problem is that you should instead run git fetch -u and rebase onto origin/master instead. (By default your rebase will use the remote anyway, but won't fetch for you.)

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

#72

Post by AstralStorm »

JoshTriplett wrote: post #66
kobeya wrote: post #51

Earlier quoted context omitted.

If true, the the whole claim that nonlinear histories break git-bisect is bunk.

Non-linear histories work just fine with git-bisect. What breaks git-bisect are histories where every commit doesn't work; for instance, if you have one commit that breaks something, and a second commit that fixes it, git-bisect won't work well.

It will work just fine, you just might have to call git bisect skip a time or two or run it more than once.

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

#73

Post by AstralStorm »

epmatsw wrote: post #56
test1235 wrote: post #29

Earlier quoted context omitted.

e.g. remove console.log what do you need that in the git history for?

“Fix lint” is my favorite one.

My unfavorite is WIP and "update submodule(s)". In fact I contemplated making a git hook to reject such drivel on merge.

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

#74

Post by JoshTriplett »

AstralStorm wrote: post #72
JoshTriplett wrote: post #66

Earlier quoted context omitted.

Non-linear histories work just fine with git-bisect. What breaks git-bisect are histories where every commit doesn't work; for instance, if you have one commit that breaks something, and a second commit that fixes it, git-bisect won't work well.

It will work just fine, you just might have to call git bisect skip a time or two or run it more than once.

That's not "fine"; bisect takes long enough when you expect it to work consistently. And that assumes the code fails at build time, rather than mysteriously at runtime.

That also breaks the ability to do automated bisects.

I don't think it's at all unreasonable, at a minimum, to expect every individual commit to build and to pass tests.

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

#75

Post by james-skemp »

maxxxxx wrote: post #62
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…

Do people actually look at the history a lot? After a pull request has been merged I rarely look at the history and I am really not interested in it. This is for a small team with around 5 people. In larger teams is it more important to see the history?

I work in a University setting where we have student's working in our various projects. While some stay with us for a number of years, some are with us for a semester or two.

Even with full-time staff, in the almost 6 years I've been here the rest of the dev and design staff completely changed (and grew).

In my opinion, if you're not using history/blame your code is relatively new, or you're the only one touching code. Or you have regular code reviews (paired programming, whatever).

Seven years at my last job was just full-time staff, but we had the same issues, once a version control system was actually implemented.

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

#76

Post by james-skemp »

hdhzy wrote: post #16
splike wrote: post #14

Earlier quoted context omitted.

I think there are two perfectly acceptable schools of thought. One says that the history should be preserved exactly, because its important we keep a record of exactly what happened. The second says that its ok to rewrite history a little if that makes it more understandable. I think you would put yourself in the first, and that's ok. I would put myself in the second because at the end of the day I value understandin…

The usual rule of thumb is not to modify (e.g rebase) published commits. So it's perfectly fine to adjust local commits before they go into centralized repo - from the point of view of an external observer the history is never destructively modified. This rule can be extended to topic branches or user owned branches with the caveat that others should not base their work upon the topic branch. Also remember git push -…

And `git commit --amend`

I missed a semi-colon or a file? I probably noticed right after I made the commit (and before I pushed it to the remote branch).

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

#77

Post by pkamb »

neebz wrote: post #31

Does this work even we keep pushing commits on a remote repository? We extensively use Github Pull Requests for code reviews and most of the time we squash our PRs into a single commit but I would love to have a way to merge into multiple smaller squashed commits (as OP did) instead of one big.

The Interactive Rebase tool in SourceTree is very good and understandable/usable. I use it all the time to squash some commits, leave others.

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

#78

Post by radiospiel »

Tade0 wrote: post #49
chii wrote: post #35

Earlier quoted context omitted.

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

Ah, yes, this was implied :) only working code (as checked via CI) is allowed to show up in master and other long living branches.

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

#79

Post by nicwolff »

lolive wrote: post #69
Zitrax wrote: post #47

Earlier quoted context omitted.

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.

How do you enforce a commit policy in your projects? Do you automate it? Or do you provide feedback by mail, IM, ... to the author when a commit mistake is detected?

We have a GitHub integration that runs on every pull request and push, which triggers an AWS Lambda function that verifies that disables the big green "Merge" button if the branch could not also be fast-forwarded onto its parent.

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

#80

Post by jogjayr »

EnderMB wrote: post #23

I think a lot of people don't bother with rebasing because they either don't know how to do it, or they are scared of the idea of a version control system not explicitly saying what they've done to accomplish the latest version of their code. Once you get even a small understanding of it, there are plenty of places you can use it. For example, in the past month I've used it to: 1. Rewrite the history on a coding test…

Another note on #1 (which I've also done in the past). Don't your pre-rebase commits remain in the reflog?
Post reply on HN