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(&git_default_date);
>> +}
>
> Looks sane.
>
>> and then to sprinkle calls liberally thr
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 "git rebase", and the codepath th
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 commit_tree_extended(), and
>> just s
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() to drive "git c
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 betwe
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
>> date.
>
> No, that would be nasty, partly f
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(&git_default_date);
> +}
Looks sane.
> and then to sprinkle calls liberally through builtin-ified programs when
> they move from one unit of work to
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 because I just think i
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 @@ st
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 entirely
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 accidental, I think that what happene
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, b
12 matches
Mail list logo
