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

  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,

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...

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).

On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:

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

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 20 April 2005 17:51, Mike Taht wrote:

Hmm...got to disagree, cg is perfectly comfortable to type here on my dvorak, whilst asdf ad jkl are uncomfortable deviations accross the board ;-)

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...

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. ;-)

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

Randy.Dunlap wrote:

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

On Wed, 20 Apr 2005, Petr Baudis 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, 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

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...

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.

On Thu, Apr 21, 2005 at 12:28:15AM +0200, Petr Baudis wrote:

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

thanks,

greg k-h

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

On Wed, 20 Apr 2005, 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..

		Linus

---- gitlog.sh: a496a864f9586e47a4d7bd3ae0af0b3e07b7deb8

On Wed, Apr 20, 2005 at 06:12:34PM -0700, Linus Torvalds wrote:

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.

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

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

On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:

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

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

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.

On Wed, Apr 20, 2005 at 09:00:44PM -0700, Linus Torvalds wrote:

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.

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...

... 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 Baudis wrote:

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.

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...

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.

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

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

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

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

On Wed, Apr 20, 2005 at 06:12:34PM -0700, Linus Torvalds wrote:

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

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

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

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

Linus Torvalds wrote:

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 wrote:

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

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

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

Linus Torvalds <torvalds@osdl.org> wrote:

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 ;)

-----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-----

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...

Harmless, and fixed in latest.

Thanks for the report,