Git development
 help / color / mirror / Atom feed
From: Luben Tuikov <ltuikov@yahoo.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add "raw" output option to blobs in "tree" view format
Date: Fri, 7 Jul 2006 09:41:52 -0700 (PDT)	[thread overview]
Message-ID: <20060707164152.86022.qmail@web31805.mail.mud.yahoo.com> (raw)
In-Reply-To: <7vmzbl3nqj.fsf@assigned-by-dhcp.cox.net>

--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > Add a "raw" output option to blobs in "tree" view format, so that the
> > user doesn't have to click on "blob", wait for the (binary) file to be
> > uploaded and shown in "blob" mode, and then click on "plain" to
> > download the (binary) file.
> 
> I appreciate what you are trying to achieve, but at the same
> time wonder if it would make more sense to simply teach a=blob
> action to do this automatically, perhaps using /etc/mime.types
> and/or File::MMagic.

That'd be cool for non-"text/*" files, but it would leave the user
go through the same click "tree->blob->plain" for "text/*" files,
since they are "cat -n"-able and the default action would be git_blob()
if such an algorithm is implemented.

That is, the user would still have to click through "tree->blob->plain"
to download a "text/*" file, as opposed to just "tree->raw".

What this patch allows, is that the user be able to simply download the file,
right from "tree" view, regardless of the type of file. (I.e. the type of
file as decided by the _user_, not gitweb.cgi.)

Having said that, we can still implement it, so that "raw"="blob" for
non-"text/*" files, but "raw"!="blob" for "text/*" files.  I.e. allow
the "cat -n" functionality for "text/*" files, as is currently implemented,
as well as shortcut for downloading ("raw").

> If you know your MUA will mangle whitespace to make your patch
> inapplicable, please do not add a patch to the message _and_
> attach the patch to the message.  The mail-acceptance tools know
> how to flatten MIME attachments, but if you have your log,
> three-dash and then corrupt patch in the cover-letter part, and
> then the true patch in the attachment part, the flattened result
> will have the corrupt patch first to cause the patch application
> to fail.  So please either (preferably) use a MUA that does not
> corrupt your patches, or do a log in the message part with patch
> only as attachment.

Will do.

    Luben

  reply	other threads:[~2006-07-07 16:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-07  6:39 [PATCH] Add "raw" output option to blobs in "tree" view format Luben Tuikov
2006-07-07  6:58 ` Junio C Hamano
2006-07-07 16:41   ` Luben Tuikov [this message]
2006-07-07 18:45     ` Junio C Hamano

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=20060707164152.86022.qmail@web31805.mail.mud.yahoo.com \
    --to=ltuikov@yahoo.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /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