skysight-inc/HackerNews huggingface dataset:
yep exactly this. I found early on while having to work with perforce and using timelapse view (git blame but with a nice gui) that lots of intermediary commits like this generate enough noise to discourage even the most determined sleuth from using commit history to solve a crime.

Well scoped and well sized commits, squashed, and in my personal preference rebased, provide a commit history that's segregated on actual tickets/stories/features/fixes that I find are navigatable very far back.

I'd say squash usage is very much case by case. But yeah equating a feature like squash to large commits is a fallacy. It's a useful tool imo that can be misused, but that doesn't mean the tool is "bad".
Caper (YC W16) Hiring Android Engineer (Remote OK)
Criminals have right to due process too.

Perhaps the access data should be released with a delay to protect current investigations, or sealed altogether for a very good reason with appropriate authority.
I do, all the time. I highly recommend others do it too. I like to keep to 1 commit per ticket (even a super large ticket that might take me weeks of development). But having a commit history like the fella in this story is nice too. So what you should do is work in a feature branch. On the day of deployment I'll squash, and cherry pick (in my case to a train). If the deployment goes bad, and my code is at fault, then all that is required to fix it is a single revert.

If you want to continously deploy to production (with real users using it) you need a process to very quickly revert bad commits from it. At my last company with hundreds of developers, we would push to prod several times a day. Each deployment would have several devs changes included. A clean linear history is essential to making that process work.
That's much better than looking at a file in a 300 file commit and seeing "merged from XXXX" with no information as to why that one line was changed. I'd much rather spend 30 seconds parsing through the 10 yak shaving commits than have to go trawling through old commits on a file to find the most likely owner of it to ping on slack.
The only time I ever do it is if it's trivial. Say I've removed some vestigial code, then I find some more after I've committed.
> Correlation, maybe -- not the same as comprehension.

The problem with this argument is that, although it is right (I agree!) it will not carry the debate.

_The_ problem here is that there is a large group of political moderates who trust authority. Arguing that the authorities will misinterpret and/or abuse statistical evidence will not sway their opinions.

It is difficult to convince that group to limit the power of government. The best argument I came up with was an appeal to a fundamental right to privacy; but that has pretty much all but evaporated in today's world. Privacy is too expensive and might be politically untenable. That argument started to collapse in the hysteria after 9/11 2001.
I work for enterprise using Teams and that doesn't change the fact that it would be faster to send a pigeon with a printed sheet of paper than edit anything through Teams.
I upgraded to a Xeon because of LUKS encryption; Celeron doesn't have hardware support for encryption. Indeed I run a computationally heavy workload - boinc with protein folding and TB prevention :)
Yeah, I'm happy I learned about `bisect` with this blog post, but I (almost) always make sure my squashed commits build.

However, I try to only squash into logical units, I don't try to cram the whole PR into one commit
>get the APK from wherever

What an improvement over https. I'm glad the android sandbox has given us so much security.
UP42 | Multiple Roles| Berlin | Onsite | Full time
https://up42.com

- What we do: We are creating a developer’s platform for geospatial data and satellite imagery. Think a plug-and-play CI/CD pipeline for geospatial data. We provide the infrastructure and data to users, where they solely have to focus on implementing their models instead of the machinery behind it. The startup is well-funded by Airbus

- Who are we looking for: a whole new product team: Product Manager, Backend, Frontend Engineers

- Remote: no, we work from home now but the role is based in Berlin

- Applications: https://up42gmbh.recruitee.com/#section-123237
This line doesn’t line up with the data also in the article. The gross margin on each product is about 40%, you then lose 15-25% on stocking the machines, plus have to pay for gas, a car, insurance, repairs, initial outlay of machines etc.

You’re getting maybe 5% net margin.
Looks like they are open to implementing newer APIs in the future. So if the version reported can be spoofed or modern browsers only feature sniff then there is hope.
Depends on the Git craftmanship of the team is my experience. If they commit every small fix with a useless commit message, history becomes messy real quick. Squashing can be seen as a solution here. Until you learn proper rewriting of history as in (interactive) rebasing. After which you can put you code changes in every commit you want and order them around as you see fit. But that also depends on the Git workflow that is used and how much branches are shared amongst team members.

I had one job in the past that used Gerrit[0] as Git tool. One of it's features is that it creates a "pullrequest" for every commit in the branch you push. Which needs to be reviewed individually. This is really anoying if you're used to organising your work in lot of commits to record each step of your developerment. But from a project's Git history perspective it makes a lot of sense. As every commit is 1 change, one feature, one contained unit, that is added to the main branch. So instead of the main branch now containing countless commits with each developers complete history on a specific feature (where code is added in one commit to be removed in the next) it contains the features as distict commits, making them easy to bisect and revert if needed. This looks a lot like squashing but because you do it before you push your code you learn to put much more thought into that single commit and the commit message.

