Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-29 Thread Junio C Hamano
On Thu, Jul 28, 2016 at 5:37 PM, Linus Torvalds wrote: > On Thu, Jul 28, 2016 at 5:29 PM, Jeff King wrote: >> >> I guess we want something like: >> >> +void reset_ident_date(void) >> +{ >> + strbuf_reset(_default_date); >> +} > > Looks sane. >

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-29 Thread Junio C Hamano
Linus Torvalds writes: > So we do want to cache things for a single commit, it's just that for > things like "git am" (or, like Junio wondered, "git rebase" - I didn't > check) we probabyl just just flush the cache in between commits. What I cautioned was indeed

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-29 Thread Junio C Hamano
Jeff King writes: > On Thu, Jul 28, 2016 at 05:37:08PM -0700, Linus Torvalds wrote: > >> > and then to sprinkle calls liberally through builtin-ified programs when >> > they move from one unit of work to the next. >> >> Maybe we can just add it to the end of

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-29 Thread Junio C Hamano
Jeff King writes: > On Thu, Jul 28, 2016 at 04:47:17PM -0700, Junio C Hamano wrote: > >> Also makes me wonder if "git cherry-pick A..B" shares the same >> breakage. > > Probably. It seems that "cherry-pick A..B" leads to sequencer.c::run_git_commit() that uses run_command_v_opt()

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-29 Thread Jeff King
On Thu, Jul 28, 2016 at 05:37:08PM -0700, Linus Torvalds wrote: > > and then to sprinkle calls liberally through builtin-ified programs when > > they move from one unit of work to the next. > > Maybe we can just add it to the end of commit_tree_extended(), and > just say "the cache is reset

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-29 Thread Christian Couder
On Fri, Jul 29, 2016 at 2:32 AM, Linus Torvalds wrote: > On Thu, Jul 28, 2016 at 5:21 PM, Jeff King wrote: >> >> I do wonder if you would be happier giving each commit a "fake" >> monotonically increasing time, so they are correctly ordered by commit

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-28 Thread Linus Torvalds
On Thu, Jul 28, 2016 at 5:29 PM, Jeff King wrote: > > I guess we want something like: > > +void reset_ident_date(void) > +{ > + strbuf_reset(_default_date); > +} Looks sane. > and then to sprinkle calls liberally through builtin-ified programs when > they move from one unit

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-28 Thread Linus Torvalds
On Thu, Jul 28, 2016 at 5:21 PM, Jeff King wrote: > > I do wonder if you would be happier giving each commit a "fake" > monotonically increasing time, so they are correctly ordered by commit > date. No, that would be nasty, partly for the corner case you mention, but partly

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-28 Thread Jeff King
On Thu, Jul 28, 2016 at 04:47:17PM -0700, Junio C Hamano wrote: > Also makes me wonder if "git cherry-pick A..B" shares the same > breakage. Probably. I guess we want something like: diff --git a/ident.c b/ident.c index 139c528..e20a772 100644 --- a/ident.c +++ b/ident.c @@ -184,6 +184,11 @@

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-28 Thread Jeff King
On Thu, Jul 28, 2016 at 04:35:58PM -0700, Linus Torvalds wrote: > Now, it would be lovely if the new builtin git-am really was *so* fast > that it applies a 100+-patch series in under a second, but no, that's > not it. It's just that it only looks up the current time once. > > That seems

Re: Small trivial annoyance with the nice new builtin "git am"

2016-07-28 Thread Junio C Hamano
On Thu, Jul 28, 2016 at 4:35 PM, Linus Torvalds wrote: > Ok, it's no longer *that* new, but I only now noticed.. > > So I noticed that when I applied the last patch-bomb series from > Andrew, all the commit date-stamps are idential. > ... > That seems entirely

Small trivial annoyance with the nice new builtin "git am"

2016-07-28 Thread Linus Torvalds
Ok, it's no longer *that* new, but I only now noticed.. So I noticed that when I applied the last patch-bomb series from Andrew, all the commit date-stamps are idential. Now, it would be lovely if the new builtin git-am really was *so* fast that it applies a 100+-patch series in under a second,