This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: A ChangeLog alternative?
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 31 Jan 2019 23:56:18 +0000
- Subject: Re: A ChangeLog alternative?
- References: <87a7jgtpuu.fsf@mid.deneb.enyo.de>
On Thu, 31 Jan 2019, Florian Weimer wrote:
> Look at this:
>
> $ git log -p -M -M -C glibc-2.28..glibc-2.29 | xz -9 | wc -c
> 1454172
>
> And compare it with:
>
> $ ls -l glibc-2.29.tar.xz
> -rw-r--r-- 1 fw fw 16515488 Jan 31 19:08 glibc-2.29.tar.xz
>
> So the additional overhead for the mirrors is quite small.
>
> For some reason, a .tar.xz file with individual patches from “git
> format-patch” is even smaller:
>
> -rw-r--r-- 1 fw fw 1542028 Jan 31 23:35 patches.tar.xz
>
> I wonder if this would fit the requirement to document development
> history without a version control system.
Feel free to try to persuade RMS on bug-standards that this information is
sufficient (I think that would run into the issue of identifying the named
entities changed by a given commit, more accurately than the diff hunk
headers in cases where the funcname line appears within the diffs).
RMS did at one point accept that a sufficiently reliable mapping from
entities to commits that changed them (rather than the other way round)
would also suffice - but not that tools like "git blame" or "git log -L"
are sufficiently reliable for that purpose, or that it's OK to expect some
understanding of git to be required for such investigations of history.
--
Joseph S. Myers
joseph@codesourcery.com