[0] https://www.gerritcodereview.com/
Everywhere is "Silicon Valley of Europe". Silicon Saxony, Silicon Roundabout (London), Silicon Fen (Cambridge), Silicon Docks (Dublin), Silicon Glen, etc
Right? Very good job from CSIR Govt. Labs - https://www.csir.res.in/
I think part of it is that a builder’s work has no leverage behind it. A day of work might positively affect the 5 or so people whose house was repaired. A day of software development may impact millions of people.
Personally, I have never seen a person become a worse person after a psychedelic trip, and I've been around this a lot. I have seen many selfish and hateful people seeing outside their perceptions for the first time and finally realizing that they are a human just like everyone else, not some perfect saint free of flaws, or whatever else they had concocted in their head through the lens societal norms.

There are people, particularly among the younger, that take the drugs to "get f'd up". And I've seen those people have great times and come back more grounded and with more respect for reality, and I've seen those people have horrific experiences, in which their ego's are stripped and they are forced to see the impact their behavior has on the whole. Those experiences usually affect for much longer and are more immediately negative. But from what I've seen of those, the people who change most for the better are the ones that have the most to change, and the one's that have the most to change usually have the more intense/difficult realizations. There are such things as bad trips and there are people that come out worse, I won't deny that. But what I've seen is that the difficult experiences end up being the most valuable. It usually hurts to realise your whole life has been meaningless chasing of someone else's dream, or that you've been an asshole to everyone and making the world a worse place. But you can't intentionally change what you don't know exists.
I think they fixed that in a firmware upgrade.
I'd add that what people here are calling a "side hustle" is something that quite a few people without a lot of marketable skills would call a job/income stream. And, yes, there are a lot of jobs/income streams that work for individuals who lack a lot of alternatives that don't work for companies that have offices, accountants, etc.
The reason to squash commits is more than just keeping your commit history read-able, it's about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues.

If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue. If I had spread that endpoint across 25 commits, I'd have to actually debug the issue in QA and figure out what I broke. Reverting quickly lets me debug the issue on my time instead of keeping our test suite broken.

It's not always feasible, and I try not to be a stickler when people on my team don't do it but the fact is, if you're working in a world when you're delivery code quickly into real environments, having a back-out strategy is paramount.
Originally I presumed this was an error importing Excel files and an upload file size limit..
>you now have 30 tool-specific ways to write "true" and "false"

ISO8601 joins the chat.
Limiting max rpm might also be one way to reduce F1 engine expense. A naturally aspirated engine with, say, a 10k max rpm limit.
There are reasons why European banks aren’t exactly lining up. One of which (from [1]) "The ease with which suspect foreign money can enter the economy has become an essential aspect of London’s success."

Good luck to any institution/nation that would want to replace London as a financial hub. There is a lot of dirty money floating round. Any bank that decided to take on a new customer would need to do all the financial background checks which makes it so much harder to turn a blind eye with a wink. The situation in London markets is very much like the scene from Casablanca where Captain Renault announced “I’m shocked, shocked to find that gambling is going on in here!”

[1] https://abcnews.go.com/International/londongrad-real-life-fi...
Any tennis player could get the best racket and shoes from any sponsor, or buy it themselves.

The costs to have a F1 is incomparable. Any single part alone is astronomical and many have to be changed between races. Having a car at all for training is a miracle!
To nitpick, that list has at least three British films pop up in the latter half of the 20th century (Goldfinger, Diamonds are Forever and Moonraker). Relaxing to "non-Anglosphere" is still very notable though.
Wouldn’t it be easier to start with something like roof tops and start making roofs reflective?
I think what you really want is neither of squashing nor retaining: what you want is to take the messy history you had and then reconstruct a history that makes sense and commit that; thankfully, git makes this easy. I hate it when people leave messy thoughts in the commit history as I do use the history, and it is even worse if they just leave mega-commits. I want to see easy to review step by step organized thoughts designed to help the reader appreciate the series of steps needed to bring you from where you were to where you went.
It really depends. I've seen developers commit tiny changes all the time, which do not make sense - I wouldn't want to trace a small logic change over 10 commits. Also, sometimes you commit, then realise that there's a stupid mistake you've made and then you fix it with another commit. In those cases it does make sense to squash the commits so that you get a normal, logical, commit in the history. On the other hand, squashing perfectly legit commits together into a horrendous single commit is a pretty bad practise for obvious reasons.
"I like paying for it so the author gets paid "

I've been thinking about this: If this is the only reason you use an ebook-store (like the Kindle store), this would be fairly easy to create a 100% competitor for - after all, there's no law against creating a site for giving money to your favourite authors!

