fphilipe
Joined 16 years ago
Karma
1,088
Submissions
190
Member since
Nov 8
Recent submissions
Comment · 1 month ago
I have this rule in my global AGENTS.md:
> When writing a commit message, briefly explain at a high level what was done (the details are in the code). Explain the why of the commit; if you don't know that, ask me.
It works quite well. When it doesn't have it in context, it does ask.
Comment · 1 month ago
ln -s AGENTS.md CLAUDE.mdComment · 3 months ago
I was using my usual stacked PR approach without the CLI and it detected the stack. So I think the CLI just does the heavy lifting for you (although I prefer to stick to vanilla git rather than learning a new tool).
Comment · 3 months ago
I use the colon as EDITOR with Git when I want to do an interactive rebase combined with auto squash without having to edit the todo list.
I have an alias[1] for that which I call a quick interactive rebase:
riq = -c sequence.editor=: rebase --interactive
Comment · 3 months ago
This is what has been frustrating me most lately. Even though I have a rule in my global CLAUDE.md that says:
> 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.
Comment · 5 months ago
At that point you might as well use a worktree[1].
Comment · 5 months ago
These pages do look good. But they all just look the same. And I'm getting bored of them.
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.
Comment · 5 months ago
I wonder the same. The answer I usually get from people who do manage is that they don't look at the code – or at least not in detail.
Personally, I always end up tweaking something the agent produced. I wonder if I should let go of that control...
Comment · 5 months ago
It features the current date and time with seconds, so it must be rendered on the fly.
Comment · 6 months ago
Sure, that's possible. I can also use the GitHub app and use a Git abstraction where I don't have to understand Git at all.
The point is that I want to use Git, a tool and skill that is portable to other platforms.
Comment · 6 months ago
My git config for pushing is set to push.default=current. For rebased stacks I have an alias that does this:
git --config push.default=matching push --force-with-lease --force-if-includes
Comment · 6 months ago
I've been doing stacked PRs for ~2 years now. Thus, I don't quite see the need for this CLI. Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of.
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-...
Comment · 8 months ago
I have a global setting for that. Whenever I work in a repo that deviates from that I override it locally. I have a few other aliases that rely on the default branch, such as “switch to the default branch”. So I usually notice it quite quickly when the value is off in a particular repo.
Comment · 8 months ago
Here's my take on the one-liner that I use via a `git tidy` alias[1]. A few points:
* 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
https://github.com/fphilipe
[ my public key: https://keybase.io/philipe; my proof: https://keybase.io/philipe/sigs/182uf1x4SUnMvtmLchInbgTL0X0b0qcRGe_g2T0KLDo ]