Re: Status update - version 5.2.2, cvs->git conversion, plans

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

Daniel J Sebald <dan...@ie...> writes:

> On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote:
>
> Keep the same format for the git log messages as you've been using for
> the ChangeLog, i.e.,
>
> -> One line of "short-log"
> -> List of files that have changed, just like CVS ChangeLog entries
>
> <snip>
>
> 1) Ask the people submitting patches, via their git tools to include the
> file change info in their log messages

Please, let's not do that. Version control already has this information,
and asking humans to replicate it is both effortfull and error-prone.
Does 'git log --stat' give you what you want?


> 2) Code submitters will generate their changeset and extract it into a
> patch file, changeset header and all.

Can we use 'git format'?


> 3) One option is to apply that patch to your local repository and test.
> If you feel the patch is good, then push to the canonical version.  If
> it isn't quite ready, you'll have to learn how to reset your local copy
> (i.e., toss out the applied changeset).
>
> 4) Say you aren't quite happy with the code in the changeset, but it is
> close or you want to clean up the person's changeset log message.  One
> option is to edit the changeset/patch file directly.  Sometimes
> convenient, but sometimes not if it is a complex change.

Many potential workflows here. You can ask the submitter to resolve the
issues and to resubmit the patch. Or you can apply the patch as is ('git
am' would import the patch and all the metadata from a 'git format'-ted
patch), make changes, and then do something like 'git commit --amend -C
HEAD'. If we care, git allows you to separate the author and committer.