This is the mail archive of the
mailing list for the binutils project.
Re: Introduce support for location views
- From: Nick Clifton <nickc at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Mon, 17 Jul 2017 13:36:59 +0100
- Subject: Re: Introduce support for location views
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nickc at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1341037EEC
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1341037EEC
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com>
> Another issue I wanted to discuss is whether there's any interest in
> retaining development history of this patches. I've been working on it
> in a branch, users/aoliva/SFN, and I was thinking it might make sense
> for the patch that eventually gets committed to the master branch to be
> a merge from the branch, that adds the consolidated ChangeLog entries,
> rather than a single stand-alone commit that drops the development
> My reasoning is that, although we have comments and ChangeLogs and
> commit messages and email archives and whatnot, some of the development
> history behind certain changes will certainly be in the development
> commits only, and if we don't bring those into our commit history, they
> will likely be lost forever.
> I can see the benefit of them when bisecting patches for the kernel
> linux, for example, since a GIT pull request will bring some (possibly
> revised/consolidated/rewritten/polished/cleaned-up, but still...)
> development history that might shed light on issues that arise later.
> We currently throw that on the floor, but there's no reason for us to do
> so. Since we use GIT for the revision history, it would be trivial to
> install the consolidated patch as a merge that pulls in the development
> history from the branch, along with the intended changes, if we choose
> to do so.
> Just to be clear, what I'm suggesting is that, when development history
> for a patch is available, its commit be a pull/merge, so that the
> development history becomes part of the project history even if the branch
> was never published or was but gets removed later. It would in no way
> affect the checked-out tree, so the patch would add the same bits,
> including ChangeLogs and whatnot, and would carry the same commit
> messages that a regular commit would.
I like it. I am all in favour of providing future users/coders with as
much (useful) information as is possible.