For checking accounts, I have a list of rules that each transaction passes through. If a rule matches it generates the double-entry transaction going from the checking account to the account listed in the rule (or vice versa if the amount is positive). Earlier rules take precedence over later rules. If no rule matches it errors and prints out the transaction so I can add a new rule.
The main account I use for day to day spending is Monzo, they correctly categorise 99% of my transactions for me (and this is included in the csv export) which makes this way easier.
Scaleway and OVH offer all the basics and more (kubernetes, networking, hosted dbs, queues, storage, GPUs etc). It’s google workspace/microsoft 365 that has no equivalent.
Because they don’t offer every service AWS offers? They offer plenty of hosted databases, queues and what not that it shouldn’t be too hard to move things over. Especially not if you are on Kubernetes. Not if you are all in on lambdas of course but that is a problem in and of itself.
You can do that with just `jj split` too. The FAQ entry you linked to is for when you accidentally amended a commit and now you want to restore the bookmark to the old commit and move the changes you amended into a new commit on top instead.
I have used both Git and jj. I find it easier in jj.
`git reset` by itself doesn't split a commit AFAIK. You need to then `git add -p` and `git commit` (and recover the commit message from the old commit). And what happens if you had other changes in the working copy first? Or if you want to split a commit that's not at HEAD?
> `git reset` by itself doesn't split a commit AFAIK.
Git reset splits a single commit, into two "things", another commit with the first part and a second part that is put into a version prepared for a commit (--soft), prepared for further editing (--mixed) or thrown away (--hard). To me that counts as commit splitting, but it may not match with JJ terms. Also splitting into two commits with the same commit message doesn't sound quite useful to me, so the default of Git two require a second commit message is sensible to me.
Correct me I'm I'm wrong but I think were talking about using `git reset HEAD^` for splitting a commit. That will move the current branch backwards one step. With `--mixed`, it will also move the index back one step, so the index is empty (relative to HEAD) and the working copy has the combination of changes that were in the previous HEAD commit and the working copy (relative to the previous HEAD). I think that's more like squashing than splitting because we have fewer "things" after: we have one commit fewer (the previous HEAD commit may of course still be reachable from another branch, in which case we still have the same number of "things" afterwards). It's similar with `--soft` and `--hard`, except that the old changes end up in a different "thing".
At a less technical level, the point of splitting a commit is to end up with some of the changes from one commit in a new commit and the rest of the changes in another commit. That's what meant when I said "`git reset` by itself doesn't split a commit", because you need to do something like this:
git reset HEAD^
git add -p
git commit -C HEAD@{1}
> Ok, but then what was your point?
Just that additional steps are needed.
For example, if you wanted to split the HEAD commit but you had already started working on a new commit so have some changes in the working copy, then you might instead have to do something like this:
git commit -m tmp
git rebase -i HEAD^^ # Use the "edit" action for the first commit
git add -p
git commit -m first
git rebase --continue
git reset HEAD^
The other case I mentioned was if you want to split a commit on another branch. Then you have to insert some additional commands in that sequence. As I said, I know how to do this with Git. I just find it easier to do with jj, where it's `jj split -r xyz` to split commit xyz, whether it's the current working copy, an ancestor commit, or on an unrelated branch.
(Take my Git commands with a grain of salt because I haven't used Git in 10 years.)
> Correct me I'm I'm wrong but I think were talking about using `git reset HEAD^` for splitting a commit.
I wasn't. I wanted to do the same as in the FAQ entry we are talking about, so I wanted to reset it to an older commit representing the same change (i.e. before an amend that we are now reverting). This is likely in a rebase, but we can always rebase later and only do the splitting now.
> With `--mixed`, it will also move the index back one step, so the index is empty (relative to HEAD)
Yes and this is the default (without any flag).
> That's what meant when I said "`git reset` by itself doesn't split a commit", because you need to do something like this:
That's what the `--soft` is for, then `git reset` does not touch the index.
> Just that additional steps are needed.
The only "additional" step required is specifying a commit message, which, as I said earlier, to me is a sensible default.
What I suggested applied on this case would be:
git commit -m tmp
git checkout @~
git reset --soft previous-version # which you get from the reflog
git commit -C @
git rebase @~ branch-you-were-on --onto=@ # not of much use, when you only have a single commit you are throwing away in the next step, but when you are editing something earlier, this is likely what you want.
git reset @~
If you want to do it with rebase:
git commit -m tmp
git rebase @~2 # break after first commit
git reset --soft previous-version
git commit -C @
git rebase --continue
git reset @~
More idiomatic, due to using the global list of todo commits:
git rebase -i @~ --autostash # break after first commit
git reset --soft previous-version
git commit -C @
git rebase --continue
You can drop the rebase, when it is really the commit in HEAD you want to split.
Actually what you can also do, but this doesn't use reset, is this:
git rebase -i @~ --autostash
# add as the first line:
pick previous-version
git rebase --continue
This will even do what you wanted and just reuse the same commit message without asking.
Honestly, what I do most of the time to split commits (when there isn't an older version I want to split it to) is to just amend and then unselect the changes I don't want with the cursor.
Yet another way is to duplicate the commit and apply the partial reverse to the first one. I think this is what matches theory the most, and is what I essentially end up doing.
I don’t agree with the given answer to “Why the PO wants you to estimate”. The author cites external reasons (made commitments etc) that shouldn’t have been there in the first place.
Sure, in some lines of software development you really have a “deadline”, if you are working towards some event or launch date. But most of the time estimates are needed to determine *if it is worth it*. Can it be built in 2 weeks, let’s go. Is it gonna cost 2 months, then let’s prioritise something else. That isn’t to say you always have to go with the shortest te build features (you can apply "CD3" – Cost of Delay Divided by Duration), but you need it to compare alternatives.
For lots of jobs of “text querying” they do good enough of a job to be on par with humans (which are not infallible either).
And there are applications where you don’t have/wouldn’t pay another human, and the job that an AI does for mere cents is good enough most of the times. Like doing an analysis on a legacy codebase. I’ll read and verify, but running that “query” then saved me a lot of time.
Not everything needs to be deterministic to be of value.
I agree, they can be "practical tools for the job", that's where I ended my comment. The disagreement seems to be that "practical tool for the job" is the same as "right tool for the job". A hammer can be a practical tool for the job of screwing a nail into a wall (once, at least) but few would call it the right tool for that job. An LLM can be a practical tool for a text query (at least as a first pass, at least with review and a grain of sand), but if you need reliability or repeatability or the ability to send results directly to a customer without a human in the loop it may not be the right tool for the job.
There's obviously a value in practical tools, deterministic or not. It's just worth making the distinction that a practical tool is not always fit for purpose as the "right" tool if you really are seeking the (most) right tool for the job.
reply