I have an alias[1] for that which I call a quick interactive rebase:

    riq = -c sequence.editor=: rebase --interactive

> Only write comments to explain the why when it is not obvious from the code (rationale, gotchas, constraints). Do not comment on the what — well-named code already says it. Do not comment on how a framework works.

It still keeps adding these bad comments. When I then ask it to review the comments based on my preferences it then deletes most of them or improves them.

Today I asked Claude why it disrespects my preference and it said that the surrounding code was like that and it followed that style. It suggested I add this line to my global CLAUDE.md file:

> The comment rule above beats the style of the surrounding code: neighboring files with what-style comments are not license to write more of them, and comments carried along when porting or copying code must be re-judged against the rule, not kept for consistency.

Let's see if that improves things.

[1]: https://git-scm.com/docs/git-worktree

I open such a page and I immediately know it was Claude that produced it (probably end-to-end). Not that there's anything wrong with that, but it lacks soul… and that makes me kind of sad.

Personally, I always end up tweaking something the agent produced. I wonder if I should let go of that control...

The point is that I want to use Git, a tool and skill that is portable to other platforms.

    git --config push.default=matching push --force-with-lease --force-if-includes

My biggest gripe with GitHub when working with stacks – and something that's not clarified in these docs – is whether fast-forward merges are possible. Its "Merge with rebase" button always rewrites the commit. They do mention that the stack needs to be rebased in order to merge it. My workaround has been `git merge --ff-only top-branch-of-stack` to merge the entire stack locally into main (or anything in between actually) and then push. GitHub neatly recognizes that each PR in the stack is now in main and marks them all as merged. If there are subsequent PRs that weren't merged it updates the base branch.

Having said that, it's great to see GitHub getting a proper UI for this. It's also great that it understands the intent that branch B that goes on top of branch A is a stack and thus CI runs against. I just hope that it's not mandatory to use their CLI in order to create stacks. They do cover this briefly in the FAQ[3], but it might be necessary to use `gh stack init --adopt branch-a branch-b branch-c`. On the other hand, if that removes the need to manually create the N PRs for my stack, that's nice.

[1]: https://git-scm.com/docs/git-rebase#Documentation/git-rebase...

[2]: https://github.com/tummychow/git-absorb

[3]: https://github.github.com/gh-stack/faq/#will-this-work-with-...

* It ensures the default branch is not deleted (main, master)

* It does not touch the current branch

* It does not touch the branch in a different worktree[2]

* It also works with non-merge repos by deleting the local branches that are gone on the remote

    git branch --merged "$(git config init.defaultBranch)" \
    | grep -Fv "$(git config init.defaultBranch)" \
    | grep -vF '*' \
    | grep -vF '+' \
    | xargs git branch -d \
    && git fetch \
    && git remote prune origin \
    && git branch -v \
    | grep -F '[gone]' \
    | grep -vF '*' \
    | grep -vF '+' \
    | awk '{print $1}' \
    | xargs git branch -D

[2]: https://git-scm.com/docs/git-worktree

Comments URL: https://news.ycombinator.com/item?id=46643538

Points: 1

# Comments: 1

Note that you can skip hooks by passing the --no-verify flag to subcommands. Comes in handy when they're slow and you know that you've just fixed the wrong formatting that the previous invocation of your pre-commit hook complained about.

I'm using Finicky[1] on Mac to rewrite the URL by extracting the original URL from the query params[2].

1: https://github.com/johnste/finicky

2: https://github.com/fphilipe/dotfiles/blob/31e3d18fe5f51b2fd8...

Comments URL: https://news.ycombinator.com/item?id=42650300

Points: 2

# Comments: 0

> Using commit log diffs as changelogs is a bad idea: they're full of noise. Things like merge commits, commits with obscure titles, documentation changes, etc.

> The purpose of a commit is to document a step in the evolution of the source code. Some projects clean up commits, some don't.

> The purpose of a changelog entry is to document the noteworthy difference, often across multiple commits, to communicate them clearly to end users.

Did hit the front page a few times with some of my posts:

- http://phili.pe/posts/postgresql-on-the-command-line/ - 4th on https://news.ycombinator.com/front?day=2015-10-27

- https://phili.pe/posts/timestamps-and-time-zones-in-postgres... - 7th on https://news.ycombinator.com/front?day=2019-03-31

- https://phili.pe/posts/using-grep-for-simple-ci-tasks/ - 29th on https://news.ycombinator.com/front?day=2022-01-14

Comments URL: https://news.ycombinator.com/item?id=34531281

Points: 3

# Comments: 1