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.
> 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.
...or you don't bother with all that and simply do:
Not at all. One of the tricks of using AI is context management and managing the Git history yourself can be a big part of that. If the AI has a stupid idea and implements it, even when you tell it, “that was a stupid idea, don’t do that, change it back”, the history could persist and the stupid idea will poison the context window every time an agent reads the commit history. It’s even worse if you had the stupid idea!
Also, my current workflow actually has hooks to block agents from creating or changing commits. I know at some point this will be a limit to scaling, but I think that will result in me spending more rather than less time in git.
The use of init.defaultBranch here is really problematic, because different repositories may use a different name for their default, and this is a global (your home directory scope) setting you have to pre-set.
I have an alias I use called git default which works like this:
default = !git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'
then it becomes
..."$(git default)"...
This figures out the actual default from the origin.
I work at a company that was born and grew during the master->main transition. As a result, we have a 50/50 split of main and master.
No matter what you think about the reason for the transition, any reasonable person must admit that this was a stupid, user hostile, and needlessly complexifying change.
I am a trainer at my company. I literally teach git. And: I have no words.
Every time I decide to NOT explain to a new engineer why it's that way and say, "just learn that some are master, newer ones are main, there's no way to be sure" a little piece of me dies inside.
No, actually, zero people 'must admit' that it was a stupid, user hostile and needlessly complexifying change.
I would say any reasonable person would have to agree that a company which didn't bother to set a standard for new repos once there are multiple common options is stupid, user hostile and needlessly complexifying. And if the company does have a standard for new repos, but for some reason you don't explain that to new engineers....
There was only a single standard before, so there was no reason why a company should make any company specific standard. The need for companies to make a standard only exists, since the master to main change, because now there are two standards.
Except git init still creates branches named master without configuration (although with a warning), which will only change in 3.0 for obvious reasons, and tons of people (including me) still use master, and old projects don't just vanish.
Why does your company not migrate to one standard? Github has this functionality built in, and it's also easy enough to do with just git.
I'm personally a huge fan of the master-> main changejus5t because main is shorter to type. Might be a small win, but I checkout projects' main branches a lot.
It's extremely obvious that "main" is more ergonomic. It's sad that we're so resistant to change (regardless of how valid you think the initial trigger was)
I love the arguments where you tell me what I “must admit”.
I simply don’t, therefore your entire point is meaningless.
I’m sorry that something so inconsequential irked you so much. Maybe you need to read a book about git if this stumped you bad enough to want to voice your upset about it years later?
I’d consider yourself lucky that everything else is going so well that this is what’s occupying you.
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.
I'm of the opinion that Git hooks are personal. That's why they're not part of the source code itself. I make extensive use of hooks, but they're tailored to my needs.
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.
Nice, I use finicky as well, but now and again I have to change a rule or even add a new one. pisses me right off. Anyway thank you for sharing your dotfiles.
> 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.
> they're full of noise. Things like merge commits
From another angle, merge commits can also be a solution to the problem. `git merge --no-ff --edit` can be a great way to summarize an entire branch of commits. Most PR tools will give you an easy way to create those kind of merge commits. Don't settle for the default "merge branch x into y", create a meaningful title and fill in details/summary of what happened in the branch. With traversal tools like git log --first-parent you can see a high level of just your merge commits with the gnarly details of whatever steps led up to the merge commit itself.
I've certainly seen good projects where `git log --first-parent` was always a useful first pass changelog (no matter how "clean" the rest of commits were or were not). Probably still not a changelog you should send as a document to end users (because still written from a development standpoint rather than a user standpoint), but a good place to start writing the end user documentation.
Me too, but some tools combine the best of both worlds. In my team we use commitizen [1] which drinks both from keepachangelog and conventional commits and we are quite pleased with our changelogs so far.
> Facebook aside you really see this across the board on almost any platform, that once the product reaches it's 1.0 stage, (where it is good, does what the users want it to do, and has realised its vision) it begins a process of gradual decay, as the focus of the product managers (now panicking to find some statistics to improve to show their bosses) shifts from "building functionality" to "increasing engagement/retention/active users per month".
Best example for me: Revolut. The app and product as a whole was so simple and good.
One year ago (or maybe 1.5 years ago) it started going downhill, fast. The app got so complicated that I often simply cannot find what I'm looking for (my card or the balance in a specific currency). Everyone I know using Revolut has the same complaint, especially older people like my parents or in-laws.
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-...