...and then you could create a plugin/API for embedding a "pay for book" button onto other sites - like pirate book sites, and the ONLY weapon Amazon would have against it would be the legal weapon against the pirate sites!

Also you'd probably want the give-authors-money site to be run by a trustworthy nonprofit.
The post’s argument is illogical.

It doesn’t follow from wanting to speed things up for other teams that you can avoid some kinds of testing in the pipeline by having monitoring. That makes no sense.

It also says a full test suite in the pipeline is not needed because there should be monitoring in production.

Monitoring doesn’t catch all bugs, and letting things fail at a later stage isn’t the right path for a CMM level 5 application that lives and/or serious investment depend on.

Granted, while application monitoring puts additional ongoing load on the application, which slows it down, going against the desired goal of speed, it can help to have application monitoring that may identify slow, insecure, or error prone queries. However, that shouldn’t have to run constantly unless it has low overhead. Also, if problems are just reported after deployment and aren’t a gate to deployment, then you’ll keep pushing crap code into production.

So, what I’m reading here is that Dev Ops, as defined, values getting things through the pipeline quickly, so that when bugs, security, and performance problems are found, those aren’t a Dev Ops problem, and those production issues can be handled by developers, because they’ll have fast feedback from monitoring that maybe they didn’t kill someone yet?
Likewise for all languages. 850 words is plausible effort for tourism, 25,000 isn’t.
So was cgi-bin on shared hosting providers!
Well as Lincoln said decades ago, we if falter and loose our freedom it will be because we have destroyed ourselves

I think China is a threat, and they will cease upon our weakness, but I do not believe China can do this on their own

For the US to fall, it will be down to our own hubris and internal division, not an external force or a china run Social media service hosting 30 second banal mindless videos
For me, it's the other way round: minor updates like spelling, renaming, or test fixes during initial development can really clutter the major updates.

If i am making a commit that makes a complex but important change to some significant application logic, i want that commit to contain that change and only that change, so that when i have to re-read it a year later, it's completely obvious what i did and why. Bundling a load of refactoring and cleanup in there is a significant speedbump for my understanding.

Years ago, a sage pointed out the argument for squashing is really an argument for better tools. Imagine if you could flag commits as being of two types - major/minor, significant/insignificant, feature/refactoring, foreground/background, melody/rhythm, etc. Then imagine if the tools would by default hide, roll up, or otherwise de-emphasise the commits of the latter kind. This whole apparent dichotomy would go away in a flash.

This idea is floating around in the Wiki world. I believe it was Ward's Wiki that introduced a 'minor edit' checkbox in the editor; if a change was marked as a minor edit, it wouldn't be show on the recent changes feed.

You can imagine other ways to get somewhere similar. For example, you could have a special kind of commit that just groups a previous run of commits, and the tools could show that and hide the members of the group by default. There are probably many other ways to do this.
Humans are more closely related than we commonly think
You keep saying this, but you leave out the fact that not that many publishers sell direct, and most popular books are not available in this manner.

So yes this works _sometimes_, but not most of the time.

