Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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)"

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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,

Re: history damage in linux.git

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: >

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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 >

Re: history damage in linux.git

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:

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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

history damage in linux.git

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