From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:33
Luben Tuikov [off-list ref] writes:
Teach tree->raw to not require the hash of the blob, but to
figure it out from the file name. This allows to externally
link to files into the repository, such that the hash is not
required. I.e. the file obtained would be as of the HEAD
commit.
In contrast tree->blob for binary files passes the hash, as
does tree->blob->plain for "text/*" files.
Signed-off-by: Luben Tuikov <redacted>
---
gitweb/gitweb.cgi | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
You are removing one line and adding one line, so the number of
old and new lines better match.
Hand-applied, tried, got confused and dropped.
I think _allowing_ to accept filename not hash is a sane change,
and would be useful if you want to allow linking to always the
HEAD version from external sites, but I do not think listing the
raw link in the tree view without the hash is a good idea. It
makes things quite confusing that "blob" link in its
neighbourhood gives the blob from that specific version, but
"raw" gives the version from HEAD, even when you are browsing
something other than HEAD.
BTW, can somebody volunteer to be a gitweb/ "subsystem
maintainer"?
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:33
Junio C Hamano wrote:
Luben Tuikov [off-list ref] writes:
quoted
Teach tree->raw to not require the hash of the blob, but to
figure it out from the file name. This allows to externally
link to files into the repository, such that the hash is not
required. I.e. the file obtained would be as of the HEAD
commit.
In contrast tree->blob for binary files passes the hash, as
does tree->blob->plain for "text/*" files.
I think _allowing_ to accept filename not hash is a sane change,
and would be useful if you want to allow linking to always the
HEAD version from external sites, but I do not think listing the
raw link in the tree view without the hash is a good idea. It
makes things quite confusing that "blob" link in its
neighbourhood gives the blob from that specific version, but
"raw" gives the version from HEAD, even when you are browsing
something other than HEAD.
BTW, can somebody volunteer to be a gitweb/ "subsystem
maintainer"?
I think the change to raw aka. blob_plain and not to plain is because in
plain view you have this HEAD link which takes us to HEAD revision of the
file (even if we are on different branch IIRC).
Workaround for either format is to remove 'h' (hash) parameter entirely, and
put in 'hb' (hashbase aka headref aka branch) the branch name. Gitweb then
shows the contents of latest version of the file.
BTW. sometimes you want to link to specific version of the file, and
sometimes to newest. I think it would be best (if possible, feasible, and
not too much resource consuming) that links from tree specified by hash be
to specified by hash version of file, while links from tree specified by
headref and name only would have links to latest version of the file.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Teach tree->raw to not require the hash of the blob, but to
figure it out from the file name. This allows to externally
link to files into the repository, such that the hash is not
required. I.e. the file obtained would be as of the HEAD
commit.
In contrast tree->blob for binary files passes the hash, as
does tree->blob->plain for "text/*" files.
Signed-off-by: Luben Tuikov <redacted>
---
gitweb/gitweb.cgi | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
This has exactly the same line number problem.
[cut]
Hand-applied, tried, got confused and dropped.
I'll regenerate and send it to the list.
I think _allowing_ to accept filename not hash is a sane change,
and would be useful if you want to allow linking to always the
HEAD version from external sites,
Indeed, it is useful.
but I do not think listing the
raw link in the tree view without the hash is a good idea. It
makes things quite confusing that "blob" link in its
neighbourhood gives the blob from that specific version, but
"raw" gives the version from HEAD, even when you are browsing
something other than HEAD.
I just thought it to be an easy place to put the "raw"-no-hash
link.
BTW, Junio, it would be a shame to lose this capability. How
would you like to proceed with this? Where would you like to
see this kind of link go?
BTW, can somebody volunteer to be a gitweb/ "subsystem
maintainer"?
Make sure you pick someone liberal without personal aspirations
or turning it into a personal crusade. Service to the community
(not self, or company XYZ) is best.
Luben
Teach tree->raw to not require the hash of the blob, but to
figure it out from the file name. This allows to externally
link to files into the repository, such that the hash is not
required. I.e. the file obtained would be as of the HEAD
commit.
In contrast tree->blob for binary files passes the hash, as
does tree->blob->plain for "text/*" files.
quoted
I think _allowing_ to accept filename not hash is a sane change,
and would be useful if you want to allow linking to always the
HEAD version from external sites, but I do not think listing the
raw link in the tree view without the hash is a good idea. It
makes things quite confusing that "blob" link in its
neighbourhood gives the blob from that specific version, but
"raw" gives the version from HEAD, even when you are browsing
something other than HEAD.
BTW, can somebody volunteer to be a gitweb/ "subsystem
maintainer"?
I think the change to raw aka. blob_plain and not to plain is because in
plain view you have this HEAD link which takes us to HEAD revision of the
file (even if we are on different branch IIRC).
Workaround for either format is to remove 'h' (hash) parameter entirely, and
put in 'hb' (hashbase aka headref aka branch) the branch name. Gitweb then
shows the contents of latest version of the file.
BTW. sometimes you want to link to specific version of the file, and
sometimes to newest. I think it would be best (if possible, feasible, and
not too much resource consuming) that links from tree specified by hash be
to specified by hash version of file, while links from tree specified by
headref and name only would have links to latest version of the file.
You seem to have hand-edited the mail headers to remove
Junio and myself from the CC/To headers list, but leave git@vger.
Please don't do that. Just click Reply-All and continue with your
message.
Thanks,
Luben
P.S. Restored.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:33
On 7/12/06, Luben Tuikov [off-list ref] wrote:
You seem to have hand-edited the mail headers to remove
Junio and myself from the CC/To headers list, but leave git@vger.
Please don't do that. Just click Reply-All and continue with your
message.
No, I've just replied from newsreader (not mail client) via GMane news
interface to git mailing list (gmane.comp.version-control.git), and I forgot
to use Reply-All, i.e. use mail as well as news interface.
Besides I seem to have problems trying to configure KNode to send
mail, especially with mixed mail+news sending.
--
Jakub Narebski