The latest feature release GIT 1.4.3 is available at the usual
places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.4.3.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.4.3.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.4.3.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.4.3-1.$arch.rpm	(RPM)

Please holler if i386 RPMs are broken, since they are not cut on
the machine I am used to use (I ended up burning half a day
installing and futzing with FC5 on my older laptop resurrected
from the boneyard).

User visible changes, other than bugfixes, since v1.4.2.4 are:

 - upload-tar is deprecated but not removed; we now have
   upload-archive --format=tar and --format=zip instead.

 - ftp:// protocol is supported the same way as http:// and
   https://

 - git-diff paginates its output to the tty by default.  If this
   irritates you, using LESS=RF might help.

 - git-cherry-pick does not leave often useless "cherry-picked
   from" message.

 - git-merge-recursive was replaced by a rewritten implemention
   in C.  The original Python implementation is available as
   "recursive-old" strategy for now, but hopefully we can remove
   it in the next cycle.

 - git-daemon can do name based virtual hosting.

 - git-daemon can serve tar and zip snapshots.

 - many gitweb tweaks and cleanups.

 - git-apply --reverse, --reject.

 - git-diff --color highlights whitespace errors.

 - git-diff --stat can be taught to use non-default widths.

 - git-status can use colors.

 - many more commands are built-in.

----------------------------------------------------------------

 .gitignore                                         |   10 +-
 Documentation/Makefile                             |    4 +-
 Documentation/asciidoc.conf                        |    1 +
 Documentation/config.txt                           |   34 +
 Documentation/core-tutorial.txt                    |    2 +-
 Documentation/cvs-migration.txt                    |    2 +-
 ...
[ message continues ]

Huh?!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513
-

[ message continues ]

I am considering the following to address irritation some people
(including me, actually) are experiencing with this change when
viewing a small (or no) diff.  Any objections?

diff --git a/pager.c b/pager.c
index dcb398d..8bd33a1 100644
--- a/pager.c
+++ b/pager.c
@@ -50,7 +50,7 @@ void setup_pager(void)
 	close(fd[0]);
 	close(fd[1]);
 
-	setenv("LESS", "-RS", 0);
+	setenv("LESS", "FRS", 0);
 	run_pager(pager);
 	die("unable to execute pager '%s'", pager);
 	exit(255);

-

[ message continues ]

Not from me. I use "git diff" just to check that the tree is empty, and 
the fact that it now throws me into an empty pager is irritating.

That said, "LESS=FRS" doesn't really help that much. It still clears the 
screen. Using "LESS=FRSX" fixes that, but the alternate display sequence 
is actually nice _if_ the pager is used.

Still, I think I'd prefer FRSX as the default.

		Linus
-

[ message continues ]

Hmm, what terminal emulator do you use? The reasonable ones should
restore the original screen. At least xterm does, and I *think*
gnome-terminal does too (although I'm too lazy to boot up my notebook
and confirm).

