All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andy Parkins <andyparkins@gmail.com>
Cc: git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>
Subject: Re: [PATCH] Quick description of possible gitattributes system
Date: Fri, 2 Mar 2007 13:02:23 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0703021249010.3953@woody.linux-foundation.org> (raw)
In-Reply-To: <200703021937.33648.andyparkins@gmail.com>



On Fri, 2 Mar 2007, Andy Parkins wrote:

> On Friday 2007, March 02, Linus Torvalds wrote:
> 
> > Yes. How about just having the built-in git pager do the right thing?
> 
> Perfect.  This is absolutely the right thing to do I think.

Well, it would be perfect, except it's rather hard to do. Right now we 
simply don't have any way to tell the pager what to do with the data, and 
we'd need to do some communications passing thing to let it know.

It *could* just look at the data directly, but that's actually hard: if we 
start looking at the data, there's no way to push the data back onto the 
head of a pipe, and there's no really good way to tell an external pager 
to "start off with this data that I already read earlier to figure out the 
type, and then continue with that other file descriptor that I'm passing 
in".

So then we'd have to have a totally useless process in between the git 
process and the external pager to just feed the data from one pipe to the 
other..

Doing the pager internally would obviously solve that issue, but I really 
don't think we want to do that, especially since it's very 
system-dependent. And temporary files suck for all the other reasons 
(incrementally generated data).

So we're in the situation where:

 - the pager process *will* wait until actual data is starting to appear,
   so we *can* have some side-band channel to tell it "oh, btw, if there 
   is a pager, this is going to be image data, so start up an external 
   image viewer instead". 

 - but I don't have a good clue what side-band to use. We could use 
   a special "FILE *pagerdata", of course (which would just be fd#3 in 
   the pager). Then, "git show" could just do something like

	if (pager_in_use)
		fprintf(pagerdata, "'%s'\n", type);

   and we could change pager.c to do something like the appended patch.

but I have to say, it looks a bit strange.

		Linus

---
diff --git a/pager.c b/pager.c
index 5f280ab..b71dd44 100644
--- a/pager.c
+++ b/pager.c
@@ -9,6 +9,8 @@
 
 static void run_pager(const char *pager)
 {
+	static char input_type[100] = "text";
+
 	/*
 	 * Work around bug in "less" by not starting it until we
 	 * have real input
@@ -17,7 +19,16 @@ static void run_pager(const char *pager)
 
 	FD_ZERO(&in);
 	FD_SET(0, &in);
-	select(1, &in, NULL, &in, NULL);
+	FD_SET(3, &in);
+	select(4, &in, NULL, &in, NULL);
+	if (FS_ISSET(3, &in)) {
+		int n = read(3, input_type, sizeof(input_type)-1);
+		if (n > 0)
+			input_type[n] = 0;
+	}
+	close(3);
+
+	pager = select_pager(input_type, pager);
 
 	execlp(pager, pager, NULL);
 	execl("/bin/sh", "sh", "-c", pager, NULL);

  reply	other threads:[~2007-03-02 21:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-01 12:06 [PATCH] Quick description of possible gitattributes system Andy Parkins
2007-03-01 16:06 ` Brian Gernhardt
2007-03-02 12:00   ` Andy Parkins
2007-03-02 18:05     ` Brian Gernhardt
2007-03-02 19:35       ` Andy Parkins
2007-03-02 20:35         ` Brian Gernhardt
2007-03-01 18:01 ` Robin Rosenberg
2007-03-02  0:09 ` Junio C Hamano
2007-03-02  4:46   ` Junio C Hamano
2007-03-02  8:58     ` Andy Parkins
2007-03-02  8:56   ` Andy Parkins
2007-03-02 13:56 ` Jakub Narebski
2007-03-02 16:58   ` Linus Torvalds
2007-03-02 19:37     ` Andy Parkins
2007-03-02 21:02       ` Linus Torvalds [this message]
2007-03-02 21:45         ` Johannes Schindelin
2007-03-02 22:21         ` Andy Parkins
2007-03-02 22:24           ` Andy Parkins
2007-03-03 13:11     ` Junio C Hamano
2007-03-03 20: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.0703021249010.3953@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=andyparkins@gmail.com \
    --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 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.