For the majority of users who are looking for a very specific book, not just _any_ new book to read, buying it digitally means buying it from a DRM-laden marketplace.
Granularity helps with bisecting issues.
For that amount of money I think standards should be way higher than for Bob from accounting who built a clever Excel sheet. I don't expect perfection, but there are ways and techniques to build and run software in a way that minimizes the likelihood of such problems, and this really doesn't make the impression that they followed any best practices at all. They should (but of course won't) be held accountable for that.
i was talking about the ratios though. the unfair advantage for the top guys in a winner-takes-all system is just that. top guys/teams always snowball themselves into the next big thing easier than lower rated guys.
VoiceAttack 1.3.7 Crack and License Key Free Download (2020)
The case for lockdowns is littered with dangerous logical fallacies
SaaS Startups: Forecasting Your Customer Acquisition Cost
They can both be pretty useful. So keep all commits and decide upon viewing the log which ones you really want to see.
Interesting, it seems like madness to me to have it the other way around. Why bother with a merge commit if all the changes are squashed into one anyway? Why not just fast forward merge as if it was a commit directly to the main development branch?
If you look at the PRs list, you will have a clean and tidy history.
Ask HN: If you were to build the web today from scratch how would you design it?
> That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge/squash commits, not 20 large ones.

With the people I've worked with, I'd say most don't commit at all until they think the code is "ready" and they commit all at once. In the teams I've worked with, squashing vs not squashing isn't the question. I just want them to commit/push as soon as they've hit a stopping point or at least once a day. Maybe the people you've worked with are good with git but I am not that good with git.

I'm still stuck on 6: Resolve a merge conflict on git exercises because I made one too many commits and now the exercise says I have too many commits.

https://gitexercises.fracz.com/

Previously on HN: https://news.ycombinator.com/item?id=24671638
Across The Universe – A three minute web experience across the universe
I mean comments like this are the reason there's such a stigma against medication. It's kind of ignorant to say that "psychiatry is broken", "my meds ruined my life", or "I made it through school without them so I never needed them" as if none of those things had anything to do with you.

Someone in the same situation might feel much the opposite, but they also shouldn't use their experience to convince people that their attempt at treating a condition they have is inherently a bad choice.
Many sports have regulations to prevent huge money from stealing the sport from the humans competing: thinking of swimsuit regulations in swimming, budget for football teams, ...

Sport should be more about individual qualities of the sports-man/woman than about money buying them some more advanced technology.
Sweden has destroyed the case for lockdown – spiked
I would love to see this in Spanish or Mandarin
Show HN: Bootstrapping an asset store for AR creators and ML engineers
It doesn't matter if it is more effective, but it is cheaper than employing people connecting dots.

Also the generation currently in politics would feel left behind if they didn't employ such pattern matching systems, even if there is no evidence of crime reduction.

It is part of the quantification of everything. You don't just get a number, you get several thousands and the judgement on you is calculated on the fly.

I think people responsible here are still the ones that decided to buy it. They are responsible the market exists. Also not a mystery since those people are mostly evaluated by how many people they put behind bars.
Good. Lord.
Is that definitive?
> If I had spread that endpoint across 25 commits, I'd have to actually debug the issue in QA and figure out what I broke

No, you could just revert the entire lot in one go.
Programmers can have the best of both worlds. Use granular commits on a local branch and squash merge into shared branches.

That way one gets clean shared history while preserving local work history.
Looking for Node.js and Python Devs in Hamburg/Amsterdam
You could always use your number now to get in, then erase the number from the account or switch to a dummy number (if allowed).

They don't offer this option anymore, I think they stopped offering it when I first opened a ticket. Plus giving them a number, even if only for a limited once, just perpetuates the situation...

curious if you could post the article there

I'll take a look, but then again I'm not usually interested in social media: I did this solely to benefit profesionnaly from the network effect of (i) my colleagues who are active on Twitter, and (ii) Twitter itself.
>it's puzzling how the right molecule shows up in the right place.

Most chemistry is like that though isn't it? Everything is flying around randomly but the electron density distributions mean some "bonds" have better probability of being broken and made during reactions.
Thanks. FYI, IAAL; I don't claim to be the world's greatest, but my clients seem to appreciate it when I tell them that I think that Contingencies X, Y, and Z are acceptable business risks for their situation — after explaining the nature of the risk — and I've never had any kind of malpractice claim, knock on wood.

Example: Many years ago, on the afternoon of the last day of the quarter (when lots of business gets closed for financial-reporting purposes), a software-company client's VP of sales — with whom I'd worked for years — called me and described a situation, saying "the customer wants to change our contract to say X." I asked a couple of questions and then said "there's always the possibility of Bad Situation B coming up, but it's unlikely, and it'd be manageable if it did — go ahead." The VP said "Thank you — bye!" and slammed down the phone. (That VP went on to CEO positions at two other companies and uses me to this day.)
Thank you! I actually really need this right now.
That, or "people" make their own educated decisions about the trade-offs they are accepting, and those may be different - yet equally valid - from your own decisions.
Thank you for these points. I also noticed export to Markdown. Exporting to usable formats is definitely a sore point for OneNote, especially the web version.
You can also have merge commits and revert only the merge commit in this case...

But yes, generally history is much cleaner when squashing commits.
Spaces vs Tabs, but for languages and cultures.
Let the flames begin.
It's worth noting that it depends on employment contract in Poland. Rules (if any) are different for B2B(freelance) contracts. Also NCA itself can differ, from forbidding to work with other companies, or simply forbidding you to poach clients(I've only ever seen this one in use).
Nobody is suggesting you should make commits so small they're non-functional.
I often do intermediary commits that don't compile or break something significant, only to make sure that I don't lose the code. When that happens I always squash my commit afterwards once the code is in a usable state.

The alternative is making bisecting harder which is not something that I want. I want every commit to compile and be testable individually. That definitely doesn't mean that I think it's a good idea to have "gargantuan" commits.

An ideal commit should contain a single, atomic change to the codebase. Not more, but also not less.
So, if Bill Gates had read more sci-fi, he could have had a better vision about the significance of the internet ...
I don't see incentives to give Twitter my phone number or my real name

For personal use, I don't either, and in fact I don't see incentive to give Twitter anything at all and would gladly avoid it. But to put forward one's work in academia, anonymity (or absence) isn't so great.