On 02/12/2019 17:25, Segher Boessenkool wrote: > On Mon, Dec 02, 2019 at 04:18:59PM +0000, Richard Earnshaw (lists) wrote: >> On 02/12/2019 15:35, Segher Boessenkool wrote: >>> On Mon, Dec 02, 2019 at 10:54:17AM +0000, Richard Earnshaw (lists) wrote: >>>> - author attributions are sometimes incorrect - reported >>> >>> This would disqualify that "conversion", for me at least. Keeping all >>> warts we had in SVN is better than adding new lies, lies about important >>> matters even. >> Indeed, but it's easy to turn off the option that tries to do this, if >> it can't be made to work correctly. We'd then be back with the existing >> 'author == committer' situation. > > But we need to be *sure* this is done correctly. The only safe thing > to do is to turn off all such options, if we cannot trust them.
Of course. But that's a decision that can be made quite late, because we know we *can* turn them off if we want to. > >>>> - certain key words in otherwise not very useful summary lines are >>>> also spotted and used to add [revert] or [backport] annotations to >>>> the summary. >>> >>> You won't see tags like that from anyone who uses the normal git commit >>> flows: the piece of the mail subject between [] is deleted. >> >> Well, true if you use "git am" without the -k or -b options; false >> otherwise. We have plenty of existing patches in the repo that have >> tags like this, though it doesn't appear to be the 'git way' I grant you. > > Yes, "the normal commit flows" :-) > Well my normal commit flow these days is to use -b, because that only removes "[PATCH...]" annotations. Nevertheless, we will most likely keep any existing "[...]" tags. >> We could extend the script to rewrite all [tag] attributions in tag: >> form, but I'm not really sure it's worth it. > > Sure; I'm just saying rewriting old commit messages in such a style that > they keep standing out from new ones is a bit of a weird choice. > One of the advantages of doing this in a script is that we have exactly three places in the script to change, and that's a trivial operation to do. Tweaking the logic overall is much harder as it can have surprising effects at times. >>>> No changes are made to the main commit log, if we add a new summary >>>> line, the entire original text is kept. >>> >>> That is good (an important requirement even). >> >> Yes, I even steer clear of trimming blank lines at the head or tail of >> the message, but it's possible that reposurgeon might do that itself later. > >> The real question at this point is whether or not these commit summaries >> are better than the existing ones. Personally, I think they are (or I >> wouldn't have spent the time working on this), but I'm not the only >> person with an interest here... > > Thanks for the effort, regardless of the outcome! > > > Segher > R.
