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

Git rebase, what can go wrong

jvns.ca

Post reply on HN
Print view View original

291–300 of 404 posts

Re: Git rebase, what can go wrong

#291

Post by bogeholm »

gwright wrote: post #190
bogeholm wrote: post #108

Earlier quoted context omitted.

I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. I prefer one commit to main per feature, a long with a good description on the GitHub PR. Sometimes I’ll branch out from a feature branch for the occasional and infamous ‘get CI working’ round of 10 one-line commits though, to not make it too muddy.

> why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Several reasons: * facilitates much better code review discussions * enables use of git bisect to locate bugs * allows for informative commit messages associated with the changes * communicates clearly to future self about why changes were made

> facilitates much better code review discussions

Hmm, I usually mark PR’s as draft until ready for review, and then I expect the discussion to be about the current state, not a previous intermediate state. Easiest with small PR’s.

> enables use of git bisect to locate bugs

Interesting. I know _of_ git bisect, but haven’t used it as part of my workflow. Have you found it useful to bisect commits on a feature branch (which, presumably, represents unfinished work)?

> allows for informative commit messages associated with the changes

I find using the PR title and accompanying info in GitHub or similar to be quite informative - that should convey the purpose of the change.

> communicates clearly to future self about why changes were made

See above. Perhaps we work differently, but I find it clearer to read a git history where each commit represents a single, complete feature/fix/refactor instead of intermediate steps.

Re: Git rebase, what can go wrong

#293

Post by mixmastamyk »

Chris_Newton wrote: post #271
gwright wrote: post #232

Earlier quoted context omitted.

Not my experience, nor my team's experience over almost 10 years of using this approach.

I’m firmly in your camp on this one, but I’ve noticed that advocating a tidy history gets a lot of push-back online. I think there is an element of self-fulfilling prophecy here. If a team habitually leaves a messy history behind, that history is rarely going to be useful, so naturally the team has low expectations and sees little value in doing anything to curate it. And if a team isn’t used to making an effort to c…

If a strategy requires humans to be virtuous AND vigilant it is doomed to failure.

I rarely use history and prefer merge/squash, with automated CI tools, and tests. "Why" is kept in doc strings, comments, specs, and story tickets. Everything viewable in gitlab with automatic links. All this gets out of the critical path, every day.

I submit that, if your code is so complex that diagnosing a bug is a major research project rather than moving forward with a few extra/modified lines of obvious fix, then that is the problem to focus on.

Re: Git rebase, what can go wrong

#294

Post by tormeh »

AndrewDucker wrote: post #70

I find it fascinating that people talk about "Having a history of what people did" in such emotive terms - "Cluttering", "Polluting". What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot o…

The git history of a project is the main source of knowledge on that project, once the people that wrote it are gone. The git history answers questions such as "wtf is that supposed to do?", "what's this code connected to?", and "why did they do it that way?". You can use other kinds of documentation, but the git history is always there, so it makes sense to make it semi-useful.

Re: Git rebase, what can go wrong

#295

Post by mixmastamyk »

Terr_ wrote: post #272
watwut wrote: post #225

Earlier quoted context omitted.

Frankly, people lately spend more time managing commit history then using it. Like, commit history is useful once in a year little bit, maybe, but we spend absurd amount of time trying to make it look nice.

> Frankly, people lately spend more time managing commit history then using it. At one company with a Giant Custom Enterprise App, I ended up occasionally acting as a historian for pieces of the company with bad communication/institutional-memory, ex: "Oh, the +5% Foo charge was because of a request 3 years ago by vice-president X, here's the ticket number, before that it used to be +3%." In those circumstances--wher…

Comment with a ticket-id would be more efficient.

Re: Git rebase, what can go wrong

#296

Post by yxhuvud »

zaptheimpaler wrote: post #278
dkarl wrote: post #92

Earlier quoted context omitted.

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with…

I get why you would prefer it clean but its just too much overhead for me. I naturally make lots of changes together - especially on a complex feature, you need to build things in a "full-stack" way horizontally so you can test as you go. Then pulling things apart into "clean" atomic commits later just takes too much time and I don't really know how to do it efficiently.

The thing is that when you get good at it the overhead will go down drastically. And the practice will make it easier and faster to extract small pull requests out of your main work that can be reviewed separately.

Re: Git rebase, what can go wrong

#297

Post by ozim »

0x6c6f6c wrote: post #290
throw555chip wrote: post #275

Earlier quoted context omitted.

> For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commits cluttering up the commit history. The purpose of history is to remember. Rewriting history, whether git or in life, is bad; outside of the context of don't use it on public repos. Such advice is similar to saying, only point the shotgun away from you when firing. If you have to rememb…

But in unmerged branches, you aren't rewriting history, you're starting your work on a more recent commit in history.

Shush, don’t say those things because maybe people discussing merge vs rebase will realize they don’t discuss but just talk side by side.

One and the other does not care what is the context and what they discuss but apparently each one just knows better.

I also don’t mean those specific users - but in general any git discussion I saw for last 10+ years.

Re: Git rebase, what can go wrong

#298

Post by mixmastamyk »

m000 wrote: post #280
watwut wrote: post #225

Earlier quoted context omitted.

Frankly, people lately spend more time managing commit history then using it. Like, commit history is useful once in a year little bit, maybe, but we spend absurd amount of time trying to make it look nice.

Curating the commit history takes like 10' per PR and can easily repay in hours of work when some bug hits. Or when you want to tell the junior that wants to implement X for A, why don't you take a look on this one commit where we implement X for B?

Is there something wrong with the latest version of the method? Instead of one from ~18 months ago which may not work any longer?

Re: Git rebase, what can go wrong

#299

Post by gosub100 »

m3kw9 wrote: post #20

Git rebase is stupid, I’ve seen countless f ups because someone needed the git history to look good

my case for good-looking history is pride of ownership. Are you proud of this "thing that makes money and ultimately pays your paycheck" or do you leave it polluted and full of crumbs and detritus?

I would have made this part of a root-level comment but I doubt anyone would read it, but: I think what gets lost in all these git debates is what language/context are we talking about? a shop that churns out javascript and releases to prod every 8 hours is very different than a C++ shop that writes safety-critical software. Their git needs are very different, and having an "I make my bed every day at 5:30am before I go for a 5mi run and come back and drink my juice and eat avocado toast" git regimen may be appropriate for some codebases but not for others where "I woke up hungover at 10am with a partner whose name I cannot remember, in a bed that is not mine" regimen. I think countless human-brain cycles are lost to bickering between these 2 camps.

Re: Git rebase, what can go wrong

#300

Post by erik_seaberg »

watwut wrote: post #225
bonzini wrote: post #206

Earlier quoted context omitted.

The point of the parent comment is exactly that you should clean up the history before merging to a public branch, so that you can use bisect, even if so far you had wip wip doh wip as the commit messages. The way to get there is to have a mix of proper and wip commits.

Frankly, people lately spend more time managing commit history then using it. Like, commit history is useful once in a year little bit, maybe, but we spend absurd amount of time trying to make it look nice.

If I can invest business hours and get back minutes during an outage at 3 AM, I should do that.
Post reply on HN