Re: Bug: file named - on git commit

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2013, 17:43 UTC
Message-ID: <7v8v742cwh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130128204140.GA7759@google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 8 quoted lines

>> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
>> need to read blob from the standard input, 2012-06-27), which is
>> included starting with v1.7.12 and the v1.7.11.3 maint release.  Please
>> upgrade.
>
> Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
> is currently in the release candidate stage) take this fix?  Do you
> happen to know of any other fixes such people would want?

I've been wondering if we can help automating this for backporters.

Because of the way my integration branches are managed, if you run

	git log --first-parent v1.8.0..maint-1.8.0
	git log --first-parent v1.8.1..maint

the output should give us a birds-eye view (because most are merges of one or more patches on a topic) of the changes that are fixes, excluding any feature enhancements.

You can then iterate over the single patches applied directly on top of maint (or maint-1.8.0) and tips of the topics merged to maint (or maint-1.8.0) and see if each of them is applicable to maint-1.7.10 codebase. I think you can mechanically reject the ones that are on 'maint' that merge topics that were forked from v1.8.1 as too new. That hopefully culls the topics that needs manual review and assessment (some may be too minor to be worth backproting, for example).

You should be able to do the same for

        git log --first-parent v1.8.1..master

There will be fixes and features mixed in the output, but if you can mechanically narrow down the ones that may be relevant to your old maintenance track, eyeballing the rest to judge if each of them is worth backporting will become a manageable task.