Junio C Hamano writes:
> Jeff King writes:
>
>> I wonder if you can
>> define the weight as a recursive function of the parents.
>
> I do not think we can. A merge Z between X (that has N commits
> behind it) and Y (that has M commits behind it) has at most N+M+1
> commits behind it (counting i
Junio C Hamano writes:
> Jeff King writes:
>
>> OK. I didn't think too hard about it, so I'll trust you that it is not
>> easy. I wonder if using the generation number would be another way of
>> defining "oldest" that would be easier to calculate.
>
> Go back to my illustration to Greg and think
Jeff King writes:
> OK. I didn't think too hard about it, so I'll trust you that it is not
> easy. I wonder if using the generation number would be another way of
> defining "oldest" that would be easier to calculate.
Go back to my illustration to Greg and think about the implication
of "TONS!"
Jeff King writes:
> When you wrote "oldest" here, I thought that meant you would do a
> comparison on the taggerdate. But reading the implementation, you really
> mean "topologically oldest".
>
> I wonder, though, if the former would be sufficient for most people.
Even without clock skew, timest
On Wed, Aug 29, 2012 at 08:53:49PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I wonder if you can
> > define the weight as a recursive function of the parents.
>
> I do not think we can. A merge Z between X (that has N commits
> behind it) and Y (that has M commits behind it) has a
Jeff King writes:
> I wonder if you can
> define the weight as a recursive function of the parents.
I do not think we can. A merge Z between X (that has N commits
behind it) and Y (that has M commits behind it) has at most N+M+1
commits behind it (counting itself), but we cannot tell how many
a
On Wed, Aug 29, 2012 at 02:17:24PM -0700, Junio C Hamano wrote:
> Instead of naming a rev after a tip that is topologically closest,
> use the tip that is the oldest one among those which contain the
> rev.
When you wrote "oldest" here, I thought that meant you would do a
comparison on the tagger
On Wed, Aug 29, 2012 at 04:37:06PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Note that this is fairly expensive (see NEEDSWORK comment in the
> > code).
>
> And this is with the "notes-cache".
> [...]
> +static int get_tip_weight(struct commit *commit)
> +{
> + struct strb
Junio C Hamano writes:
> Note that this is fairly expensive (see NEEDSWORK comment in the
> code).
And this is with the "notes-cache".
(priming the cache from scratch)
$ rm .git/refs/notes/name-rev-weight
$ /usr/bin/time ../git.git/git-name-rev --weight --tags 0136db586c
0136db
Instead of naming a rev after a tip that is topologically closest,
use the tip that is the oldest one among those which contain the
rev.
The semantics "name-rev --weight" would give is closer to what
people expect from "describe --contains".
Note that this is fairly expensive (see NEEDSWORK comme
10 matches
Mail list logo
