be developed as a
separate project - more or less independent from git.git, I do believe
there would be considerable value in distributing them along with Git
and easily enabling them (maybe even enabling them by default, as
without the config options they would just be no-ops). Otherwise, it
would be
On Tue, Oct 29, 2013 at 3:08 AM, Jeff King wrote:
> On Mon, Oct 28, 2013 at 12:29:32PM +0100, Johan Herland wrote:
>> > A hook-based solution could do this. But a built-in "all-purpose"
>> > handler like "footer.Fixes.arg=commit", which was intended to
ways be more flexible and less dependent on making
changes in git.git. (...a suitably flexible hook could even use the
config options discussed above as input...) In both cases, we need the
user to actively enable the functionality (either installing hooks, or
setting up config), and in both cases
On Sun, Oct 27, 2013 at 8:04 PM, Christian Couder
wrote:
> On Sun, Oct 27, 2013 at 2:30 PM, Johan Herland wrote:
>> On Sun, Oct 27, 2013 at 1:30 PM, Christian Couder
>> wrote:
>>>
>>> Your suggestion is very good, and it is not incompatible with command
>&
summmary)
Obviously, any other fancy processing you want to do into in the
commit-msg hook can be done as well, adding footnotes, checking that
commits are present in the ancestry, etc, etc.
Three good reasons to go this way:
1. If the user forgets to supply command-line options li
5 matches
Mail list logo
