Re: Is it time to drop ChangeLogs?

[Eli Zaretskii]

> From: John Wiegley <address@hidden>
> Cc: Ingo Lohmar <address@hidden>,  address@hidden,  address@hidden
> Date: Tue, 08 Mar 2016 22:41:49 -0800
> 
> Keeping ChangeLog style in the commit entry is not terribly
> useful either, since the diff output of log -p lets you know which function or
> variable is being modified.

"git log -p" cannot do the job for changes in many types of files.
For example, try it on Lisp or Texinfo files.

More generally, there's no way Git could replace ChangeLog style
entries, because they frequently include information that is not in
the diffs.  To say nothing of the fact that understanding the change
from reading Diff hunks is much harder, and therefore much less
efficient, than from reading a log entry which describes the change in
plain English.

> I've never missed not having that ChangeLog data in other projects,
> of any size.

Maybe you rarely need to do any forensics.  Me, I do it all the time
in Emacs, and ChangeLog files are a valuable tool in the chest.

======================================================================

(Why is this topic cross-posted to bug-gnu-Emacs??)

> In my short experience, Change Logs has generally been useful both when
> reading and composing them.  When writing them it helps me structure
> large changes in logical commits that are modelled by the Change Log
> format.  Finally It helps me being precise in my wordings which is not
> trivial for non-native english speakers.
> 
> On a more spiritual side, I think they belong to the zen of contributing
> to a GNU project.  :)

I agree completely.  Writing a log entry in ChangeLog format is an
excellent opportunity for reflecting on the changeset, for summarizing
its intent and final shape, and for making sure nothing was left out.
Writing those entries teaches one discipline, the ability to describe
your changes in just enough detail, and facilitates communications
between members of the development team.  And in loose teams such as
ours, good communications are everything.

As told many times in past discussions, ChangeLog files are also an
excellent first tool for forensics, easy to search with many available
tools.  It is invaluable when you don't have access to the repository,
and a good asset even if you do: traversing the history of a complex
Git repo without losing commits on branches is not a trivial task, it
requires using non-default switches and some rarely used commands and
options.  Even when you do use Git tools, ChangeLog frequently
provides additional important evidence.

So removing ChangeLog files will be a bad blow to our ability to
easily and conveniently research the past, something that is extremely
important in a project with such a rich history, where it's all too
easy to reintroduce a bug if you don't look hard enough at the history
of some code fragment.

People are saying it's an extra barrier to contributing.  That is
true, but so is understanding the Emacs internals, code conventions,
organization of the documentation system, its auxiliary files (like
CONTRIBUTE, NEWS, DEBUG, PROBLEMS, etc.), the release process, and a
few more things.  Having to write ChangeLog entries is an
insignificant addition to the body of knowledge a contributor needs to
master, there's no way around that.  Nor should there be: without
knowing this stuff, you cannot be a useful contributor anyway, as your
contributions will need too much attention from the veterans, who then
will be unable to make more significant contributions due to lack of
time.  We need here contributors who know enough to work on their own
with minimal guidance, who can be trusted to do a good job that
doesn't need to be reviewed too deeply, whose design can be trusted to
be in line with the Emacsy way of doing things.  How can one raise to
this position without learning a lot of project-specific stuff?  You
can't.

Writing ChangeLog entries is just one small part of that.  It's no
accident that people who don't want ChangeLog files more often than
not don't want to write detailed commit log messages, either, and many
times don't know how to write good documentation.  Do we want to
dispense with these as well?  If we drop the ChangeLog files, there's
no way we can explain why we ask for commit log messages in ChangeLog
format, so the next logical step is to drop that as well, and we will
then lose valuable information.  We already are firmly on that path.

Other prominent GNU projects that maintain ChangeLog files in the
repository include GCC, Binutils, GDB, glibc, and Texinfo.  XEmacs
also has it.  Why should Emacs be the first one to plunge into this
adventure?  Why not let others try that first, and then we could learn
from their mistakes?

Let's reinstate the ChangeLog files.  Maintaining them is a negligible
cost; many other projects do that and don't have any trouble.  Unlike
what some people say, merge conflicts in ChangeLog files are very
rare, once you install git-merge-changelog.  We have some important
infrastructure based on ChangeLog files that will become extinct
without them, something that people tend to forget.  We tried to live
without these files for a year; that experiment failed miserably.
It's time to admit that, and fix the mistake we made.

