: The thing about commit messages is they can't easily be cleaned up after
: they are pushed... mistakes there are permanent.
Exactly.
In particular, a feature might be collaboratively developed & committed by
Alice & Bob; but then before it's ever released Carl might find a bug with
the
The thing about commit messages is they can't easily be cleaned up after
they are pushed... mistakes there are permanent.
On Fri, May 17, 2024 at 9:47 AM Alessandro Benedetti
wrote:
> I feel the same.
> It's error-prone, easy to forget and even easier to end up with conflicts.
>
> Sure, once
I feel the same.
It's error-prone, easy to forget and even easier to end up with conflicts.
Sure, once there, it's useful and I end up reading it from time to time, to
quickly refresh on the latest contributions I (or my team) did (but the git
log is more than enough for that).
In the end,
I *do* find our current situation the worst of all possible options!
> On May 16, 2024, at 2:51 PM, David Smiley wrote:
>
> Managing CHANGES.txt in each PR/change we do is a pain. It's so
> merge-conflict prone. I don't mean to call for the removal of
> CHANGES.txt (although I've wished for
Managing CHANGES.txt in each PR/change we do is a pain. It's so
merge-conflict prone. I don't mean to call for the removal of
CHANGES.txt (although I've wished for this off-and-on), but want to
solicit inputs on what can be done to make this easier.
I could be mistaken but maybe it was Calvin
