git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Two gitweb feature requests
Date: Fri, 28 Apr 2006 11:23:11 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0604281116020.3701@g5.osdl.org> (raw)
In-Reply-To: <e2tjqm$83n$1@sea.gmane.org>



On Fri, 28 Apr 2006, Jakub Narebski wrote:
>
> I'd like to have 'parent directory' link for trees ('..' link) at the top of
> it's contents. I know it is possible to use browser history for that, but
> it would give greater similarity with 'directory listing' mode of WWW
> servers.

Well, a git "tree" doesn't actually _have_ a parent. It potentially has 
multiple.

So to get to "a parent", you literally do need to keep track of how you 
got to the tree. Which is certainly possible (maybe it even ends up being 
in the URI that gitk generates, I didn't check), but basically, if it 
isn't tracked explicitly, it basically is impossible to find.

Not having back-pointers is what allows git to do data sharing and a lot 
of other things efficiently. A tree is a tree is a tree, and has zero data 
about what points to it, so as long as the _contents_ of a tree are the 
same, you have exactly the same object. That means that the same subtree 
can - and will - be pointed to by multiple upper-level trees and commits. 

So you do need that "browser history" one way or another. Either in the 
browser (use the "back button") or by encoding the "how did we get here" 
information in the URI and the dynamically generated page content.

The downside is that you'd have two different web-pages for the same tree 
depending on which commit it came from. Which is not a downside from a 
user perspective, but it's a downside from a caching/server perspective, 
since it means less reuse of pages (maybe gitweb already does that, 
though).

		Linus

  reply	other threads:[~2006-04-28 18:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-27 13:27 Two gitweb feature requests David Woodhouse
2006-04-27 13:35 ` Matthias Lederhofer
2006-04-27 13:47   ` David Woodhouse
2006-04-27 22:54 ` Ben Clifford
2006-04-29 21:38   ` David Woodhouse
     [not found] ` <20060428122630.234edde4.seanlkml@sympatico.ca>
2006-04-28 16:26   ` sean
2006-04-28 17:37 ` Jakub Narebski
2006-04-28 18:23   ` Linus Torvalds [this message]
2006-04-28 19:11     ` Jakub Narebski
2006-04-29  5:02     ` Jeff King
2006-04-29 11:16 ` Jakub Narebski
  -- strict thread matches above, loose matches on Subject: below --
2006-04-29  7:27 Jakub Narebski

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=Pine.LNX.4.64.0604281116020.3701@g5.osdl.org \
    --to=torvalds@osdl.org \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).