Menu
▾
▴
clisp-devel
|
From: Sam S. <sd...@gn...> - 2017-02-22 20:11:10
|
Hi, ChangeLog is obsolete. Even Emacs does not use it anymore. While I see obvious benefits, for me the main drawback is that it dramatically increases the probability of conflicts. If I make a local commit and do not push it right away, it is almost certain that I will have to go through either merge or strip/recommit because rebase will definitely fail. WDYT? -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://www.dhimmitude.org https://jihadwatch.org http://jij.org http://iris.org.il http://memri.org There are two ways to write error-free programs; only the third one works. |
|
From: Pascal B. <pj...@in...> - 2017-02-22 22:51:42
|
> On 22 Feb 2017, at 21:11, Sam Steingold <sd...@gn...> wrote: > > Hi, > > ChangeLog is obsolete. Even Emacs does not use it anymore. > > While I see obvious benefits, for me the main drawback is that it > dramatically increases the probability of conflicts. > If I make a local commit and do not push it right away, it is almost > certain that I will have to go through either merge or strip/recommit > because rebase will definitely fail. > > WDYT? There would be the option of generating it automatically from git log when making the tarball, but then git logs are usually much more detailed than a high level ChangeLog. Probably, people interested in the history can always checkout from the repository instead of using tarballs. -- __Pascal J. Bourguignon__ |
|
From: Bruno H. <br...@cl...> - 2017-02-23 00:15:41
|
Hi Sam,
> ChangeLog is obsolete. Even Emacs does not use it anymore.
Different groups of developers make different choices.
> While I see obvious benefits
The not so obvious benefits are:
- We can really keep track of the history over long periods of time.
Whereas when we rely on a VCS, we lose info at each move to a different
location. (Like the gmane.org article URLs became obsolete six months ago.)
In the recent move of libffcall from cvs to git we did not lose info,
but it cost me two days of work to achieve this result.
- You get educated to review your changes before committing them.
- You can access a ChangeLog without any tools, just with a text editor.
> for me the main drawback is that it
> dramatically increases the probability of conflicts.
1) There is a tool for automatically resolving these conflicts:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
You find the installation instructions at lines 42..48, 77..88 of this file.
2) Even without it, yes there would be conflicts, but they are easy to resolve,
since you remember what you have added. Conflicts are only difficult to resolve
if you don't remember what were your changes versus what were the other person's
changes.
> If I make a local commit and do not push it right away, it is almost
> certain that I will have to go through either merge or strip/recommit
> because rebase will definitely fail.
It is not the intent of ChangeLog that you feel the need to push
immediately. Just keep the same patience as before.
In all projects I work in (from gnulib to libffcall), I find ChangeLogs useful.
In projects without ChangeLog (e.g. XFree86), I found it hard to work.
I admit that in projects with many branches and merges (like the github workflow)
ChangeLogs are not appropriate. But clisp is not in this situation.
Bruno
|
|
From: Daniel J. <dan...@gm...> - 2017-02-23 08:44:28
|
Hi, I think a changelog is a very useful thing to have, but I always felt that the one of CLISP is by far too detailed. Perhaps this [1] could give an inspiration how to keep a changelog that only contains "important" changes. The "full detailed list of changes" would then be maintained through commit messages. Best, Daniel (Yes I'm still here, though only reading. Long story short, I'm basically ill since last October and thus have barely time for anything) [1] http://keepachangelog.com/en/0.3.0/ Bruno Haible <br...@cl...> schrieb am Do., 23. Feb. 2017, 01:16: > Hi Sam, > > > ChangeLog is obsolete. Even Emacs does not use it anymore. > > Different groups of developers make different choices. > > > While I see obvious benefits > > The not so obvious benefits are: > > - We can really keep track of the history over long periods of time. > Whereas when we rely on a VCS, we lose info at each move to a different > location. (Like the gmane.org article URLs became obsolete six months > ago.) > In the recent move of libffcall from cvs to git we did not lose info, > but it cost me two days of work to achieve this result. > > - You get educated to review your changes before committing them. > > - You can access a ChangeLog without any tools, just with a text editor. > > > for me the main drawback is that it > > dramatically increases the probability of conflicts. > > 1) There is a tool for automatically resolving these conflicts: > > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c > You find the installation instructions at lines 42..48, 77..88 of this > file. > > 2) Even without it, yes there would be conflicts, but they are easy to > resolve, > since you remember what you have added. Conflicts are only difficult to > resolve > if you don't remember what were your changes versus what were the other > person's > changes. > > > If I make a local commit and do not push it right away, it is almost > > certain that I will have to go through either merge or strip/recommit > > because rebase will definitely fail. > > It is not the intent of ChangeLog that you feel the need to push > immediately. Just keep the same patience as before. > > In all projects I work in (from gnulib to libffcall), I find ChangeLogs > useful. > In projects without ChangeLog (e.g. XFree86), I found it hard to work. > > I admit that in projects with many branches and merges (like the github > workflow) > ChangeLogs are not appropriate. But clisp is not in this situation. > > Bruno > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > clisp-devel mailing list > cli...@li... > https://lists.sourceforge.net/lists/listinfo/clisp-devel > |
|
From: Bruno H. <br...@cl...> - 2017-02-23 13:10:05
|
Hi Daniel, > I think a changelog is a very useful thing to have, but I always felt that > the one of CLISP is by far too detailed. > > Perhaps this [1] could give an inspiration how to keep a changelog that > only contains "important" changes. > [1] http://keepachangelog.com/en/0.3.0/ This kind of log is "for users and contributors to see precisely what notable changes have been made between each release (or version) of the project". In GNU, the NEWS file [2] serves this purpose. Whereas the ChangeLog [3] is for "people investigating bugs in the future". That's why it is so detailed. Bruno [2] https://www.gnu.org/prep/standards/html_node/NEWS-File.html [3] https://www.gnu.org/prep/standards/html_node/Change-Logs.html |
|
From: Sam S. <sd...@gn...> - 2017-02-23 14:49:51
|
Hi Bruno, > * Bruno Haible <oe...@py...> [2017-02-23 01:03:18 +0100]: > >> ChangeLog is obsolete. Even Emacs does not use it anymore. > Different groups of developers make different choices. Emacs is by far the oldest / most conservative project still active. (I think) > The not so obvious benefits are: > > - We can really keep track of the history over long periods of time. > Whereas when we rely on a VCS, we lose info at each move to a different > location. Nope. We never lost history, and, barring a global cataclysm, never will. > (Like the gmane.org article URLs became obsolete six months ago.) Yes, I have code in clisp/emacs/misc.el to resolve this. > In the recent move of libffcall from cvs to git we did not lose info, > but it cost me two days of work to achieve this result. This is a rare event. The CLISP move from CVS to HG was not free either, but it was lossless too. > - You get educated to review your changes before committing them. I don't know what you mean here. > - You can access a ChangeLog without any tools, just with a text editor. You still need a computer. :-) I have never been in a situation when this was more useful than VC logs - which are directly linked to diffs. >> for me the main drawback is that it >> dramatically increases the probability of conflicts. > > 1) There is a tool for automatically resolving these conflicts: > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c > You find the installation instructions at lines 42..48, 77..88 of this file. This is a crutch to keep using a 40yo VC simultaneously with a modern one. > 2) Even without it, yes there would be conflicts, but they are easy to > resolve, since you remember what you have added. Conflicts are only > difficult to resolve if you don't remember what were your changes > versus what were the other person's changes. It's not about difficulty. It's about inconvenience. You are underestimating its importance. (see the recent discussion about *.d format for relevant insights) >> If I make a local commit and do not push it right away, it is almost >> certain that I will have to go through either merge or strip/recommit >> because rebase will definitely fail. > > It is not the intent of ChangeLog that you feel the need to push > immediately. Just keep the same patience as before. Intent ("normative") has nothing to do with reality ("positive"). > In all projects I work in (from gnulib to libffcall), I find ChangeLogs useful. > In projects without ChangeLog (e.g. XFree86), I found it hard to work. Okay, you want it, you got it. Let us not repeat the memorable discussion we had 20 years ago about 1s0+1d0 - should it be 1d0(me and the rest of the known universe) or 1s0(you). ;-) -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://www.dhimmitude.org https://jihadwatch.org http://iris.org.il http://no2bds.org (lisp programmers do it better) |
|
From: Raymond T. <toy...@gm...> - 2017-02-23 16:20:06
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes:
Sam> Hi Bruno,
>> * Bruno Haible <oe...@py...> [2017-02-23 01:03:18 +0100]:
>>
>>> ChangeLog is obsolete. Even Emacs does not use it anymore.
>> Different groups of developers make different choices.
Sam> Emacs is by far the oldest / most conservative project still active.
Sam> (I think)
>> The not so obvious benefits are:
>>
>> - We can really keep track of the history over long periods of time.
>> Whereas when we rely on a VCS, we lose info at each move to a different
>> location.
Sam> Nope. We never lost history, and, barring a global cataclysm, never will.
I think there's a huge difference between history (source control
system) and explanation of the history (changelog and commit
messages).
On many open source projects the commit messages basically tend to
suck. The say incomplete things like "fix bug". What bug? And the
actual diff contains the fix and lots of other stuff. Changelogs tend
to force you to more precisely that you changed this function to do
this and that function to fix something else.
But I've seen bad Changelog entries too.
If people wrote good commit messages, then a Changelog wouldn't be
needed.
So I hate writing changelogs and will instead try to make the commit
message equivalent to the changelog.
My 2 cents, anyway.
--
Ray
|
|
From: Sam S. <sd...@gn...> - 2017-02-23 17:43:22
|
> * Raymond Toy <gbl...@tz...> [2017-02-23 08:19:42 -0800]: > > I think there's a huge difference between history (source control > system) and explanation of the history (changelog and commit > messages). VC contains both history (diffs) and explanations (commit messages). > If people wrote good commit messages, then a Changelog wouldn't be > needed. Agreed. I have never heard a coherent explanation of how ChangeLog entries should differ from commit messages. If a ChangeLog is a part of the commit, Emacs copies the ChangeLog entry into the buffer editing the commit message. So, as far as I am concerned, `hg log` and `less ChangeLog` should be the same. > On many open source projects the commit messages basically tend to > suck. > But I've seen bad Changelog entries too. The only cure is self- or external(code review) discipline. One has to _care_ about what one is doing to make coherent commits and write informative and clear explanations (Changelog or commit messages). I think -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il http://www.dhimmitude.org https://jihadwatch.org Don't hit a man when he's down -- kick him; it's easier. |
|
From: Sam S. <sd...@gn...> - 2017-02-23 17:43:31
|
> * Raymond Toy <gbl...@tz...> [2017-02-23 08:19:42 -0800]: > > I think there's a huge difference between history (source control > system) and explanation of the history (changelog and commit > messages). VC contains both history (diffs) and explanations (commit messages). > If people wrote good commit messages, then a Changelog wouldn't be > needed. Agreed. I have never heard a coherent explanation of how ChangeLog entries should differ from commit messages. If a ChangeLog is a part of the commit, Emacs copies the ChangeLog entry into the buffer editing the commit message. So, as far as I am concerned, `hg log` and `less ChangeLog` should be the same. > On many open source projects the commit messages basically tend to > suck. > But I've seen bad Changelog entries too. The only cure is self- or external(code review) discipline. One has to _care_ about what one is doing to make coherent commits and write informative and clear explanations (Changelog or commit messages). -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il http://www.dhimmitude.org https://jihadwatch.org Don't hit a man when he's down -- kick him; it's easier. |
|
From: Sam S. <sd...@gn...> - 2017-02-23 17:14:32
|
> * Daniel Jour <qna...@tz...> [2017-02-23 08:44:10 +0000]: > > I think a changelog is a very useful thing to have, but I always felt > that the one of CLISP is by far too detailed. Once upon a time, CLISP had 3(!) historical files: ChangeLog (detailed), CHANGES.LOG (summary for developers), and NEWS (summary for users). I got rid of CHANGES.LOG in 2002. Now we have 4(!!!) histories: ChangeLog, NEWS, history.xml, `hg log`. The twist is that history.xml is merely the compressed docbook version of NEWS, updated at release time (IOW, the main difference between https://sourceforge.net/p/clisp/clisp/ci/tip/tree/src/NEWS and http://clisp.org/impnotes/clisp-history.html is the order). ChangeLog is a hold-over from the pre-VC times. Bruno finds it useful so we will keep it until he grows out of it :-) -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://no2bds.org http://thereligionofpeace.com http://mideasttruth.com Conscience is like a hamster: it is either asleep or gnawing. |
|
From: Bruno H. <br...@cl...> - 2017-02-23 21:10:16
|
Sam wrote: > Now we have 4(!!!) histories: ChangeLog, NEWS, history.xml, `hg log`. > The twist is that history.xml is merely the compressed docbook version > of NEWS, updated at release time During usual development: - You need to think only about ChangeLog and NEWS. - The hg log message is just a copy of the one-line summary of the ChangeLog entry; nothing that costs you brain cycles. - The history.xml you don't need to think about, since - as you say - it's updated only at release time. By the way, I find it marvellous how you have kept the NEWS file up-to-date. Bruno |
|
From: Sam S. <sd...@gn...> - 2017-02-23 21:40:59
|
> * Bruno Haible <oe...@py...> [2017-02-23 22:10:06 +0100]: > > - The hg log message is just a copy of the one-line summary of the ChangeLog > entry; nothing that costs you brain cycles. That's the whole point! NO! hg log message is the WHOLE ChangeLog entry. I am not proposing that we remove the ChangeLogs from the repo. Just put into hg what you have been putting into ChangeLogs. Or, as a first baby step, put the full message in BOTH. > By the way, I find it marvellous how you have kept the NEWS file up-to-date. Thank You! -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://no2bds.org https://ffii.org http://honestreporting.com http://thereligionofpeace.com The Politically Correct term for Censorship is Political Correctness. |
|
From: Bruno H. <br...@cl...> - 2017-02-24 17:20:05
|
Sam wrote: > NO! hg log message is the WHOLE ChangeLog entry. > ... > Or, as a first baby step, put the full message in BOTH. If you can tell me an Emacs customization that makes this effortless, through a single copy-and-paste from ChangeLog, then I'm willing to do it. That is, when hg opens an "emacs -nw" editor, I want to copy&paste the tab-indented entry, and Emacs should remove the leading tab and insert a blank line after the first line. If I need to spend time reindenting each line of the entry, I'm not agreeing. Bruno |
|
From: Sam S. <sd...@gn...> - 2017-02-24 17:47:14
|
> * Bruno Haible <oe...@py...> [2017-02-24 18:19:56 +0100]: > > Sam wrote: >> NO! hg log message is the WHOLE ChangeLog entry. >> ... >> Or, as a first baby step, put the full message in BOTH. > > If you can tell me an Emacs customization that makes this effortless, > through a single copy-and-paste from ChangeLog, then I'm willing to do > it. That is, when hg opens an "emacs -nw" editor, I want to This is how you use VIM, not Emacs. With Emacs, after I finish with the patch, I do `C-x v d` to get the *vc-dir* buffer which lists the modified files in the hg-controlled directory. There I select with `m` the files to be committed. Then I hit `C-x v v` and I am placed into the *vc-log* buffer with the ChangeLog entry already there and properly formatted as you describe (with the summary line, separator line, no TABs &c &c) > copy&paste the tab-indented entry, and Emacs should remove the leading > tab and insert a blank line after the first line. Well, you can remove the leading tabs with M-% TAB RET RET. > If I need to spend time reindenting each line of the entry, I'm not > agreeing. You need to start using Emacs like it was intended to be used, not fight against the stream. You will like it. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il http://memri.org http://mideasttruth.com http://camera.org Rhinoceros has poor vision, but, due to his size, it's not his problem. |
Thanks for helping keep SourceForge clean.
X