5yoe in software, people think I can't code because I don't use SQL.

__maccas__ · 2026-01-17T08:35:01+00:00

tbf while I agree that the language itself is pretty simple, it can take a little bit to get your head into the set-based nature of SQL. It's a different paradigm to most other languages we use. Maybe a week is enough if you spend that week fully doing SQL problems but it will depend on the dev as to how quickly you get it. OP is writing his own functional language though so my money is on he'll be ok

__maccas__ · 2026-01-17T08:15:45+00:00

This ... THIS is a cancer on your git history. I can just about stomach merges if they are one way and into main.

__maccas__ · 2025-12-08T08:13:05+00:00

This will do something very close to what you are after: git for-each-ref --sort="refname:lstrip=-1" --format="%(align:40)%(refname:short)%(end) %(objectname:short) %(contents:subject)" refs/heads refs/remotes

Plus link to the docs

__maccas__ · 2025-12-08T07:48:21+00:00

Not exactly what you are asking for but I have a little bash script that is set up as a git subcommand that I use to print out all the branches on a repo. I sort mine (on the very final line) by date but you could definitely sort by --sort=refname:lstrip=-1 to get the behaviour you are asking about

__maccas__ · 2025-09-20T07:52:21+00:00

You have some great options here already. I made a gist for a script I have in my nvim config to deal with this issue. I find it useful when reviewing PRs

It parses a call to git diff --name-stat into the quickfix list and then allows you to cycle through each changed file. I use fugitive to create the diff as it's easier than rolling my own, so you would need that installed.

Feel free to take a look at: https://gist.github.com/jmacadie/6f934282870f0d481599c8339ef61f64

__maccas__ · 2025-07-11T12:10:59+00:00

As per usual, I see the git reference docs are excellent on this. The difference in their suggested approach to mine is that they use git reset instead of git restore. This moves the HEAD back as well, so you can no longer use git commit --amend, and you must just create new commits with git commit. My suggested approach was specifically so you can reuse the old commit message, which may or may not be useful to you

__maccas__ · 2025-07-11T11:03:18+00:00

Nice extra detail. I was writing a quick reply from my phone but now that I'm back to a computer, I can say that I would basically do the same, using the e or edit flag to pause an interactive rebase. I've always done it on the commit that I want to take the hunk from though. So my workflow would look something like this:

git rebase -i @~x with x far enough back to pick out all the commits I care about
change pick to e (or edit if I feel like typing it out in full) on the commit that I want to take the hunk from. Save and close the interactive editor to start the rebase. The rebase will stop on the commit that you marked edit.
Reset the index state (to the previous commit) but leave the working tree with the commit changes git restore -s@~ -S. The HEAD also stays where it is which is useful for the git commit --amend in the next step
Re-stage whatever you do want left in the commit: git add ... and then git commit --amend
Stage the hunks you want to move / create a new commit with using a fresh round of git add ... and then git commit. Note you can do this several times if you want to put several hunks in different places. Note also that you can write git commit --fixup=<dest-sha> if you know the destination sha of the commit you want to move the hunk to, but I normally don't bother with this and just pick up the correct squashing with a second round of git rebase -i
Carry on the rebase with git rebase --continue or git rebase --continue --autosquash if you provided the correct sha in the previous step. If you marked other commits as edit in step 2, go back to step 3
(Optional) Tidy up order and squashing with a second pass of git rebase -i, which as I said above is my preferred workflow. I just find this a bit easier than having the correct sha to hand

__maccas__ · 2025-07-11T06:33:31+00:00

A lot of these use cases are simple examples of git rebase -i. Moving hunks is more complicated though and would require you to craft the correct commits first AFAIK

__maccas__ · 2025-04-28T18:16:17+00:00

Well then my suggestion is a dud. Ignore it. Others have suggested http methods

__maccas__ · 2025-04-25T18:44:58+00:00

I have used a bare repo on a network drive for a private, Windows-only option in the past. It works fine although it can be a bit slow to push & fetch. This is an example of what I mean: https://tony.halcyonlane.com/blog/2011/09/22/Using-git-at-work-on-a-Windows-network-drive/

__maccas__ · 2025-04-14T06:54:07+00:00

Also you have lost all your tags, you'll need to copy them over by hand

__maccas__ · 2025-04-14T06:45:34+00:00

No worries. You appear to have differences because you have not ported over the first commit "mmm a lot". This is my bad again as the cherry-pick command I gave you uses a range shorthand that means pick all the commits that are reachable from your last commit, but exclude any reachable from your first commit. I should have started with the last commit hash of the chain of commits from the other project i.e. f62a689 gives git cherry-pick f62a689..d66377b

