All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Nicolas Pitre <nico@cam.org>, Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Add "--show-all" revision walker flag for debugging
Date: Mon, 11 Feb 2008 17:26:26 +0100	[thread overview]
Message-ID: <200802111726.28001.jnareb@gmail.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0802110748370.2920@woody.linux-foundation.org>

On Mon, 11 Feb 2008, Linus Torvalds wrote:
> 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.

> 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

  reply	other threads:[~2008-02-11 16:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-09 22:02 Add "--show-all" revision walker flag for debugging Linus Torvalds
2008-02-09 23:52 ` Linus Torvalds
2008-02-10  4:44   ` Junio C Hamano
2008-02-10  1:12 ` Johannes Schindelin
2008-02-10  1:22   ` Linus Torvalds
2008-02-10  1:29     ` Johannes Schindelin
2008-02-10  4:09     ` Junio C Hamano
2008-02-10  4:21       ` Junio C Hamano
2008-02-10  1:28   ` Nicolas Pitre
2008-02-10  1:30     ` Johannes Schindelin
2008-02-10 20:17       ` Jakub Narebski
2008-02-10 20:50         ` Linus Torvalds
2008-02-10 21:04           ` Nicolas Pitre
2008-02-10 22:53           ` Jakub Narebski
2008-02-10 23:11             ` Linus Torvalds
2008-02-11  1:24               ` Jakub Narebski
2008-02-11  1:59                 ` Nicolas Pitre
2008-02-11 15:59                 ` Linus Torvalds
2008-02-11 16:26                   ` Jakub Narebski [this message]
2008-02-11 16:39                   ` Nicolas Pitre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200802111726.28001.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=nico@cam.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.