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
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 relie
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'
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 C
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
> a
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
patch
On Tue, Apr 29, 2014 at 6:16 AM, Trevor Saunders 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 of
>> @di
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 opini
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 std
+# 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
From: Trevor Saunders
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 pipe git diff to mklog
11 matches
Mail list logo