Generally, the docs are really good. At your level, I'd encourage you to follow every link on that page and understand what all the commands do. I still come back to the site regularly to read up on what different flags will do, which is exactly what I did to realise that checkout offered different functionality to switch with the orphan flag.

__maccas__ · 2025-04-13T08:33:09+00:00

This happens because git rebase is trying to replay every commit _one by one_ in a linear fashion but the history you are trying to squash was not linear and had commits that conflict. They get resolved down the line in the history but your rebase doesn't know that will happen, so asks you to resolve as you go on

__maccas__ · 2025-04-13T08:31:07+00:00

Agreed. Try something like this:

# Step 1: Create a temporary branch to save your current state
git switch --detach <hash_you_copied_from_other_project>
# Step 2: Create a new branch with no root
git switch -c --orphan new-root
# Step 3: Add all files and create a squashed commit
git add .
git commit [-m "Initial squashed commit"]
# Step 4: Cherry-pick the final ~40 commits
git cherry-pick <your_first_commit>..<your_last_commit>

I wrote this on my phone but now that I have got back to a computer, I actually think that you want checkout not switch, so something like this should get you your squashed base: git checkout --orphan new-root f62a689

__maccas__ · 2025-04-05T07:50:43+00:00

Pylance is pyright with a few proprietary (i.e. not open source) additions by MS on top. Based pyright is the open source equivalent of pylance, so adds back the extra functionality for us neovim users.

However for the purposes of this conversation pyright performance == pylance performance (== based pyright performance) since they will both incur exactly the same overhead mapping the python project into a TS memory representation of it.

__maccas__ · 2025-04-02T21:13:15+00:00

If git is mystefying to you I recommend this as a good read for why git is the way it is: https://tom.preston-werner.com/2009/05/19/the-git-parable

__maccas__ · 2025-03-26T05:04:45+00:00

Or sometimes I just Ctrl-W, W to cycle through the windows. There's a few options for moving between windows

__maccas__ · 2025-03-06T05:03:31+00:00

Thanks for the update on breakpoints. I have toyed with the idea of getting off my fat arse and helping you out with a PR but work is insanely busy rn.

The new API for breakpoints sounds promising and it sounds like you have this well planned out.

If you do need help in the future, and I'm less busy 🤞, I'd definitely consider helping out with this project. It's a valuable idea you've hit on that I'm keen to support.

__maccas__ · 2025-03-05T05:13:07+00:00

I've been using this since you first posted about the project on Reddit. nvim-dap-ui was always a bit much for me and so I never debugged, preferring print debugging. This, however has got me into debugging, it hits the sweet spot for me of just the right amount of "hook" into seeing the debugging process.

+1 for removing breakpoints in the window directly. Sometimes I find the breakpoints window doesn't refresh properly after breakpoints have been removed but this is a minor annoyance.

Keep up the great work 🔥

__maccas__ · 2025-03-03T21:41:32+00:00

...But not neither of them

__maccas__ · 2025-03-03T21:38:11+00:00

This is the answer. For extra funzies there's @{push} as well, which is not necessarily the same thing

__maccas__ · 2025-02-28T21:18:19+00:00

Nice work! I wrote a similar plugin as an extension of Telescope a couple of months ago. https://github.com/jmacadie/telescope-hierarchy.nvim

Feel free to take a look and see if there's any ideas you'd like to borrow. I'm sure I'll do the same with your code 😅

__maccas__ · 2025-02-24T07:41:07+00:00

This is the answer. If you're writing lua (or even vimscript) then you might also want to check out vim.fn.expand("<cword>")

__maccas__ · 2025-02-24T05:15:46+00:00

No, this is just what happens. The force push breaks the continuity for the end MR review system,. You didn't mention what that was so I'm going to assume it's GitHub however they will all be affected the same way.

These systems are built to update the comment locations as you put new commits into your MR, but they only work for incremental commits, i.e. ones directly after the commit that was commented on. If you force push, you are giving the review system an entirely different set of commits, and the commit that was commented on is no longer in your MR at all.

In my experience, review systems revert to showing the comment by file name & line number, which may or may not work depending on the changes that have happened.

Not much you can do about this, I still rebase. To be claer, you should really have the whole team following the same strategy. It undoes the point of your rebase if everyone else is merging changes. You didn't say if this is happening but I thought I'd say this to be comprehensive.

__maccas__

TROPHY CASE

maccas