Re: [PATCH 2/2] allow running mklog as a filter

2014-07-28 Thread Yury Gribov
On 07/21/2014 12:55 PM, Trevor Saunders wrote: I'm not really sure which is the better UI, but I'd rather time be spent on better automatic change log generation. Yeah. Do you have some particular complaints btw? I may or may not hope we'll eventually have a mklog that can autogenerate most

Re: [PATCH 2/2] allow running mklog as a filter

2014-07-28 Thread Trevor Saunders
On Mon, Jul 28, 2014 at 10:42:51AM +0400, Yury Gribov wrote: On 07/21/2014 12:55 PM, Trevor Saunders wrote: I'm not really sure which is the better UI, but I'd rather time be spent on better automatic change log generation. Yeah. Do you have some particular complaints btw? I haven't

Re: [PATCH 2/2] allow running mklog as a filter

2014-07-28 Thread Yury Gribov
On 07/28/2014 03:01 PM, Trevor Saunders wrote: Yeah. Do you have some particular complaints btw? I haven't actually used it in a while, but istr there's an issue where if you change the prototype of a function mklog makes an entry for the previous function. I think this is because mklog

Re: [PATCH 2/2] allow running mklog as a filter

2014-07-28 Thread Trevor Saunders
On Mon, Jul 28, 2014 at 06:29:22PM +0400, Yury Gribov wrote: On 07/28/2014 03:01 PM, Trevor Saunders wrote: Yeah. Do you have some particular complaints btw? I haven't actually used it in a while, but istr there's an issue where if you change the prototype of a function mklog makes an entry

Re: [PATCH 2/2] allow running mklog as a filter

2014-07-21 Thread Yury Gribov
On 05/09/2014 07:09 PM, Diego Novillo wrote: I slightly prefer the semantics that gets me just the ChangeLog. The workflow I'm envisioning is: I've commited both patches in r212883 and r12884. Mklog now runs as a filter and prints generated ChangeLog to stdout instead of modifying the

Re: [PATCH 2/2] allow running mklog as a filter

2014-07-21 Thread Trevor Saunders
On Mon, Jul 21, 2014 at 11:49:05AM +0400, Yury Gribov wrote: On 05/09/2014 07:09 PM, Diego Novillo wrote: I slightly prefer the semantics that gets me just the ChangeLog. The workflow I'm envisioning is: I've commited both patches in r212883 and r12884. Mklog now runs as a filter and

Re: [PATCH 2/2] allow running mklog as a filter

2014-05-09 Thread Diego Novillo
On Tue, Apr 29, 2014 at 6:16 AM, Trevor Saunders tsaund...@mozilla.com wrote: +# In any case if we got the diff on stdin then write the ChangeLog to stdout. Hm, this is breaks semantics: you only dump CL instead of CL+diff just because diff comes from stdin. Perhaps we could append contents

Re: [PATCH 2/2] allow running mklog as a filter

2014-04-29 Thread Trevor Saunders
On Tue, Apr 29, 2014 at 09:18:39AM +0400, Yury Gribov wrote: +# XXX We should probably accept /dev/stdin or maybe magic autodetection of +# being supposed to get the patch from stdin. +# Can we just set $diff to '-' if @ARGV is empty? sgtm +# In any case if we got the diff on stdin then

Re: [PATCH 2/2] allow running mklog as a filter

2014-04-29 Thread Yury Gribov
I agree stdin gets different semantics than other files but I think that's sort of ok because it means you generated the patch somehow so presumably you can do that again if you need the patch. True but this would be a surpising behavior for ordinary Linux user. We can wait for Diego's

[PATCH 2/2] allow running mklog as a filter

2014-04-28 Thread tsaunders
From: Trevor Saunders tbsau...@mozilla.com Hi, I'd like to be able to suggest a git prepare-committ-msg hook, that uses this at some point to populate the commit message at some point. This doesn't do that, but its a step in that direction, what would remain is just writing a shell script to

Re: [PATCH 2/2] allow running mklog as a filter

2014-04-28 Thread Yury Gribov
+# XXX We should probably accept /dev/stdin or maybe magic autodetection of +# being supposed to get the patch from stdin. +# Can we just set $diff to '-' if @ARGV is empty? +# In any case if we got the diff on stdin then write the ChangeLog to stdout. Hm, this is breaks semantics: you only