Re: Unreleased fixes in master

[Dima K. <gn...@di...>]

Ethan A Merritt <sf...@us...> writes:

> That's not the development model we have been using.
>
> Trivial bug-fixes are applied for both the stable and development branches
> immediately as they are found.
>
> Non-trivial changes, even bug fixes, are applied only to the
> development branch. Often people using the development branch then
> report related issues that require additional fixes or re-thinking of
> the original fix. After sufficient testing in the development version
> the original fix and any follow-ups developed during testing may or
> may not be back-ported to the stable branch. This particular change
> was non-trivial to begin with and engendered many follow-up fixes.

OK. Is your thinking to include this in a 5.4 release at some point in
the future?


>> I can ask git about the difference in branches (git log
>> 5.2.6..master), but they're very diverged, and that command isn't
>> entirely helpful.
>
> Tracking changes via commit messages is one of the things I like least
> about git. I am seriously considering to switch back to a model where
> changes are fully described in a separate ChangeLog and all git
> commits simply say "see ChangeLog". That would require some automated
> way to insert the appropriate git hash indices into the text of the
> ChangeLog. I have tried a couple of git add-ons that looked like they
> might help, but so far with no success.

OK. I use git heavily, but never to do anything with lots of branching,
so I wasn't sure what you're doing. Things like "git master..feature"
(i.e. tell me what's on the feature branch that isn't on the master
branch) is exactly the thing that git is supposed to do well, so I
suspect we're doing something incorrectly here.

The reason that 'git log master..5.2.6' wasn't entirely useful is that
there was way too much noise. And THAT happened because there were many
commits that appear in both master and 5.2.6, but that the above command
isn't recognizing as being on both:

  dima@scrawny:~/projects/gnuplot$ comm -12 <(git log master..5.2.6 --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) <(git log 5.2.6..master --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) | wc -l
  224

  dima@scrawny:~/projects/gnuplot$ comm -23 <(git log master..5.2.6 --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) <(git log 5.2.6..master --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) | wc -l
  156

  dima@scrawny:~/projects/gnuplot$ comm -13 <(git log master..5.2.6 --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) <(git log 5.2.6..master --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) | wc -l
  635

i.e. there were 224 commits that appear in both master..5.2.6 AND in
5.2.6..master. Taking a random one. Look at this:

  gitk 1f7160945 fb107d74e

These are clearly the same commit, so ideally it should appear on
neither "git log master..5.2.6" nor "git log 5.2.6..master", but it
appears on both. Those commits aren't in a merge, and their immediate
parents aren't the same. How did we get here? Did we cherry-pick it?
Maybe that confuses "git log" a bit?


> The thing is, you can't go back to edit old commit messages like you
> can edit a ChangeLog. That means you cannot fix typos, cannot clarify
> or expand bad descriptions, cannot update or redact Email addresses,
> cannot forward-link to eventual reversion or to subsequent related
> patches etc.
>
> My #1 suggestion for improving git would be to move all the commit
> messages to a parallel data structure so that they can be edited
> without invalidating the orginal commit hash.

Are you really proposing to have a hand-curated NEWS file AND a
hand-curated ChangeLog AND version control?