git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Add "--show-all" revision walker flag for debugging

From
Jakub Narebski <jnareb@gmail.com>
Date
Feb 11, 2008, 16:26 UTC
Message-ID
<200802111726.28001.jnareb@gmail.com>
In-Reply-To
<alpine.LFD.1.00.0802110748370.2920@woody.linux-foundation.org>
On Mon, 11 Feb 2008, Linus Torvalds wrote:
Show 7 quoted lines
> On Mon, 11 Feb 2008, Jakub Narebski wrote:
>> 
>> Errr... index is per workarea (per checkout), and this information
>> is per repository, so IMHO storing this info in an index (dircache)
>> is a layering violation. Unless you were talking about pack-file-index.
> 
> I did mean the pack-file index, not the "cache" index.
> And yes, just generating the generation number when repacking is fine. It 
> would mean that unpacked objects don't have generation numbers, but of you 
> have tons and tons of unpacked objects, you have more serious problems 
> anyway!

With generation number info in pack index, we could generate them on repack (adding some time to repack).

With generation number info in separate pack-index like file, we could add generation info whenever during browsing history we get to root or to commit with generation number, saving generation numbers in the by-the-way way, generating them lazily.

>> Weren't the cases of multiple roots that were difficult? Storing roots
>> would help with 'hard' (if seldom happening) cases then.
Show 18 quoted lines
> The thing that worried me about multiple roots was that they make the 
> generation numbers essentially "meaningless" when compared across totally 
> unrelated commits, and might give incorrect results for generation number 
> comparisons as a result.
> 
> However, I decided that if two commits really *are* totally unrelated and 
> don't share a commit, then:
> 
>  - yes, the generation number comparison is "meaningless"
> 
>  - BUT: we don't actually care if it's correct or not, because it will 
>    never matter: whatever we choose to do, it's correct. Because there are 
>    just two choices:
> 
>     (a) stop early because everything we have left is uninteresting
> 
>     (b) continue to the root because we think we might turn something 
>         interesting into an uninteresting commit.

By the way, with generation number we can always limit walk length to difference between generation numbers, or distance to root if it is smaller.

-- 
Jakub Narebski
Poland
Previous: Linus TorvaldsNext: Nicolas Pitre
Message 19 of 20 in “Add "--show-all" revision walker flag for debugging”
  1. Linus TorvaldsFeb 9, 2008
  2. Linus TorvaldsFeb 9, 2008
  3. Junio C HamanoFeb 10, 2008
  4. Johannes SchindelinFeb 10, 2008
  5. Linus TorvaldsFeb 10, 2008
  6. Johannes SchindelinFeb 10, 2008
  7. Junio C HamanoFeb 10, 2008
  8. Junio C HamanoFeb 10, 2008
  9. Nicolas PitreFeb 10, 2008
  10. Johannes SchindelinFeb 10, 2008
  11. Jakub NarebskiFeb 10, 2008
  12. Linus TorvaldsFeb 10, 2008
  13. Nicolas PitreFeb 10, 2008
  14. Jakub NarebskiFeb 10, 2008
  15. Linus TorvaldsFeb 10, 2008
  16. Jakub NarebskiFeb 11, 2008
  17. Nicolas PitreFeb 11, 2008
  18. Linus TorvaldsFeb 11, 2008
  19. Jakub NarebskiFeb 11, 2008
  20. Nicolas PitreFeb 11, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.