All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>
Subject: Re: .git/info/refs
Date: Fri, 26 Jan 2007 03:41:54 -0800	[thread overview]
Message-ID: <7vireuxbel.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <45B8E551.9020808@zytor.com> (H. Peter Anvin's message of "Thu, 25 Jan 2007 09:13:53 -0800")

"H. Peter Anvin" <hpa@zytor.com> writes:

> For heaven's sake, in computer science we can *NEVER* use the same
> feature for *MORE THAN ONE THING*.  If it doesn't work format-wise
> that's fine, but "it's only supposed to be used by dumb transports" is
> ridiculous.

Hmmmm... I am lost here....

> Right
> now, git-update-server-index is the command to update cached
> information, and for usability reasons there should be a single entry
> point.

Modulo s/-index/-info/, I agree that would be a very sensible
position, as long as the cost to generate additional cached
information necessary to help gitweb is reasonably small, I am
not opposed to have it generate another file [*1*].


[*1*]

I've been looking for backward-compatible holes in ls-remote and
its users, hoping we somehow could shoehorn this information in
info/refs, as I do not think its file format is sacred, nor the
file is there _only_ to help dumb transports.  As long as the
published way to access that information stays consistent, the
underlying file format is a fair game.  However, I do not think
the ls-remote command implementations in the wild has such a
hole I can exploit.

  parent reply	other threads:[~2007-01-26 11:42 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-24  7:38 .git/info/refs H. Peter Anvin
2007-01-24  9:28 ` .git/info/refs Jakub Narebski
2007-01-24 15:55   ` .git/info/refs H. Peter Anvin
2007-01-24 16:02     ` .git/info/refs Johannes Schindelin
2007-01-24 16:24       ` .git/info/refs H. Peter Anvin
2007-01-24 16:38         ` .git/info/refs Johannes Schindelin
2007-01-24 16:41           ` .git/info/refs H. Peter Anvin
2007-01-24 16:52             ` .git/info/refs Johannes Schindelin
2007-01-24 17:06               ` .git/info/refs H. Peter Anvin
2007-01-24 17:25                 ` .git/info/refs Jakub Narebski
2007-01-24 17:10             ` .git/info/refs Jakub Narebski
2007-01-24 17:20               ` .git/info/refs Johannes Schindelin
2007-01-25 17:13               ` .git/info/refs H. Peter Anvin
2007-01-26 11:22                 ` .git/info/refs Jakub Narebski
2007-01-26 11:41                 ` Junio C Hamano [this message]
2007-01-26 16:39                   ` .git/info/refs H. Peter Anvin
2007-01-26 17:06                     ` .git/info/refs Jakub Narebski
2007-01-26 21:09                     ` .git/info/refs Johannes Schindelin
2007-01-26 21:32                       ` .git/info/refs H. Peter Anvin
2007-01-26 21:54                       ` .git/info/refs H. Peter Anvin
2007-01-24 20:40     ` .git/info/refs Jakub Narebski
2007-01-24 20:44       ` .git/info/refs hpa
2007-01-25  8:14         ` .git/info/refs Johannes Schindelin
2007-01-25 16:12           ` .git/info/refs H. Peter Anvin
2007-01-25 16:50             ` .git/info/refs Johannes Schindelin
2007-01-24 20:45       ` .git/info/refs hpa
2007-01-25 21:28     ` .git/info/refs Junio C Hamano
2007-01-25 21:37       ` .git/info/refs H. Peter Anvin
2007-01-25 21:51         ` .git/info/refs Junio C Hamano
2007-01-25 22:01           ` .git/info/refs H. Peter Anvin
2007-01-25 23:33             ` .git/info/refs Johannes Schindelin
2007-01-27 22:07               ` .git/info/refs H. Peter Anvin
2007-01-31 15:38                 ` .git/info/refs Santi Béjar
2007-02-01 14:03                 ` .git/info/refs Johannes Schindelin
2007-02-01 16:16                   ` .git/info/refs H. Peter Anvin
2007-02-01 16:52                     ` .git/info/refs Johannes Schindelin
2007-02-01 16:56                       ` .git/info/refs H. Peter Anvin
2007-02-01 17:32                         ` .git/info/refs Matthias Lederhofer
2007-02-01 17:51                           ` .git/info/refs H. Peter Anvin

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=7vireuxbel.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=hpa@zytor.com \
    --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 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.