Hi Linus,
On Thu, 21 Apr 2016, Linus Torvalds wrote:
> On Thu, Apr 21, 2016 at 11:05 AM, Jeff King wrote:
> >
> > Sadly, neither git's internal version-sorting nor GNU's "sort -V"
> > knows that "v1.0-rc1" comes before "v1.0", so I had to rely on
> > "--sort=taggerdate".
>
> I'm not seeing the
Stefan Beller writes:
> Combining Junios and Linus idea:
>
> * We want to have the minimal history, i.e. that tag with the fewest
> cummulative parent commits. (i.e. v3.13-rc7 is better than v3.13
> because `git log --oneline v3.13-rc7 |wc -l` (414317) is smaller tha
> `git log --oneline v3.13 |w
On Thu, Apr 21, 2016 at 12:27 PM, Junio C Hamano wrote:
> Linus Torvalds writes:
>
>> But this patch is small and simple, and has some excuses for its
>> behavior. What do people think?
>
> I like it that you call it "excuse" not "rationale", as I couldn't
> form a logical connection between your
Linus Torvalds writes:
> But this patch is small and simple, and has some excuses for its
> behavior. What do people think?
I like it that you call it "excuse" not "rationale", as I couldn't
form a logical connection between your "4 (2) letters" and "1
(100)" at all ;-)
Modulo the usual sty
On Thu, Apr 21, 2016 at 11:05 AM, Jeff King wrote:
>
> I actually think the best name for aed06b9 is probably:
>
> v3.13-rc1~65^2^2~42
Sounds likely. I don't know how to find that best match without a
complete rewrite, though.
My recent patch that got
v3.13-rc2~32^2^2~47
comes close to tha
On Thu, Apr 21, 2016 at 10:59:52AM -0700, Linus Torvalds wrote:
> That said, I do think that a much bigger conceptual change that
> actually does full traversal and be much more complicated might be the
> only "correct" solution.
>
> So my patch is just a "improve heuristics" small fixlet rather
On Thu, Apr 21, 2016 at 10:23:10AM -0700, Linus Torvalds wrote:
> > which is technically true, but kind of painful to read. It may be that a
> > reasonable weight is somewhere between "1" and "65535", though.
>
> Based on my tests, the "right" number is somewhere in the 500-1000
> range for this
On Thu, Apr 21, 2016 at 10:43 AM, Linus Torvalds
wrote:
>
> In other words, I'm trying to convince people that my patch not only
> gives a good result, but that the "weight numbers" I use make some
> kind of conceptual sense from a complexity cost angle.
Basically, the patch approximates the nume
On Thu, Apr 21, 2016 at 10:23 AM, Linus Torvalds
wrote:
> On Thu, Apr 21, 2016 at 10:08 AM, Jeff King wrote:
>>
>> Right, because it makes the names longer. We give the second-parent
>> traversal a heuristic cost. If we drop that cost to "1", like:
>
> So I dropped it to 500 (removed the two last
On Thu, Apr 21, 2016 at 10:23 AM, Junio C Hamano wrote:
>
> I think avoiding side branches to describe with the weight is a
> right thing to do, i.e. if you have this history:
>
> X---o---o---o---o---v4.6
> \ /
> o---o
>
> you do not want to explain X as "v4.6~^2
Linus Torvalds writes:
> On Thu, Apr 21, 2016 at 9:36 AM, Linus Torvalds
> wrote:
>>
>> This seems to be a git bug.
>>
>> That commit aed06b9 can also be described as
>>
>> v3.13-rc7~9^2~14^2~42
>>
>> so describing it as 'v4.6-rc1~9^2~792' is clearly not closer in any way.
>
> Hmm. I think I
On Thu, Apr 21, 2016 at 10:08 AM, Jeff King wrote:
>
> Right, because it makes the names longer. We give the second-parent
> traversal a heuristic cost. If we drop that cost to "1", like:
So I dropped it to 500 (removed the two last digits), and it gave a
reasonable answer. With 1000, it gave the
On Thu, Apr 21, 2016 at 09:59:13AM -0700, Junio C Hamano wrote:
> Linus Torvalds writes:
>
> > That commit aed06b9 can also be described as
> >
> > v3.13-rc7~9^2~14^2~42
> >
> > so describing it as 'v4.6-rc1~9^2~792' is clearly not closer in any way.
>
> I seem to recall that name-rev had a
On Thu, Apr 21, 2016 at 9:36 AM, Linus Torvalds
wrote:
>
> This seems to be a git bug.
>
> That commit aed06b9 can also be described as
>
> v3.13-rc7~9^2~14^2~42
>
> so describing it as 'v4.6-rc1~9^2~792' is clearly not closer in any way.
Hmm. I think I see what's up. The git distance functio
Linus Torvalds writes:
> That commit aed06b9 can also be described as
>
> v3.13-rc7~9^2~14^2~42
>
> so describing it as 'v4.6-rc1~9^2~792' is clearly not closer in any way.
I seem to recall that name-rev had an unexplained heuristics to
strongly avoid following second parent changes (I see t
Olaf Hering writes:
> On Thu, Apr 21, John Keeping wrote:
>
>> $ git tag --contains aed06b9cfcabf8644ac5f6f108c0b3d01522f88b
>
> Thanks for that, I did not know this variant.
>
> Unless git does not do it for me, I may hackup my script like that to
> find the earlierst tag:
"git tag" has a
On Thu, Apr 21, 2016 at 6:24 AM, Andreas Schwab wrote:
>
> The branches recently pulled by Linus contain commits with rather old
> author dates, eg 8cad489261c564d4ee1db4de4ac365af56807d8a or
> 281baf7a702693deaa45c98ef0c5161006b48257. That will probably cause git
> describe --contains to take a
On Thu, Apr 21, John Keeping wrote:
> $ git tag --contains aed06b9cfcabf8644ac5f6f108c0b3d01522f88b
Thanks for that, I did not know this variant.
Unless git does not do it for me, I may hackup my script like that to
find the earlierst tag:
for i in `git tag --contains aed06b9cfcabf8644ac
Olaf Hering writes:
> How can I find out whats going on? Is my git(1) 2.8.1 broken, or did
> Linus just pull some junk tree (and does he continue to do so)?
The branches recently pulled by Linus contain commits with rather old
author dates, eg 8cad489261c564d4ee1db4de4ac365af56807d8a or
281baf7a
On Thu, Apr 21, 2016 at 01:30:04PM +0200, Olaf Hering wrote:
> To track the changes in hyperv related files I created some scripts
> years ago to automate the process of finding relevant commits in
> linux.git. Part of that process is to record the tag when a commit
> appeared in mainline. This wor
Olaf Hering writes:
> On Thu, Apr 21, Matthieu Moy wrote:
>
>> My guess is that this commit has been sitting for a long time in a
>> repo outside Linus' linux.git, and got merged only recently.
>
> Thats what it looks like. And thats what I'm complaining about. But in
> fact that file is there si
On Thu, Apr 21, Matthieu Moy wrote:
> My guess is that this commit has been sitting for a long time in a
> repo outside Linus' linux.git, and got merged only recently.
Thats what it looks like. And thats what I'm complaining about. But in
fact that file is there since v3.13-rc7 (if the tag is rea
Olaf Hering writes:
> To track the changes in hyperv related files I created some scripts
> years ago to automate the process of finding relevant commits in
> linux.git. Part of that process is to record the tag when a commit
> appeared in mainline. This worked fine, until very recently.
>
> Sudd
To track the changes in hyperv related files I created some scripts
years ago to automate the process of finding relevant commits in
linux.git. Part of that process is to record the tag when a commit
appeared in mainline. This worked fine, until very recently.
Suddenly years-old commits are declar
24 matches
Mail list logo