======================================================================

> > On a more spiritual side, I think they belong to the zen of contributing
> > to a GNU project.  :)
> 
> Dear Goddess, I hope you're joking.

Actually, I'm sure he isn't.  Maybe you are.

> Speaking as a very, *very* long-time GNU contributor (I'm pretty sure
> my earliest Emacs patches predated the formation of the FSF), I
> consider ChangeLogs a relic of a bygone era.

You are entitled to your opinions; others are entitled to theirs.
IMO, active involvement in Emacs development during the recent years
brings more weight to an opinion about the current subject than
contributions made 30 years ago.

> Changelogs made some sense as a way of grouping together what we now
> call a changeset back in the days of file-oriented version-control
> systems.  Nowadays, set against the actual changeset comments in
> version-control histories, Changelogs are a pointless and duplicative
> ritual.

They are not duplications.  They are work-tree expressions of the VCS
log, exactly like any source file is the work-tree expression of the
VCS repo objects which hold that file's data.  You won't lobby for
removing the source files, and use the likes of "git show :foo.c"
instead, would you?  It should go without saying that having a file is
more convenient than having to regenerate it every time from the
repository.

And please note that many people who want to drop Changelogs also want
to drop the policy of making detailed commit log messages.  We are
experiencing the adverse effects of that for the past year.  If we
continue on that disastrous path, things will keep deteriorating, and
we will lose important information that cannot be restored.

> I think we should have dispensed with this practice during the CVS-to-bzr
> transition. As it is, the sooner gone the better.

You are a year late to the party, I think: we already did what you
describe.  We no longer maintain Changelogs directly, we produce them
from Git logs.  The result is problematic even when there's only one
active branch of development; when there are 2 branches, as we have
now, the result is an unimaginable mess, with _more_ merge conflicts
and more work to fix the fallout, not less.  I cannot even imagine
what will happen if we will ever want to start a 3rd branch.

>From this past year's experience, it is clear to me that having
ChangeLog files as we did before is a fraction of the price we had to
pay for removing them.  Removing them is also a serious impediment on
our way to more complex workflows, so it's actually a regression, not
progress.  It's high time we recognized the mistake and fixed it.

======================================================================

> I respect that Richard may use them in a constructive way, but he's no longer
> doing the majority of the work on Emacs

Neither are some of those who expressed their views here.  Unlike
Richard, those others cannot present a history of contributions and of
leading the development that is anywhere near what Richard has on his
record.

> I want to choose the path that works for the core developers, and
> will make Emacs more welcoming to new contributors.

It is IMO a grave mistake to remove parts of our development process
just because they need to be learned by new contributors.  The result
will be increased burden on the shoulders of those who review the
submissions, due to the need to coach them, catch their mistakes, ask
for re-submissions, etc.  It will eventually be a net loss, because
those contributors will not enjoy the need to produce several versions
of the patch before it is admitted, and the reviewers will not enjoy
the extra burden.

We should consider each part of the development process on its own
merit, first and foremost.  If a part is useful, and its removal will
make the quality of the code or the documentation lower, then it
should not be removed, and new contributors will have to learn it and
to live by it.

There's no useful way into Emacs development that doesn't require
negotiating a few barriers.  No free lunch here (or anywhere).  We
should recognize this fact instead of trying to bury our head in the
sand.

======================================================================

> > At this point, I give up, since it seems fairly clear that maintaining
>   > an accurate ChangeLog just isn't of interest. Even the bare minimum
>   > legally relevant mistakes (missing "tiny change") don't seem to be being
>   > corrected.
> 
> In concrete terms, what is the problem with these mistakes?

The mistakes are not being corrected.  Experience shows that
correcting them is enough of an annoyance to discourage people.

> Where is the master record of this information now?

In the Git commit messages.

> Is it being maintained correctly there?

When a mistake is made there, it cannot be corrected, because Git
commit log is immutable.  Corrections must be made manually to a
ChangeLog file produced from the Git log by a script.  That proved not
to work well, see above.  It also proved to be a non-trivial problem
when merging changes from the release branch to master -- for this
latter issue we still don't have any idea for how to solve it reliably
and without requiring a lot of manual labor.

>                Probably just deleting it from the repo would be more honest.
> 
> What exactly are you proposing as the new practice
> for handling ChangeLog files?

