[ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Petr Baudis]

  Hello,

  so I've "released" git-pasky-0.6.2 (my SCMish layer on top of Linus
Torvalds' git tree history storage system), find it at the usual

	http://pasky.or.cz/~pasky/dev/git/

  git-pasky-0.6 has couple of big changes; mainly enhanced git diff,
git patch (to be renamed to cg mkpatch), enhanced git pull and
completely reworked git merge - it now uses the git-core facilities for
merging, and does the merges in-tree. Plenty of smaller stuff, some
bugfixes and some new bugs, and of course regular merging with Linus.

  The most important change for current users is the objects database
SHA1 keys change and (comparatively minor) directory cache format
change. This makes "pulling up" from older revisions rather difficult.
Linus' instructions _should_ work for you too, basically (you should
replace cat .git/HEAD with cat .git/heads/* or equivalent - note that
convert-tree does not accept multiple arguments so you need to invoke it
multiple times), but I didn't test it well (I did it the lowlevel way
completely since I needed to simultaneously merge with Linus).

  But if you can't be bothered by this or fear touching stuff like that,
and you do not have any local commits in your tree (it would be pretty
strange if you had and still fear), just fetch the tarball (which is
preferrable than git init for me since it eats up _significantly_
smaller portion of my bandwidth).

  I had to release git-pasky-0.6.1 since Linus changed the directory
cache format during me releasing git-pasky-0.6. And git-pasky-0.6.2
fixes gitmerge-file.sh script missing in the list of scripts for
install.


  So, now for the heads-up part. We will undergo at least two major
changes now. First, I'll probably make git-pasky to use the directory
cache for the add/rm queues now that we have diff-cache.

  Second, I've decided to straighten up the naming now that we still
have a chance. There will be no git-pasky-0.7, sorry. You'll get
cogito-0.7 instead. I've decided for it since after some consideration
having it named differently is the right thing (tm).

  The short command version will change from 'git' to 'cg', which should
be shorter to type and free the 'git' command for possible eventual
entry gate for the git commands (so that they are more
namespace-friendly, and it might make most sense anyway if we get fully
libgitized; but this is more of long-term ideas).

  The usage changes:

  cg patch -> cg mkpatch	('patch' is the program which _applies_ it)
  cg apply -> cg patch		(analogically to diff | patch)

  cg pull will now always only pull, never merge.

  cg update will do pull + merge.

  cg track will either just set the default for cg update if you pass it
no parameters, or disappear altogether; I think it could default to the
'origin' branch (or 'master' branch for non-master branches if no 'origin'
branch is around), and I'd rather set up some "cg admin" where you could
set all this stuff - from this to e.g. the committer details [*1*]. You
likely don't need to change the default every day.

  I must say that I'm pretty happy with the Cogito's command set
otherwise, though. I actually think it has now (almost?) all commands
it needs, and it is not too likely that (many) more will be added -
simple means easy to use, which is Cogito's goal. Compare with
the command set of GNU arch clones. ;-)


  [*1*] The committer details in .git would override the environemnt
variables to discourage people of trying to alter them based on
whatever, since that's not what they are supposed to do. They can always
just change the .git stuff if they _really_ need to.


  Comments welcomed, as well as new ideas. Persuading me to change what
I sketched here will need some good arguments, though. ;-)

  Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Petr Baudis]

Dear diary, on Wed, Apr 20, 2005 at 10:56:33PM CEST, I got a letter
where Petr Baudis <pasky@ucw.cz> told me that...
>   cg pull will now always only pull, never merge.
> 
>   cg update will do pull + merge.

Note that what you will probably do _most_ by far is cg update.
You generally do cg pull only when you want to make sure you have the
latest and greatest when doing some cg diff or whatever, or on your
notebook when getting on an airplane. And you do direct cg merge generally
only on the airplane.

I also forgot one last usage change:

  cg fork BNAME BRANCH_DIR [COMMIT_ID]
  ->
  cg fork BRANCH_DIR [BNAME] [COMMIT_ID]

This will bring its usage in sync to both cg export and cg tag.
The branch name will also default to the last element in the
BRANCH_DIR path (that annoyed me a lot, basically writing a thing
two times at single line).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Greg KH]

On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
>   The short command version will change from 'git' to 'cg', which should
> be shorter to type and free the 'git' command for possible eventual
> entry gate for the git commands (so that they are more
> namespace-friendly, and it might make most sense anyway if we get fully
> libgitized; but this is more of long-term ideas).

Hm, but there already is a 'cg' program out there:
	http://uzix.org/cgvg.html
I use it every day :(

How about 'cog' instead?

Or I can just rename my local copy of cg and try to retrain my
fingers...

thanks,

greg k-h

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Mike Taht]

I keep thinking perversely that we need something as obtuse as possible
in the unix tradition, but easy to type... git requires that the fingers
move off the home row...

how about "asdf" or "jkl"?  :)

cg is singularly uncomfortable to type. I think that's why it isn't 
commonly used.....

Greg KH wrote:
> On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
> 
>>  The short command version will change from 'git' to 'cg', which should
>>be shorter to type and free the 'git' command for possible eventual
>>entry gate for the git commands (so that they are more
>>namespace-friendly, and it might make most sense anyway if we get fully
>>libgitized; but this is more of long-term ideas).
> 
> 
> Hm, but there already is a 'cg' program out there:
> 	http://uzix.org/cgvg.html
> I use it every day :(
> 
> How about 'cog' instead?
> 
> Or I can just rename my local copy of cg and try to retrain my
> fingers...
> 
> thanks,
> 
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 

Mike Taht


   "New systems generate new problems."

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Joshua T. Corbin]

On 20 April 2005 17:51, Mike Taht wrote:
> I keep thinking perversely that we need something as obtuse as possible
> in the unix tradition, but easy to type... git requires that the fingers
> move off the home row...
>
> how about "asdf" or "jkl"?  :)
>
> cg is singularly uncomfortable to type. I think that's why it isn't
> commonly used.....
Hmm...got to disagree, cg is perfectly comfortable to type here on my dvorak, 
whilst asdf ad jkl are uncomfortable deviations accross the board ;-)

-- 
Regards,
Joshua T. Corbin <jcorbin@wunjo.org>

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Petr Baudis]

Dear diary, on Wed, Apr 20, 2005 at 11:19:19PM CEST, I got a letter
where Greg KH <greg@kroah.com> told me that...
> On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
> >   The short command version will change from 'git' to 'cg', which should
> > be shorter to type and free the 'git' command for possible eventual
> > entry gate for the git commands (so that they are more
> > namespace-friendly, and it might make most sense anyway if we get fully
> > libgitized; but this is more of long-term ideas).
> 
> Hm, but there already is a 'cg' program out there:
> 	http://uzix.org/cgvg.html
> I use it every day :(
> 
> How about 'cog' instead?

Grm. Cg is also name of some scary NVidia thing, and cog is GNOME
Configurator. CGT are Chimera Grid Tools, but I think we can clash
with those - at least *I* wouldn't mind. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Randy.Dunlap]

On Wed, 20 Apr 2005 23:51:18 +0200 Petr Baudis wrote:

| Dear diary, on Wed, Apr 20, 2005 at 11:19:19PM CEST, I got a letter
| where Greg KH <greg@kroah.com> told me that...
| > On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
| > >   The short command version will change from 'git' to 'cg', which should
| > > be shorter to type and free the 'git' command for possible eventual
| > > entry gate for the git commands (so that they are more
| > > namespace-friendly, and it might make most sense anyway if we get fully
| > > libgitized; but this is more of long-term ideas).
| > 
| > Hm, but there already is a 'cg' program out there:
| > 	http://uzix.org/cgvg.html
| > I use it every day :(
| > 
| > How about 'cog' instead?
| 
| Grm. Cg is also name of some scary NVidia thing, and cog is GNOME
| Configurator. CGT are Chimera Grid Tools, but I think we can clash
| with those - at least *I* wouldn't mind. ;-)

I'd rather see you go back to 'tig'...

is there a tig out there?

---
~Randy

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Steven Cole]

Randy.Dunlap wrote:
> On Wed, 20 Apr 2005 23:51:18 +0200 Petr Baudis wrote:
> 
> | Dear diary, on Wed, Apr 20, 2005 at 11:19:19PM CEST, I got a letter
> | where Greg KH <greg@kroah.com> told me that...
> | > On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
> | > >   The short command version will change from 'git' to 'cg', which should
> | > > be shorter to type and free the 'git' command for possible eventual
> | > > entry gate for the git commands (so that they are more
> | > > namespace-friendly, and it might make most sense anyway if we get fully
> | > > libgitized; but this is more of long-term ideas).
> | > 
> | > Hm, but there already is a 'cg' program out there:
> | > 	http://uzix.org/cgvg.html
> | > I use it every day :(
> | > 
> | > How about 'cog' instead?
> | 
> | Grm. Cg is also name of some scary NVidia thing, and cog is GNOME
> | Configurator. CGT are Chimera Grid Tools, but I think we can clash
> | with those - at least *I* wouldn't mind. ;-)
> 
> I'd rather see you go back to 'tig'...
> 
> is there a tig out there?
> 
> ---
> ~Randy

Since I was the one who came up with the "cogito" name, I'll suggest
some alternatives if cogito is unworkable.  This was posted once before,
mostly as a joke, but here goes.

agitato  ag     Since Beethoven's "Moonlight" 3rd mvmt is Presto agitato
                 and very, very fast, just like git.

legit le or lg  Since git is GPLv2, it's now legit.


Steven

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Linus Torvalds]

On Wed, 20 Apr 2005, Petr Baudis wrote:
> 
> Grm. Cg is also name of some scary NVidia thing, and cog is GNOME
> Configurator. CGT are Chimera Grid Tools, but I think we can clash
> with those - at least *I* wouldn't mind. ;-)

I realize that there is probably a law that there has to be a space, but I 
actually personally use tab-completion all the time, and in many ways 
prefer a name that can be completed without having to play games with 
magic bash completion files.

So how about using a dash instead of a space, and making things be

	cg-pull
	cg-update

etc? You can link them all to the same script if you don't like having 
multiple scripts, and just match with

	case "$0" in
	*-pull)
		...
		;;
	*-update)
		...
		;;

or something.

Yeah, yeah, it looks different from "cvs update", but dammit, wouldn't it 
be cool to just write "cg-<tab><tab>" and see the command choices? Or 
"cg-up<tab>" and get cg-update done for you..

Just because rcs/cvs/everybody-and-his-dog thinks it is cool to have a 
space there and have different meaning for flags depending on whether they 
are before the command or after the command doesn't mean that they are 
necessarily right..

Just an idea,

		Linus

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Petr Baudis]

Dear diary, on Thu, Apr 21, 2005 at 12:09:06AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> Yeah, yeah, it looks different from "cvs update", but dammit, wouldn't it 
> be cool to just write "cg-<tab><tab>" and see the command choices? Or 
> "cg-up<tab>" and get cg-update done for you..

I like this idea! :-) I guess that is in fact exactly what I have been
looking for, and (as probably apparent from the current git-pasky
structure) I prefer to have the scripts separated anyway.

I think I will go for it. I also thought about having this _and_ a 'cg'
command which would act as a completely dumb multiplexer, but I decided
to toss that idea since it would only create usage ambiguity and other
problems on the long run.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Greg KH]

On Thu, Apr 21, 2005 at 12:28:15AM +0200, Petr Baudis wrote:
> Dear diary, on Thu, Apr 21, 2005 at 12:09:06AM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> told me that...
> > Yeah, yeah, it looks different from "cvs update", but dammit, wouldn't it 
> > be cool to just write "cg-<tab><tab>" and see the command choices? Or 
> > "cg-up<tab>" and get cg-update done for you..
> 
> I like this idea! :-) I guess that is in fact exactly what I have been
> looking for, and (as probably apparent from the current git-pasky
> structure) I prefer to have the scripts separated anyway.

I agree, it would solve the issue with 'cg' being overloaded, and I too
like the <tab><tab> completion idea.

thanks,

greg k-h

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Linus Torvalds]

Pasky,
 what do you think about this change to "git log"?

It makes it a _lot_ easier to parse the result, as it indents all the
comments by two spaces, meaning that the header is clearly marked, and you
can then do various 'sed'/'grep' things with nice normal regular
expressions like '^parent' without having to worry about there being a 
line that starts with "parent" in the free-form part..

I also think the end result is more readable from a human standpoint, with 
indentation as the way to distinguish the headers from the commentary, 
and less ugly ASCII barfic's with "------" etc.

I'm doing a 2.6.12-rc3 release, so I care more than usual about the 
changelog ;)

		Linus

---
gitlog.sh: a496a864f9586e47a4d7bd3ae0af0b3e07b7deb8
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -28,7 +28,7 @@ rev-tree $base | sort -rn | while read t
 				fi
 				;;
 			"")
-				echo; cat
+				echo; sed 's/^/  /'
 				;;
 			*)
 				echo $key $rest
@@ -36,5 +36,5 @@ rev-tree $base | sort -rn | while read t
 			esac
 
 		done
-	echo -e "\n--------------------------"
+	echo
 done

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Linus Torvalds]

On Wed, 20 Apr 2005, Linus Torvalds wrote:
> 
> Pasky,
>  what do you think about this change to "git log"?

Here's a slightly updated version.

It's identical to the previous one, except that it also feeds the result 
through "| ${PAGER:-less}" which makes it a lot more useful, in my 
opinion.

If you redirect the output to a non-tty, both "less" and "more" do the 
right thing and just feed the output straight through. But if the output 
is a tty, this makes "git log" a lot more friendly than a quickly 
scrolling mess..

		Linus

----
gitlog.sh: a496a864f9586e47a4d7bd3ae0af0b3e07b7deb8
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -28,7 +28,7 @@ rev-tree $base | sort -rn | while read t
 				fi
 				;;
 			"")
-				echo; cat
+				echo; sed 's/^/  /'
 				;;
 			*)
 				echo $key $rest
@@ -36,5 +36,5 @@ rev-tree $base | sort -rn | while read t
 			esac
 
 		done
-	echo -e "\n--------------------------"
-done
+	echo
+done | ${PAGER:-less}

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Daniel Jacobowitz]

On Wed, Apr 20, 2005 at 06:12:34PM -0700, Linus Torvalds wrote:
> Here's a slightly updated version.
> 
> It's identical to the previous one, except that it also feeds the result 
> through "| ${PAGER:-less}" which makes it a lot more useful, in my 
> opinion.
> 
> If you redirect the output to a non-tty, both "less" and "more" do the 
> right thing and just feed the output straight through. But if the output 
> is a tty, this makes "git log" a lot more friendly than a quickly 
> scrolling mess..

Personally, I'd rather it didn't do this; bk help does the same thing,
and it drives me crazy.  I guess you have /usr/bin/man for a precedent,
though :-)

My logic: it's a lot more intuitive to say "cg-log | less" to get
paginated output than it is to say "cg-log | cat" to get unpaginated
output.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Sean]

On Wed, April 20, 2005 11:35 pm, Daniel Jacobowitz said:

> My logic: it's a lot more intuitive to say "cg-log | less" to get
paginated output than it is to say "cg-log | cat" to get unpaginated
output.
>

Daniel,

All you'd have to do is:

$ export PAGER=cat

to get the behavior you want.

Sean

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Linus Torvalds]

On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
> 
> My logic: it's a lot more intuitive to say "cg-log | less" to get
> paginated output than it is to say "cg-log | cat" to get unpaginated
> output.

I disagree.

There is _never_ any valid situation where you do "cg-log" with 
unpaginated output to a tty.

In _any_ real system you'll be getting thousands of lines of output. 
Possibly millions. unpaginated? What the hell are you talking about?

And as I pointed out, if the output is not a tty, then both less and more
automatically turn into cat, so there's no difference. This change _only_
triggers for a tty, and I dare you to show a single relevant project where 
it's ok to scroll thousands of lines.

Even git-pasky, which is just a two-week-old project right now outputs 
4338 lines of output to "git log". 

Unpaginated? You must be kidding.

(But if you are _that_ fast a reader, then hey, use "PAGER=cat", and 
you'll find yourself happy).

		Linus

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Dave Jones]

On Wed, Apr 20, 2005 at 09:00:44PM -0700, Linus Torvalds wrote:
 
 > > My logic: it's a lot more intuitive to say "cg-log | less" to get
 > > paginated output than it is to say "cg-log | cat" to get unpaginated
 > > output.
 > I disagree.
 > 
 > There is _never_ any valid situation where you do "cg-log" with 
 > unpaginated output to a tty.
 > 
 > In _any_ real system you'll be getting thousands of lines of output. 
 > Possibly millions. unpaginated? What the hell are you talking about?
 > 
 > And as I pointed out, if the output is not a tty, then both less and more
 > automatically turn into cat, so there's no difference. This change _only_
 > triggers for a tty, and I dare you to show a single relevant project where 
 > it's ok to scroll thousands of lines.
 > 
 > Even git-pasky, which is just a two-week-old project right now outputs 
 > 4338 lines of output to "git log". 
 > 
 > Unpaginated? You must be kidding.
 > 
 > (But if you are _that_ fast a reader, then hey, use "PAGER=cat", and 
 > you'll find yourself happy).

I used to do 'bk changes | grep \[AGPGART\] -C3 | head'  on a regular basis,
just to be able to answer 'hey, did cset x get into tree y?' questions from users.
which is the probably the closest I came to non-paginated usage.
(though, ok 'head' is technically a pager too..)

		Dave

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Junio C Hamano]

>>>>> "DJ" == Dave Jones <davej@redhat.com> writes:

DJ> I used to do 'bk changes | grep \[AGPGART\] -C3 | head' on a
DJ> regular basis, just to be able to answer 'hey, did cset x
DJ> get into tree y?' questions from users.  which is the
DJ> probably the closest I came to non-paginated usage.

I am bk untainted so I may be misunderstanding what your example
is, but I take that "bk changes" in your example corresponds to
"git log", correct?

Then please read what Linus wrote again.  Your example is
exactly the point Linus is making.  The output from that command
is not going to a tty---it is going to a _pipe_ and more or less
will do exactly (not more or less ;-) the right thing.

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Daniel Jacobowitz]

On Wed, Apr 20, 2005 at 09:00:44PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
> > 
> > My logic: it's a lot more intuitive to say "cg-log | less" to get
> > paginated output than it is to say "cg-log | cat" to get unpaginated
> > output.
> 
> I disagree.
> 
> There is _never_ any valid situation where you do "cg-log" with 
> unpaginated output to a tty.
> 
> In _any_ real system you'll be getting thousands of lines of output. 
> Possibly millions. unpaginated? What the hell are you talking about?

OK, so I'm crazy.  I must have hallucinated doing this sort of thing on
a regular basis... :-) Examples: terminals with good scrollback,
screen, script.  Small repositories.  Irritation at less's habit of
using the alternate xterm buffer, whatever the technical term for that
is.

But hey, you'll use it more often than I will by far.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Petr Baudis]

Dear diary, on Thu, Apr 21, 2005 at 06:28:34AM CEST, I got a letter
where Daniel Jacobowitz <dan@debian.org> told me that...
> On Wed, Apr 20, 2005 at 09:00:44PM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
> > > 
> > > My logic: it's a lot more intuitive to say "cg-log | less" to get
> > > paginated output than it is to say "cg-log | cat" to get unpaginated
> > > output.
> > 
> > I disagree.
> > 
> > There is _never_ any valid situation where you do "cg-log" with 
> > unpaginated output to a tty.
> > 
> > In _any_ real system you'll be getting thousands of lines of output. 
> > Possibly millions. unpaginated? What the hell are you talking about?
> 
> OK, so I'm crazy.  I must have hallucinated doing this sort of thing on
> a regular basis... :-) Examples: terminals with good scrollback,
> screen, script.  Small repositories.  Irritation at less's habit of
> using the alternate xterm buffer, whatever the technical term for that
> is.

... Plan9. But I guess you won't even have a pager there. ;-)

A little off-topic, anyone knows how to turn off that damn alternate
screen thing on the xterm level? (Or any other level which makes _all_
programs not to use it.)

More seriously, I think Linus' patch is fine; the usage in scripts is
not affected, and alternatives were suggested. When we have cg-admin, I
might even let you set per-repository git-specific PAGER (which you
could set to be even some fancy script which would parse the stuff, open
a cute window and display stuff graphically, or whatever).

Linus, ahem, could you please sign off your patch? :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Edgar Toernig]

Petr Baudis wrote:
>
> A little off-topic, anyone knows how to turn off that damn alternate
> screen thing on the xterm level? (Or any other level which makes _all_
> programs not to use it.)

Change the terminfo entry.

The relevant sequence is \E?47h and \E[?47l (save/restore screen) and
often it is paired with \E7 and \E8 (save/restore cursor position)
and \E[2J (clear screen).  [1]

Here it was put in the smcup/rmcup capabilities.

  infocmp >term.src
  vi term.src
  # either remove the sequences or completely disable the
  # capabilities by adding a dot in front of them (.rmcup=...).
  tic term.src

Done.

Ciao, ET.

[1] On strange terminals the escape sequences may be completely
different but these are the common ones.

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Petr Baudis]

Dear diary, on Thu, Apr 21, 2005 at 04:21:00PM CEST, I got a letter
where Edgar Toernig <froese@gmx.de> told me that...
> Petr Baudis wrote:
> >
> > A little off-topic, anyone knows how to turn off that damn alternate
> > screen thing on the xterm level? (Or any other level which makes _all_
> > programs not to use it.)
> 
> Change the terminfo entry.

That's why I asked for how to do it on the xterm level. Some programs
don't care about term(cap|info). And I may not be root.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Paul Jackson]

> A little off-topic, anyone knows how to turn off that damn alternate
> screen thing on the xterm level? 

Do you mean the 'feature' where it clears the screen of the
last page you were viewing on exit from 'less'?

The following stops that clearing:

    export LESS=-X

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Randy.Dunlap]

On Wed, 20 Apr 2005 21:00:44 -0700 (PDT) Linus Torvalds wrote:

| 
| 
| On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
| > 
| > My logic: it's a lot more intuitive to say "cg-log | less" to get
| > paginated output than it is to say "cg-log | cat" to get unpaginated
| > output.
| 
| I disagree.
| 
| There is _never_ any valid situation where you do "cg-log" with 
| unpaginated output to a tty.
| 
| In _any_ real system you'll be getting thousands of lines of output. 
| Possibly millions. unpaginated? What the hell are you talking about?

Who in the world would look at thousands or millions of lines on a
tty using a pager?

| And as I pointed out, if the output is not a tty, then both less and more
| automatically turn into cat, so there's no difference. This change _only_
| triggers for a tty, and I dare you to show a single relevant project where 
| it's ok to scroll thousands of lines.
| 
| Even git-pasky, which is just a two-week-old project right now outputs 
| 4338 lines of output to "git log". 
| 
| Unpaginated? You must be kidding.
| 
| (But if you are _that_ fast a reader, then hey, use "PAGER=cat", and 
| you'll find yourself happy).

---
~Randy

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Sean]

On Thu, April 21, 2005 1:14 am, Randy.Dunlap said:

>> In _any_ real system you'll be getting thousands of lines of output.
>> Possibly millions. unpaginated? What the hell are you talking about?
>
> Who in the world would look at thousands or millions of lines on a
> tty using a pager?
>

This conversation is getting a bit silly, but to answer your question a
pager has a search feature which would let you bypass the first 900,000
lines to find the ones you're interested in.

Cheers,
Sean

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Greg KH]

On Wed, Apr 20, 2005 at 06:12:34PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 20 Apr 2005, Linus Torvalds wrote:
> > 
> > Pasky,
> >  what do you think about this change to "git log"?
> 
> Here's a slightly updated version.
> 
> It's identical to the previous one, except that it also feeds the result 
> through "| ${PAGER:-less}" which makes it a lot more useful, in my 
> opinion.

Yeah!

I've gotten tired of counting how many times I forgot to pipe 'git log'
to less already.  Doesn't seem to want to be canceled either...

thanks for doing this.

greg k-h

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Paul Jackson]

Linus wrote:
+				echo; sed 's/^/  /'

One can avoid adding useless trailing spaces on empty lines with:

+				echo; sed 's/./  &/'

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Matthias Urlichs]

Linus Torvalds wrote:

> I realize that there is probably a law that there has to be a space, but I 
> actually personally use tab-completion all the time

You can actually teach bash3 to do that (yes, with space).

In general, though, I tend to agree -- dashes work with more shells and
avoid namespace collisions.

-- 
Matthias Urlichs

Removing command dispatcher (was Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes)

[David A. Wheeler]

Matthias Urlichs wrote:

>Linus Torvalds wrote:
>
>  
>
>>I realize that there is probably a law that there has to be a space, but I 
>>actually personally use tab-completion all the time
>>    
>>
It's very unusual, but I can't think of any crisis it causes.

One minor annoyance: Windows doesn't support #! magic headers,
and a very few-and-probably-ignorable old Unix systems don't either.
There, commands written in an interpreter like perl, python, or shell can't
be kicked off just by a #! reference at the top (standard Windows' shell is
incompatible anyway, so it's just as well in the case of shell).

I don't see this as a roadblock, though.  On those systems, you could
create trivial stubs that just invoke the interpreter (e.g., perl) and the
real program. In the Windows case, you can use Windows' miserable
excuse for a command processor to do that very easily.
E.g., if "cg-update" is a Perl script, then you can create a file 
"cg-update.bat":
perl  \path\to\cg-update %*

(That requires Windows NT4 or better. MS-DOS didn't have %*, so you needed:
perl  \path\to\cg-update %1 %2 %3 %4 %5 %6 %7 %8 %9
It's hard to imagine an MS-DOS git user though.)

--- David A. Wheeler

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Ingo Molnar]

* Linus Torvalds <torvalds@osdl.org> wrote:

> Yeah, yeah, it looks different from "cvs update", but dammit, wouldn't 
> it be cool to just write "cg-<tab><tab>" and see the command choices?  
> Or "cg-up<tab>" and get cg-update done for you..

add this line to your ~/.bashrc:

 complete -W "add addremote apply cancel ci commit diff export fork help init log ls lsobj lsremote merge pull rm seek status tag track version" git

and you'll get all the argument completions, after "git " (it works on 
arguments, after the space). (you can even customize it to list only the 
ones you typically use, to make the completion faster) This first showed 
up in zsh but now bash knows it too. (see 'Programmable Completions' in 
man bash)

	Ingo

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Andrew Morton]

Linus Torvalds <torvalds@osdl.org> wrote:
>
> Yeah, yeah, it looks different from "cvs update", but dammit, wouldn't it 
>  be cool to just write "cg-<tab><tab>" and see the command choices? Or 
>  "cg-up<tab>" and get cg-update done for you..

zsh can do this for (for example) cvs.  Type "cvs <tab><tab><tab>" and 
you get "cvs annotate".

Type "cvs commit foo/bar/<tab>" and zsh will start cycling through the 
files which need committing in ./foo/bar/.  Yes, the shell knows about
and pokes around inside cvs files.

I just brought this up because I know how much you'd love the whole
concept ;)

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Bryan Donlan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Petr Baudis wrote:
|   Hello,
|
|   so I've "released" git-pasky-0.6.2 (my SCMish layer on top of Linus
| Torvalds' git tree history storage system), find it at the usual
|
| 	http://pasky.or.cz/~pasky/dev/git/

When I run `git pull', I get:

Tree change:
55f9d5042603fff4ddfaf4e5f004d2995286d6d3:7a4c67965de68ae7bc7aa1fde33f8eb9d8114697
+100644	blob	8186a561108d3c62625614272bd5e2f7d5826b4b	README.reference
*100755->100755	blob
5f23301eb97a0fadd505a6e9cc851e98741a512a->bf277135908ee7c6b7d6ad330d1ce183b9bb411f
git
*100755->100755	blob
a78cf8ccab98861ef7aecb4cb5a79e47d3a84b67->74b4083d67eda87d88a6f92c6c66877bba8bda8a
gitcancel.sh
Tracked branch, applying changes...
Fast-forwarding 55f9d5042603fff4ddfaf4e5f004d2995286d6d3 ->
7a4c67965de68ae7bc7aa1fde33f8eb9d8114697
	on top of 55f9d5042603fff4ddfaf4e5f004d2995286d6d3...
patch: **** Only garbage was found in the patch input.

I'm on debian testing, patch 2.5.9. It seems to apply the changes
despite this error.

Thanks,

Bryan Donlan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQmcVqXhF4rlE0/81AQPNdA//fmL+O3amch3WUfYLZroSNarto/jcQ8WE
NAwthoT+nPkvUcrgoPVPvuJKmKlemBLGqJhz5raOgL8Cu09ttnHh9zi9fz/XD2uR
FFJ603xJDBqHGAG3FVS9EHaTdIFq7kSgVKn90BGdR/gxYR5oCt9DHbOzpI9S0DC5
o580CvtMHRfN1mUwhmxt8oU1E5obRvHlwQ2R4kVl90DBmPNRNXMiWziKjaVyKVng
IXR2ERfCb1HurZfoOlcmhw0Aod7sJpjubf/tm9CDdRIkMdKkeuKBqWbanzHJTlJG
2GOH2Q0CNp1HscFO+DKsCPBMa8zLAPuN0AF//o8URzXElwFiAfQNMjK8hOFVBI2y
6OR/WUvwlXUs47+9QJX7mLTjTJIgcHsxZF9amX37jXKiL5iZyDUJD9wxcFL6A1ut
eVntC36Fp6yx8zROAex0hNx68LHTILUh5bDi3N9gTnpplWpCn02GNkQi18GQLk4Z
Y34WipxwGImbJooGveHh8nH6v/6V4fOy1SaxaV5q4EL563wGrRlIZ9/POgWeJoas
D5S7aJgXCw0GLTJFZCEDORUTCv73HgxR7zSlyqup2qR0Tjqv/JWTCfqCSRLJ8Ktc
PVKf2Alx6ycVFbh9XhQUKWT4tLm1KywpTUvZe+K0DMfw28dbRREnRyFVqbId8JmX
LJgbHTVxRCs=
=Fx+f
-----END PGP SIGNATURE-----

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

[Petr Baudis]

Dear diary, on Thu, Apr 21, 2005 at 04:53:33AM CEST, I got a letter
where Bryan Donlan <bdonlan@bd.beginyourfear.com> told me that...
> Fast-forwarding 55f9d5042603fff4ddfaf4e5f004d2995286d6d3 ->
> 7a4c67965de68ae7bc7aa1fde33f8eb9d8114697
> 	on top of 55f9d5042603fff4ddfaf4e5f004d2995286d6d3...
> patch: **** Only garbage was found in the patch input.
> 
> I'm on debian testing, patch 2.5.9. It seems to apply the changes
> despite this error.

Harmless, and fixed in latest.

Thanks for the report,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor