Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Achim Gratz <address@hidden> writes:

> Bastien writes:
>> How would we handle fixing in such generated logs?
>
> The same way we do today if we only care about the Changelog file.

We don't do "it" today.

Org ChangeLogs are generated using a script, and these changelogs are
added to Emacs when we merge Org.  It's fine fixing these changelogs
manually because newly generated Changelogs don't overwrite previous
ones.

My question is: if Emacs generates Changelogs from commit messages,
and if commit messages contain ill-formated changelogs, how do you
fix generated changelogs?

One idea is to generate only new changes (and fix them manually if
needed), not to generate all ChangeLogs.

> Otherwise, we'd have to come up with something using Git notes (as
> already mentioned earlier in this thread).
>
>> By revising the git history through rebasing?
>
> Nope.
>
>> Not a rhetorical question, just curious, as I do have a
>> problem with the current way Org generates its ChangeLogs.
>
> For the benefit of other participants in this discussion you might
> mention that Org doesn't have a ChangeLog

I did: http://article.gmane.org/gmane.emacs.devel/167136

> and the only reason we
> generate one is that when changes are imported into Emacs there is
> suddenly a need to document that merge (typically produced by ~1000
> commits from Org) in Emacs' ChangeLog.  Since that operation throws away
> all history from Org, it also means you can't use the commit messages
> directly for the ChangeLog, no matter how hard you'd wish you could.

It's a matter of convention: if Emacs generates Changelog files from
commit messages, I guess we will enforce some policy on how to write
suitable commit messages.

Additional (not suitable for ChangeLogs) information could then be
stored in git notes.

> That wouldn't necessarily be a problem in Emacs' case where the
> correspondence between commit and ChangeLog would be 1:1.

Yes.

-- 
 Bastien