There are 3 possibilities:

  . Keep the current system, where ChangeLog is produced from Git log
    and mistakes made in Git log should be corrected manually after
    producing ChangeLog

  . Give up on having ChangeLog files, either produced from Git log or
    maintained in the repository -- meaning a tarball will not include
    any ChangeLog at all

  . Go back to previous practice where we maintained ChangeLog files
    in the repository, and Git log messages were just copies of the
    ChangeLog entries

======================================================================

> No, what we do currently is different: we auto-generate the ChangeLog
> and then commit it into the Git.  What I think we should do is to never
> commit it into the Git, and only auto-generate it into the tarball.
> Like what we do for GNU ELPA packages (where the log is extracted via
> "git log" when building the package and added to the package's content).
> 
> That makes "fixing" ChangeLog entries harder/impossible.  But it gets us
> rid of the merge-mess once and for all.

This would mean we don't care at all about what's in the ChangeLog.
You already said you didn't care, so it's not really surprising you'd
consider this as a viable option.  But for someone like me, who does
care, this is not really a solution at all.

======================================================================

> If we could switch to a system where every patch is reviewed before
> commit, that'd be great.  My own impression is that it will kill the
> development pace because too few people are willing to spend the
> corresponding efforts.

Agreed.  For my part, I can say that I simply don't have enough free
time to review more patches than I do (which is an abysmal little).

> That's why I've followed a practice of giving out write access very
> liberally, with "post-commit spot-check reviews" instead.  Indeed, it
> means that errors in commit messages can't be fixed (we can fix them in
> the ChangeLog files, admittedly, but since I don't use them it doesn't
> help me).

Post-commit reviews also take time.  Do you have an estimation of how
much time per day this takes?

> Maybe we could have a half-way system, where commits are pushed to
> a branch that is "not fast-forward-only", and this branch is then
> auto-merged to the real (fast-forward-only) master branch after a delay
> (one day, maybe?) to give time to fix mess ups before they're cast
> in stone.

A day is nowhere near enough.  IME, a bad commit pushed to master
takes up to a week to be discovered.

More generally, the problem with such a branch is that it won't be
much different from pushing to master, except in rare cases that it
breaks the build, and even that can only be avoided if we set up some
kind of CI system that continuously builds that branch on the main
supported platforms.

======================================================================

> On 03/07/2016 01:06 PM, Eli Zaretskii wrote:
> 
>         Maintaining ChangeLog files by hand with each commit makes it harder
>         to merge changes due to the inevitable collisions with ChangeLog
>         files.
> 
>     Incorrect!  And the current situation creates _more_ collisions, not
>     less!
>
> My own experience is otherwise. For the kinds of development I do, I rarely 
> see ChangeLog screwups now, whereas I used to see them routinely.

With or without git-merge-changelog?

If you have git-merge-changelog installed, what kind of screwups did
you see with ChangeLogs?  (I didn't see even one, in all the years I
use Git.)

>  I far prefer the current approach. Of course our approach can be improved 
> (in particular merging from emacs-25 to master doesn't work well now), but 
> let's not throw out the baby with the bathwater.

The current approach completely breaks down when more than one branch
is active.  So there's no baby in that bathwater.

>     We don't have to be better than the other prominent GNU projects.
> 
> I'd be happy if we were merely as good as the other prominent GNU projects 
> that generate ChangeLog entries automatically. As things stand, due to our 
> attempt to cater to all sides of this disagreement, we have an approach that 
> satisfies nobody.

Not sure what you mean here.  What alternatives that don't "cater to
all sides" would you suggest?  The only one I see is to stop producing
ChangeLog files for the releases.

>     ChangeLog mistakes can be easily fixed. 
> 
> That's true under both the old and the new regimes.

No, it isn't.  Definitely not with two branches.

>     Let other projects invent those schemes and test-drive them. Enough with 
> these experiments! 
> 
> I'd rather just do what coreutils, grep, tar, etc. use.

Don't know what hides behind "etc", but the rest are much smaller
projects, which are all in maintenance mode, and have a very small
number of active committers (of which you personally are a significant
fraction ;-).  They also don't use branches, at least not as much as
we do.  So I don't see how the experience of these projects is more
relevant to us than that of GCC, GDB, Binutils, and glibc.

> I could fairly easily change the master branch to do that.

To do what?  Please describe the details of your proposal.  Also,
please tell what do you suggest doing on the release branches.

> Even simpler would be to do what Guile does: it dispenses with ChangeLogs 
> entirely. With Guile if you want something like a ChangeLog you run "git log".

As I said, tossing ChangeLog files entirely would indeed solve the
problems, but it's a sure path to further deterioration in the quality
of log messages.  It is easy to keep the quality in a project that has
a small number of committers who are veteran GNU developers (Guile has
1 frequent committer on master, and 3 on stable).  That's not our
case.

> If neither of the above two approaches suffice, we can always fall back on my 
> previous email's proposal. It's not that experiemental, as it says to use the 
> new produre on master and the old procedure on emacs-25. The new procedure 
> works well enough within a single master branch.

Any suggested approach should support not only the current emacs-25
branch, but also the future release branches, i.e. it should continue
working when we cut the emacs-26 branch in the future.  It should also
be reliable, and not require manual labor for fixing mistakes in the
log messages, beyond the fix itself.

>     these procedures work, and all those projects are alive and kicking, and 
> actually make more frequent releases than we do. 
> 
> XEmacs is not really alive and kicking.

XEmacs is not that different from Grep or Sed.  Sed, for example, saw
just 30 commits during the last year.

> Projects like GCC and glibc have more resources than we do, and can afford to 
> insist on more-expert contributions that involve harder-to-generate patch 
> formats. We do not have that luxury.

It's the other way around, actually: the current situation requires
more labor from us to get it right, so our lack of resources should
lead us to the opposite conclusion.

>         I often ran into problems. Yes, git-merge-changelog should reduce the
>         number of merge conflicts, but it doesn't eliminate them
> 
>     Oh, yes, it does.
> 
> Not in my experience, or in Dmitry's. It's a fine program, but it sometimes 
> makes mistakes and they can be a pain to fix. 

Fixing its mistakes involves moving an entry to a different place,
that's all.  Easy done, and even if not done, it's not a disaster, as
the information is there anyway.

======================================================================

>         Maintaining ChangeLog files by hand with each commit makes it harder
>         to merge changes due to the inevitable collisions with ChangeLog
>         files.
> 
>     Incorrect!  And the current situation creates _more_ collisions, not
>     less!
> 
> Only when merging between branches.

It doesn't work very well even on a single branch.  With two branches,
it completely breaks down.

We do want to work on multiple branches, don't we?  We discussed how
to make more frequent releases, and perhaps have 3 branches for even
more flexible development and release schedule.  All of that would be
impossible because of this tiny but annoying PITA.  Do we really want
to continue wasting energy on fixing something that wasn't such a big
problem to begin with?

> Other than that, only a select group of people needs to bother: those who 
> make mistakes, and those who feel a general need to clean up.

See, that's the crux of the issue: do we or don't we care about the
need to clean up our ChangeLogs?  If we don't, then why bother
maintaining them?

You (and some others) say the format and the content in the log
messages are important, and I agree.  But if we do care about them,
how can we NOT clean them up?  Having them in their current state
means they cannot be trusted, which is worse than not having them at
all.

> As a relatively careful committer, I've only had to correct the entries a few 
> times, and I've been enjoying the lack of collisions quite a bit.

Yes, a few of us don't need any corrections.  But enough of us do, and
that's where the problem lies.  It is that problem that we need to
fix.  Leaving it unfixed makes your accurate work unreliable as well.

>     But ChangeLog mistakes can be easily fixed.
> 
> In the current approach, as well.

Only on a single branch, and even there this is not done enough.  We
all relied on Glenn to do that behind the scenes.  Now Glenn gave up
in despair, so things will degrade from now on.

>     We don't know how, and we don't have anyone who is motivated enough to
>     do that.  And even if and when we do have some solution, it is likely
>     to be inconvenient and unreliable.
> 
> I think we should wait and see until the work really transitions back to 
> master. The motivation must rise.

The release branch will remain active for quite some time: we have
just started a new major version.  And if we want more frequent
releases, we should strive to have an active release branch at all
times.  So I don't think we can wait; waiting will not solve anything,
it will just make the current problems bigger and harder to solve.

>     Let other projects invent those schemes and test-drive them.  Enough
>     with these experiments!  They draw the last drops of energy from us,
>     and they avert the few last veteran contributors we have left.
> 
> Has the current experiment really sucked too much energy from anyone, aside 
> from the implementors?

Why do you think Glenn gave up?

>     That's not a bad thing in itself.  The point is, these procedures
>     work, and all those projects are alive and kicking, and actually make
>     more frequent releases than we do.
> 
> For all we know, they might be thriving despite this practice.

Nothing wrong with that.

>         I often ran into problems. Yes, git-merge-changelog should reduce the
>         number of merge conflicts, but it doesn't eliminate them
> 
>     Oh, yes, it does.
> 
> Not in my experience either. I've still had collisions, and even when 
> git-merge-changelog resolved them, it often put my entry in the middle of the 
> file, whereas I usually needed it to be at the top. Leading to extra manual 
> labor.

That extra manual labor is very small, and it's still a rare case to
have that.  A small price to pay for a clean and reliable solution.

>         requiring git-merge-changelog means that many contributors would
>         have to worry about installing and configuring git-merge-changelog,
>         which would be more of a hassle for recruiting contributors.
> 
>     It's a 5-sec configuration, let's not make a mountain out of a
>     molehill.
> 
> It was longer for me. But either way, it's more hassle for a random 
> contributor than the current system.

The current system is much more hassle for non-random contributors, so
much so that we risk losing them, something we cannot afford.

> If it can be fixed, Someone should.

Let that Someone step forward, then, and speak up.  We have been
waiting for that for the past year, so I'm not holding my breath now.

======================================================================

> >> Introduce code reviews. Don't give commit access to the "golden"
> >> branches to everyone, just to a few top contributors and reviewers.
> >
> > We don't have manpower for that.
> 
> I find perplexing that we have manpower for reviewing ChangeLogs but not
> for reviewing commit logs *instead*.

Log messages are much shorter than code diffs, and much simpler to
read and understand.  It takes a few seconds to read them; reading a
code patch takes much more, typically needs to consult the surrounding
and related code, etc.  So code review takes orders of magnitude more
time than reviewing the corresponding log entries.

> And is it so super-important to have typo-free commit logs?

Typos is the least of our problems.  But yes, it's important: if you
start by forgiving typos, you end with unhelpful and uninformative log
messages.

> We are not even using `git notes'.

No one came up with a detailed procedure for doing that.  If you can
propose something that works, please do.

======================================================================

> >> Another option for correcting errors on commit logs is `git notes', but
> >> I don't know about its implications.
> >
> > Nobody does.  We shouldn't consider any more experiments in this area
> > until someone else uses these methods and proves they are viable in
> > our case.
> 
> How could *someone else* prove the viability of something in *our* case?

By coming up with a procedure which we can study and decide whether
it fits us.

> You always can argue that his project is not Emacs...

I can, but why would I want to?  The opinions are not pre-determined,
they are based on study and in this case also on a year-long
experience of actually using a procedure.

> `git notes' is a documented feature available since a long time ago. It
> can turn the immutability of the commit log into a non-issue if you wish
> to produce a proofread ChangeLog to include in the tarball.

We need a more detailed proposal than this, TIA.  David says "git
notes" is not a solution; if notes don't support merging, then I tend
to think he is right.

======================================================================

> > The reasons exist, and has been described.  You may not agree with
> > them, perhaps due to different experience, but that doesn't mean they
> > aren't valid.
> 
> Yeah, but what exactly is your point here? I was pointing out that this
> practice is astonishing for new contributors. You didn't understand why,
> so I explained that it's astonishing because to a new contributor it
> seems pointless. Now you assert that there are good reasons for it, but
> that really doesn't change that, to new contributors, it appears
> pointless and is astonishing.

My point is that the initial surprise will subside with time, by way
of getting used to it.  It is even possible that you will come to
value this, as someone else who reported here.

> Sorry, I still don't follow your reasoning. I still consider myself a
> potential contributor (I didn't contribute much beyond that first little
> foray), and not requiring me to copy my commit message into the
> ChangeLog is not going to affect the quality of the commit measures in
> any way. The only "message" that I get from this is "Great, sending
> patches for Emacs doesn't require me to do a copy & paste anymore".

As long as you don't have write access to the repository, you are not
required to provide the log entries more than once, and so this issue
doesn't really affect you.  This issue is only relevant to those who
actually push changes, because they might need to copy/paste into the
ChangeLog file.

======================================================================

> > I think if we care at all about having ChangeLog in the releases, we
> > should simply reinstate the file and maintain it in the repository.
> 
> FWIW, that's not what I was hoping would come from this, and I think
> that would be a retrograde step.

Can you tell why?  It solves all the problems you mention in your
mail, at negligible costs.  So it seems to be a clear winner.

> For 1) and 2), experience shows that few people will bother to make
> corrections.

Is it an important drawback that few people bother to make
corrections?  If it is, then any solution that involves such
corrections is not what we want.

Also, is the situation with corrections worse or better than what it
was when we maintained ChangeLog files in the repository?

> PS For the record, to explain the actual merging issue as I see it:
> 
> Suppose emacs-25 and master are synced at revision aaa and ChangeLog.2
> is up-to-date. emacs-25 advances to rev xxx, and independently master to
> rev xxx'. emacs-25 gets ChangeLog.2 updated, and merged to master. Now
> the footer of master ChangeLog.2 reports that it is up-to-date to rev
> xxx. What does this mean for the changes on master between aaa and xxx'?
> Because xxx on master is "after" xxx', I suspect it means they end up
> missing from ChangeLog.2 forever, which is bad.

No, they don't end up missing.  They will in general be in the "wrong"
order, time-wise, though.  But what is the "right" order for this
situation, where changes are made in parallel on several branches?  Do
we want them interwoven, in strict order of their commit times?  Or do
we want all the entries of a merge from the branch be kept together
with the time stamp of the merge?  If we want to continue keeping a
single generated ChangeLog file on master and on the branch, we need
to decide what is the desired result.

> But maybe there's no such issue, or it is fixable with some git
> trivia.

The only "git trivia" that's possible is a custom merge driver (which
AFAIK doesn't exist).  Git itself is not aware of the special meaning
of the time stamps in ChangeLog entries.

We could also have some Lisp rearranging the entries in whatever order
we decide we want it, after git-merge-changelog puts them in the order
it thinks is right.

> I don't know. That's why I made this bug report. AFAICS, the adopted
> "solution" was simply to ignore the issue, which means
> master/ChangeLog.2 is (probably) messed up at the moment.

It is not messed, but it isn't in chronological order, either.  And it
looks like no one ran "make change-history" on master for several
moons, so problems might become worse when they do.

======================================================================

> Giving people different permissions on different branches seems to make
> sense. Overtime, people move toward master/emacs-25.

AFAIK, Git (or is it Savannah?) doesn't support such granularity.

> > Maybe we could have a half-way system, where commits are pushed to
> > a branch that is "not fast-forward-only", and this branch is then
> > auto-merged to the real (fast-forward-only) master branch after a delay
> > (one day, maybe?) to give time to fix mess ups before they're cast
> > in stone.
> 
> I think that this would require some considerable co-ordination. If I
> push a broken commit to devel branch, and then you fix this commit
> through rebase, my copy of the branch (and everyone elses) is now
> broken.

Stefan was talking about merging, not rebasing.

======================================================================

> > Find a better and more reliable way of dealing with the problems described
> > here, and I'll be the first to agree not to reintroduce ChangeLogs.
> 
> As far as I understand so far, we have only a few needs. If I've understood
> incorrectly, please let me know, as this thread has wandered in a few places.
> 
>  1. We need a way to ensure quality commit messages from contributors.
>  2. We'd like to be able to correct commit messages after the fact.
>  3. We need a convenient way to both create and access this information.
>  4. We want to publish the history of these commit messages in the tarball.
> 
> The ChangeLog file and its format are one implementation of these needs that
> has worked over the years. Are you saying that if we move to something else,
> and it fulfills these criteria, you'd be just as happy with it?

Yes.

However, putting on my system engineer hat, let me make sure the list
of requirements covers all the aspects:

 5. The "history of commit messages" produced in 4 above should
    resemble a ChangeLog file (ideally, it should use the same
    format).
 6. The solution should allow manual generation of the "history" file
    mentioned in 4, on demand, in reasonably short time, even if the
    repo clone does not include a built Emacs.  (It is okay to use the
    installed Emacs binary, if necessary.)
 7. The solution should support Git workflows we allow: merging
    between branches, rebasing local changes on upstream,
    cherry-picking from another branch, reverting a commit, tagging a
    commit, and amending an unpushed commit.  "Support" here means
    that the solution should not impose limitations on these
    workflows, and the steps for updating whatever databases the
    solution will use should not require additional manual work as
    result of using these workflows.

(I'm not saying these additions are something non-obvious, I just
want to make sure we have everything covered.)