On Mon, Dec 11, 2017 at 3:17 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> the information to what is shown. For example:
>>
>> $ ./git log --oneline --blobfind=v2.0.0:Makefile
>> b2feb64309 Revert the whole "ask curl-config" topic for now
>>
Stefan Beller writes:
> the information to what is shown. For example:
>
> $ ./git log --oneline --blobfind=v2.0.0:Makefile
> b2feb64309 Revert the whole "ask curl-config" topic for now
> 47fbfded53 i18n: only extract comments marked with "TRANSLATORS:"
This part is a
Sometimes users are given a hash of an object and they want to
identify it further (ex.: Use verify-pack to find the largest blobs,
but what are these? or [1])
One might be tempted to extend git-describe to also work with blobs,
such that `git describe ` gives a description as
':'. This was
On Fri, Dec 08, 2017 at 12:39:55PM -0800, Stefan Beller wrote:
> > If you add --raw, you can see that both commits introduce that blob, and
> > it never "goes away". That's because that happened in a merge, which we
> > don't diff in a default log invocation.
>
> We should when --raw is given.
>
Stefan Beller writes:
>>> +
>>> + if ((DIFF_FILE_VALID(p->one) &&
>>> + oidset_contains(options->blobfind, >one->oid)) ||
>>> + (DIFF_FILE_VALID(p->two) &&
>>> + oidset_contains(options->blobfind, >two->oid))) {
>>
>> +
>> + if ((DIFF_FILE_VALID(p->one) &&
>> + oidset_contains(options->blobfind, >one->oid)) ||
>> + (DIFF_FILE_VALID(p->two) &&
>> + oidset_contains(options->blobfind, >two->oid))) {
>
> Shouldn't this make sure that
On Fri, Dec 8, 2017 at 12:19 PM, Jeff King wrote:
> On Fri, Dec 08, 2017 at 04:28:23PM +, Ramsay Jones wrote:
>
>> On 08/12/17 09:34, Jeff King wrote:
>> > On Thu, Dec 07, 2017 at 04:24:47PM -0800, Stefan Beller wrote:
>> [snip]
>> >> Junio hinted at a different approach of
On Fri, Dec 08, 2017 at 04:28:23PM +, Ramsay Jones wrote:
> On 08/12/17 09:34, Jeff King wrote:
> > On Thu, Dec 07, 2017 at 04:24:47PM -0800, Stefan Beller wrote:
> [snip]
> >> Junio hinted at a different approach of solving this problem, which this
> >> patch implements. Teach the diff
Junio C Hamano writes:
> Stefan Beller writes:
> ...
>> @@ -2883,6 +2884,8 @@ int prepare_revision_walk(struct rev_info *revs)
>> simplify_merges(revs);
>> if (revs->children.name)
>> set_children(revs);
>> +if
On 08/12/17 09:34, Jeff King wrote:
> On Thu, Dec 07, 2017 at 04:24:47PM -0800, Stefan Beller wrote:
[snip]
>> Junio hinted at a different approach of solving this problem, which this
>> patch implements. Teach the diff machinery another flag for restricting
>> the information to what is shown.
Stefan Beller writes:
> diff --git a/diffcore-blobfind.c b/diffcore-blobfind.c
> new file mode 100644
> index 00..e65c7cad6e
> --- /dev/null
> +++ b/diffcore-blobfind.c
> @@ -0,0 +1,41 @@
> +/*
> + * Copyright (c) 2017 Google Inc.
> + */
> +#include "cache.h"
>
On Thu, Dec 07, 2017 at 04:24:47PM -0800, Stefan Beller wrote:
> Sometimes users are given a hash of an object and they want to
> identify it further (ex.: Use verify-pack to find the largest blobs,
> but what are these? or [1])
>
> One might be tempted to extend git-describe to also work with
Sometimes users are given a hash of an object and they want to
identify it further (ex.: Use verify-pack to find the largest blobs,
but what are these? or [1])
One might be tempted to extend git-describe to also work with blobs,
such that `git describe ` gives a description as
':'. This was
Junio C Hamano writes:
After saying "Will merge to 'next'" in the recent "What's cooking"
report, I noticed that a few loose ends were never tied on this
topic.
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index dd0dba5b1d..252a21cc19
Junio C Hamano writes:
> If that is the case, shouldn't we make this new mode imply
> --full-history to forbid history simplification? "git log" is a
> tool to find _an_ explanation of the current state, and the usual
> history simplification makes tons of sense there, but
Stefan Beller writes:
> Sometimes users are given a hash of an object and they want to
> identify it further (ex.: Use verify-pack to find the largest blobs,
> but what are these? or [1])
>
> One might be tempted to extend git-describe to also work with blobs,
> such that
Sometimes users are given a hash of an object and they want to
identify it further (ex.: Use verify-pack to find the largest blobs,
but what are these? or [1])
One might be tempted to extend git-describe to also work with blobs,
such that `git describe ` gives a description as
':'. This was
17 matches
Mail list logo