I had a different experience with the Economist. I forgot to cancel and was billed. I emailed saying I forgot to cancel, could I unsubscribe now? And got a quick reply saying they'd cancelled and also refunded me despite me not asking.
I recently cancelled again after getting the 1-month renewal warning, and immediately got a 50% off offer, so I'll probably subscribe again.
I had a similarly easy experience with the Guardian a few years ago, based in Europe.
I had the opposite problem - with simple meals (the default) it looks like I was barely required to cook at all, just getting recommendations for some carrots and hummus or fruit on bread.
I guess that's something you could expect from a tool that doesn't require cooking.
_So many_ people are running red lights in Paris, there's been a huge increase in the past year or so. I think it's mainly food delivery service scooters.
I second this. It wasn't until I adopted this practice that the staging area really made sense to me. I find it helpful not just for making atomic commits, but as a way of remembering what I was actually doing, so that I can write a good commit statement.
This has never made sense to me. I've seen others say that they commit only parts of a file. How does this scenario start? Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change?
Partly, yes. Or, I'll be working on a task overall, and have to touch multiple files in the process. Then when I'm ready to commit, I review all the modified files on disk, and look for ways to break those down into smaller discrete logical changes. I prefer to avoid "big bang" commits as much as possible, because smaller individual commits are easier to inspect, easier to back out if necessary, and provide a better "story" when inspecting a file's history sometime down the road.
But then, you either never run/tested those smaller individual commits, or you have to do extra work (stash changes, test, restore stash) to do that.
I do not see why a source control system should make it easier to make a commit that hasn’t ever existed on disk and thus cannot have been tested.
I think the better model would be to stash your changes and have an diff editor between the on-disk working copy and the stashed version that allows you to commit a set of changes as several smaller, more coherent commits.
That wouldn’t guarantee that each of those intermediate commits gets tested or even built, but it would guarantee that each smaller commit is in the on-disk copy at some time.
> But then, you either never run/tested those smaller individual commits
Not necessarily. One nice option that the git rebase command has is --exec (which can be specified multiple times). So you can run a rebase and have git execute a command (like running a test suite) for each commit in the branch. If any commit files, the rebase process will stop and let you amend the commit to fix the issue.
> or you have to do extra work (stash changes, test, restore stash) to do that.
I've found that it's easier to write and locally test a given feature and them incrementally stage parts of it and create commits before pushing the code up for review. To me, that's easier than just making a large commit and then trying to split it out into a better set of commits after the fact.
For example, I may write a new method and then call it several places in the code. So my first commit would be to add the new method along with its unit tests and my second commit would be to add calls to it in the code base and update the associated integration tests (if necessary).
One common scenario is that I'm working on one problem, and in the process of solving that issue do some refactoring of related code. In this case, I want to commit the refactoring (which does not change the program's behaviour) before committing the changes that do change the program's behaviour.
I typically then send that first refactoring commit to Github (on its own branch) so that it gets full CI test coverage. And then continue working on the fix/feature while it runs.
One use case is to exclude extra lines of the file you don't want to commit. For example, I might have some debug print statements in my file that I want to keep in my local copy of the file while testing, but I don't want to include in the commit I push up for review.
> Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change?
Almost. Most often it's:
- Working on solving problem A
- Notice problem B
- Start to solve problem B
- Notice I'm getting distracted from A, and return to finish it.
- Want to commit my fix for A, but don't want to lose or forget the partial work on B.
Two different approaches I might take in this situation, depending on whether B is related to A.
1. If they are related (eg, B depends on A), use `add --patch` to commit A, then finish and commit B.
2. If unrelated, use `git stash --patch` to stash B, then commit A, then switch to a different branch to finish B.
Honestly, I see the point of both stash and staging, but not both together. Too many tools for the same job. On my long list of projects to do is a git porcelain that combines some of these concepts (eg, stash and working directory which would be tied to a branch):
- Each branch would have a single stash.
- When you check out a new branch, all uncommitted changes are automatically stashed.
- If the branch you're switching to has anything stashed, that stash gets popped.
- Any current workflow that involves stashing can be replicated by using a branch instead of a stash.
This way, branches can be thought of as "state of the working directory", which is more intuitive with the branching tree model, imo; commits are a snapshot of the repo at that point in time; and the staging area is just a way to choose what should be included in those commits.
If he is Satoshi, and what he's saying about being forced to reveal his identity now is true, it would make sense to provide the minimum that the threateners would accept, knowing that the community wouldn't buy it. That video is really odd. (FWIW I don't believe this claim is or isn't true, I'm waiting for more info.)
And yet the images he used in his letter came from Shutterstock, rather than directly contacting a photographer and checking they're okay with their image being used to illustrate the point he's making.
Not saying this isn't a problem, just that he doesn't like it when it brings him less money, yet he uses it in other industries because it's convenient.
Having some way to filter out the big agglomerators would be nice - obviously you can use 'buy used car -autotrader', but the majority of users don't realise they can do that, even if they would like to.
Actually, my mum uses it all the time. She's a primary school teacher, and it works great for children's worksheets, seeing as the 'a' is formed the way we learn to write it at school. Yes there's other fonts with 'a's like that, but not ones that are available on all computers by default.
I too learn effectively when I've got outstanding lecturers lecturing at me. However that's rarely the case - some lecturers don't really care for the students; some care but aren't that great at lecturing... So in practice, lectures don't even always work for students who learn effectively from lectures.
I recently cancelled again after getting the 1-month renewal warning, and immediately got a 50% off offer, so I'll probably subscribe again.
I had a similarly easy experience with the Guardian a few years ago, based in Europe.