Dangling footnote. I decided against adding one and forgot to remove it.

Programs to manage “stacks of patches” go back decades. That might be hundreds that have accumulated over years which are all rebased on the upstream repository. The upstream repository might be someone you barely know, or someone you haven’t managed to get a response from. But you have your changes in your fork and you need to maintain it yourself until upstream accepts it (if they ever call back).

I’m pretty sure that the Git For Windows project is managed as patches on top of Git. And I’ve seen the maintainer post patches to the Git mailing list saying something like, okay we’ve been using this for months now and I think it’s time that it is incorporated in Git.[1]

I’ve seen patches posted to the Git mailing list where they talk about how this new thing (like a command) was originally developed by someone on GitHub (say) but now someone on GitLab (say) took it over and wants to upstream it. Maybe years after it was started.

Almost all changes to the Git project need to incubate for a week in an integration branch called `next` before it is merged to `master`.[1] Beyond slow testing for Git project itself, this means that downstream projects can use `next` in their automated testing to catch regressions before they hit `master`.

† 1: Which is kind of a like a “megamerge”

My mind was a little blown when I read about the megamerge strategy in Steve Klabnik's tutorial.[1]

Yes, Jujutsu's approach of autorebasing changes is very nice. Now all I have to do is to try it myself.

† 1: https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...

IMO `git merge --squash` was perhaps a cultural mistake. Few people use that command but the apparent cultural impact seems to have been great (if that was where it came from).

GitHub squash is a bullet list of all the commit messages. That’s just inviting a ball of mud changelist[1]. But because of the all too convenient "squash" shorthand we now have to explain every time: Yes, there is a middle ground between having one monolithic commit and keeping every little trivial checkpoint and correction.

[1]: The change: the diff. The list: try to correlate each bullet point with something in the diff. (In cases where that applies, some things will have been done and undone and won’t show up in the diff.)

I would rather deal with nice and tidy but untested commits rather than a very well-tested but too monolithic squash. If you test the eventual merge then you have done no less testing than the squash case.

Old commits are read more than they are run.

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

Points: 1

# Comments: 0

I'll take that bet.

[^1] https://news.ycombinator.com/item?id=44348438

    I did  and found no other places in the code base where this needs to be fixed.

And also like a commit message on the iterations on the patches. So for a patch series that go over three versions the note may say what updates where done in versions 2 and 3.

And other than that I use notes for:

- Private notes on how I’ve manually tested the commit

- Link to CI

- A localized changelog for customers (who are not technical)

I also tried to make a minimal reproduction but wasn’t able to.

- The real unit of change lives in Git

- The real unit of change lives on some forge

I want it to live in Git.