(I personally consider alternate screen an abomination. It would be so
nice if the terminal emulators would just make it optional.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
-

[ message continues ]

Not xterm, at least.

Not gnome-terminal either, for that matter.

I just tried.

	LESS=FRS git diff

clears the screen and leaves the thing at the end.

	LESS=FRSX git diff

works fine, but for people who _like_ the alternate screens (and I do, 
once I really use a pager) it also disables the alternate screen.

It might depend on the termcap, of course. I'm running FC5.

		Linus
-

[ message continues ]

$ xterm -rm "*titeInhibit: true"

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstra
[ message continues ]

Speaking of irritations...  There is a major (and AFAICS fixable)
suckitude in git-cherry.  Basically, what it does is
	* use git-rev-list to find commits on our branches
	* do git-diff-tree -p for each commit
	* do git-patch-id on each delta
	* compare sets.
For one thing, there are better ways to do set comparison than creating
a file for each element in one set and going through another checking
if corresponding files exist (join(1) and sort(1) or just use perl hashes).
That one is annoying on journalling filesystems (a lot of files being
created, read and removed - fsckloads of disk traffic), but it's actually
not the worst problem.

Far more annoying is that we keep recalculating git-diff-tree -p | git-patch-id
again and again; try to do git cherry on a dozen short branches forked at
2.6.18 and you'll see the damn thing recalculated a dozen of times for
each commit from 2.6.18 to current.  It's not cheap, to put it mildly.

git-rev-list ^v2.6.18 HEAD|while read i; do git-diff-tree -p $i; done |git-patch-id >/dev/null

out of hot cache on 2GHz amd64 box (Athlon 64 3400+) takes 3 minutes of
wall time.  Repeat that for each branch and it's starting to get old very
fast.

Note that we are calculating a function of commit; it _never_ changes.
Even if we don't just calculate and memorize it at commit time, a cache
somewhere under .git would speed the things up a lot...
-

[ message continues ]

Yeah, that sucks big time.  I never realized there are people
who still are using it, though. git-format-patch used to use it,
but the version was retired exactly five months ago, and there
is no in-tree users anymore.

I guess we could separate out the revision filtering logic in
builtin-log.c:cmd_format_patch() and implement git-cherry as a
new built-in.



-

[ message continues ]

Huh?  If you have a saner way to do reordering/changeset-by-changeset
rebasing of branches...  git-cherry followed by selective cherry-pick
works and is much more convenient than messing with implementing what
I need via git-am and shitloads of editing...
-

[ message continues ]

How about this patch?  It does away with using temporary files and instead
creates persistent cache files under .git/patch-ids/.  It is a very stupid
cache layout: file name = commit SHA1, file contents = patch ID.  Perhaps
it needs fan-out directories like .git/objects/ has before it can be
considered for merge.

The set compare is stupid, too, but at least it is in-shell now, using a
space separated list and the is_in function.

And the cache file creation is not safe for multiple parallel git-cherry's.

It survives "make test" and is otherwise untested.  Care to test drive
this prototype? :-D

Thanks,
Ren
[ message continues ]

I think this is an excellent idea.


Nicolas
-

[ message continues ]

So for me, if I run

	less -FRS file

where "file" is less than a page, I see nothing happen whatsoever.

At a guess, maybe it's clearing the screen, displaying the file, the
restoring, all before I see anything happen?

--b.
-

[ message continues ]

Junio,

How about reverting this change? From the reports here, is causing 
problems on a number of different distributions.

These settings are probably something that is better set by the user in 
an environment variable. Or, make the default something that does work 
everywhere and have a config item for those that wish to customize their UI.
-

[ message continues ]

(Um, sorry for my mail screwups, by the way....)

--b.
-

[ message continues ]

Hmmm.  I thought I was using gnome-terminal as well, but I
always work in screen and did not see this problem.

Sorry, but you are right and Linus is more right.  How about
doing FRSX.

diff --git a/pager.c b/pager.c
index 8bd33a1..4587fbb 100644
--- a/pager.c
+++ b/pager.c
@@ -50,7 +50,7 @@ void setup_pager(void)
 	close(fd[0]);
 	close(fd[1]);
 
-	setenv("LESS", "FRS", 0);
+	setenv("LESS", "FRSX", 0);
 	run_pager(pager);
 	die("unable to execute pager '%s'", pager);
 	exit(255);

-

[ message continues ]

Dear diary, on Mon, Oct 23, 2006 at 05:27:49AM CEST, I got a letter

I should like that solution more since I hate the alternate screen, but
I actually don't, since it should be left at the user's will whether to
use the alternate screen or not, and Git shouldn't change the default on
whim. Git is trying to be too smart here, and I think it's more annoying
to override what the user is used to than having to by default press q.

Yes, the user can always override Git by setting own $LESS, but that
means another explicit action at the user's side is required and they
don't receive any further cool flags we might stick in there later.
(BTW, I don't think this is right either. In Cogito, I do

	LESS="$myflags$LESS"

unless $CG_LESS is set, in which case I do

	LESS="$CG_LESS".

So people like Jens who have LESS set still get sensible behaviour from
Cogito _and_ they don't loose the ability to override Cogito's less
flags.)

BTW, I think not seeing output of paged commands is a major problem,
this should probably warrant another bugfix release.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
-

[ message continues ]

I'm a little confused by all this because I
set the LESS environment variable by myself
already.  And I use the value that I like.
Why change it or override the user's settings
like this?  Or did I miss something?

Thanks,
jdl


-

[ message continues ]

This is about "if user does not set it, use this default".


-

[ message continues ]