[ANNOUNCE] GIT 1.5.4.3

[ANNOUNCE] GIT 1.5.4.3

[Junio C Hamano]

The latest maintenance release GIT 1.5.4.3 is available at the
usual places:

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

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

Largest user visible change in this is RPM packaging updates by
Kristian Høgsberg.  'git-core' will only be pure git without
pulling foreign SCM packages in as its dependencies anymore when
you do "yum install git-core".

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

GIT v1.5.4.3 Release Notes
==========================

Fixes since v1.5.4.2
--------------------

 * RPM spec used to pull in everything with 'git'.  This has been
   changed so that 'git' package contains just the core parts,
   and we now supply 'git-all' metapackage to slurp in everything.
   This should match end user's expectation better.

 * When some refs failed to update, git-push reported "failure"
   which was unclear if some other refs were updated or all of
   them failed atomically (the answer is the former).  Reworded
   the message to clarify this.

 * "git clone" from a repository whose HEAD was misconfigured
   did not set up the remote properly.  Now it tries to do
   better.

 * Updated git-push documentation to clarify what "matching"
   means, in order to reduce user confusion.

 * Updated git-add documentation to clarify "add -u" operates in
   the current subdirectory you are in, just like other commands.

 * git-gui updates to work on OSX and Windows better.

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

Changes since v1.5.4.2 are as follows:

Gerrit Pape (1):
      git-clone.sh: properly configure remote even if remote's head is dangling

Jay Soffian (2):
      git-gui: support Git Gui.app under OS X 10.5
      send-email: squelch warning due to comparing undefined $_ to ""

Jeff King (4):
      push: indicate partialness of error message
      Documentation/push: clarify matching refspec behavior
      push: document the status output
      hash: fix lookup_hash semantics

Junio C Hamano (1):
      GIT 1.5.4.3

Kristian H淡gsberg (1):
      Rename git-core rpm to just git and rename the meta-pacakge to git-all.

Miklos Vajna (1):
      Documentation/git-stash: document options for git stash list

Pekka Kaitaniemi (1):
      Clarified the meaning of git-add -u in the documentation

Shawn O. Pearce (5):
      git-gui: Ensure error dialogs always appear over all other windows
      git-gui: Paper bag fix error dialogs opening over the main window
      git-gui: Default TCL_PATH to same location as TCLTK_PATH
      git-gui: Avoid hardcoded Windows paths in Cygwin package files
      git-gui: Focus insertion point at end of strings in repository chooser

Wincent Colaiuta (1):
      git-gui: relax "dirty" version detection

[ANNOUNCE] GIT 1.5.4.4

[Junio C Hamano]

The latest maintenance release GIT 1.5.4.4 is available at the
usual places:

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

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

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

GIT v1.5.4.4 Release Notes
==========================

Fixes since v1.5.4.3
--------------------

 * Building and installing with an overtight umask such as 077 made
   installed templates unreadable by others, while the rest of the install
   are done in a way that is friendly to umask 022.

 * "git cvsexportcommit -w $cvsdir" misbehaved when GIT_DIR is set to a
   relative directory.

 * "git http-push" had an invalid memory access that could lead it to
   segfault.

 * When "git rebase -i" gave control back to the user for a commit that is
   marked to be edited, it just said "modify it with commit --amend",
   without saying what to do to continue after modifying it.  Give an
   explicit instruction to run "rebase --continue" to be more helpful.

 * "git send-email" in 1.5.4.3 issued a bogus empty In-Reply-To: header.

 * "git bisect" showed mysterious "won't bisect on seeked tree" error message.
   This was leftover from Cogito days to prevent "bisect" starting from a
   cg-seeked state.  We still keep the Cogito safety, but running "git bisect
   start" when another bisect was in effect will clean up and start over.

 * "git push" with an explicit PATH to receive-pack did not quite work if
   receive-pack was not on usual PATH.  We earlier fixed the same issue
   with "git fetch" and upload-pack, but somehow forgot to do so in the
   other direction.

 * git-gui's info dialog was not displayed correctly when the user tries
   to commit nothing (i.e. without staging anything).

 * "git revert" did not properly fail when attempting to run with a
   dirty index.

 * "git merge --no-commit --no-ff <other>" incorrectly made commits.

 * "git merge --squash --no-ff <other>", which is a nonsense combination
   of options, was not rejected.

 * "git ls-remote" and "git remote show" against an empty repository
   failed, instead of just giving an empty result (regression).

 * "git fast-import" did not handle a renamed path whose name needs to be
   quoted, due to a bug in unquote_c_style() function.

 * "git cvsexportcommit" was confused when multiple files with the same
   basename needed to be pushed out in the same commit.

 * "git daemon" did not send early errors to syslog.

 * "git log --merge" did not work well with --left-right option.

 * "git svn" promprted for client cert password every time it accessed the
   server.

 * The reset command in "git fast-import" data stream was documented to
   end with an optional LF, but it actually required one.

 * "git svn dcommit/rebase" did not honor --rewrite-root option.

Also included are a handful documentation updates.

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

Changes since v1.5.4.3 are as follows:

Adeodato Simó (1):
      Really make the LF after reset in fast-import optional

Björn Steinbrink (1):
      receive-pack: Initialize PATH to include exec-dir.

Brandon Casey (1):
      builtin-reflog.c: don't install new reflog on write failure

Bryan Donlan (1):
      Documentation/git-am.txt: Pass -r in the example invocation of rm -f .dotest

Caio Marcelo de Oliveira Filho (1):
      filter-branch documentation: non-zero exit status in command abort the filter

Carl Worth (1):
      Eliminate confusing "won't bisect on seeked tree" failure

Daniel Barkalow (3):
      Use a single implementation and API for copy_file()
      Don't use GIT_CONFIG in t5505-remote
      Correct name of diff_flush() in API documentation

Gerrit Pape (2):
      templates/Makefile: don't depend on local umask setting
      git-merge.sh: better handling of combined --squash,--no-ff,--no-commit options

Jay Soffian (2):
      rev-parse: fix potential bus error with --parseopt option spec handling
      send-email: fix In-Reply-To regression

Jeff King (1):
      revert: actually check for a dirty index

Johan Herland (2):
      Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative $GIT_DIR
      Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR

Johannes Schindelin (4):
      http-push: avoid invalid memory accesses
      http-push: do not get confused by submodules
      http-push: avoid a needless goto
      cvsexportcommit: be graceful when "cvs status" reorders the arguments

Johannes Sixt (2):
      daemon: send more error messages to the syslog
      daemon: ensure that base-path is an existing directory

John Goerzen (1):
      Fix dcommit, rebase when rewriteRoot is in use

Jonathan del Strother (1):
      Prompt to continue when editing during rebase --interactive

Junio C Hamano (6):
      Fix "git log --merge --left-right"
      Start preparing for 1.5.4.4
      tests: introduce test_must_fail
      Update draft release notes for 1.5.4.4
      test-lib: fix TERM to dumb for test repeatability
      GIT 1.5.4.4

Matthieu Moy (1):
      Fix incorrect wording in git-merge.txt.

Mike Hommey (2):
      Set proxy override with http_init()
      Fix random crashes in http_cleanup()

Mike Ralphson (1):
      Documentation cherry-pick: Fix cut-and-paste error

Miklos Vajna (2):
      Documentation/git-filter-branch: add a new msg-filter example
      Documentation/git svn log: add a note about timezones.

Pierre Habouzit (1):
      unquote_c_style: fix off-by-one.

Ping Yin (1):
      git-submodule: Fix typo 'url' which should be '$url'

Rémi Vanicat (1):
      git.el: find the git-status buffer whatever its name is

Santi Béjar (1):
      ident.c: reword error message when the user name cannot be determined

Sebastian Noack (1):
      git-svn: Don't prompt for client cert password everytime.

Shawn O. Pearce (6):
      Ensure 'make dist' compiles git-archive.exe on Cygwin
      Protect peel_ref fallback case from NULL parse_object result
      Correct fast-export file mode strings to match fast-import standard
      git-gui: Paper bag fix info dialog when no files are staged at commit
      Fix 'git remote show' regression on empty repository in 1.5.4
      git-gui: Gracefully fall back to po2msg.sh if msgfmt --tcl fails

Steven Drake (1):
      timezone_names[]: fixed the tz offset for New Zealand.

Uwe Kleine-König (1):
      config.txt: refer to --upload-pack and --receive-pack instead of --exec

Re: [ANNOUNCE] GIT 1.5.4.4

[Jeff Garzik]

Junio C Hamano wrote:
> The latest maintenance release GIT 1.5.4.4 is available at the
> usual places:
> 
>   http://www.kernel.org/pub/software/scm/git/
> 
>   git-1.5.4.4.tar.{gz,bz2}			(tarball)
>   git-htmldocs-1.5.4.4.tar.{gz,bz2}		(preformatted docs)
>   git-manpages-1.5.4.4.tar.{gz,bz2}		(preformatted docs)
>   RPMS/$arch/git-*-1.5.4.4-1.$arch.rpm	(RPM)

Does it address the following issue, present in git-core-1.5.4.1-1.fc8?

http://marc.info/?l=git&m=120423022832530&w=2

Thanks,

	Jeff

Re: [ANNOUNCE] GIT 1.5.4.4

[Junio C Hamano]

Jeff Garzik <jeff@garzik.org> writes:

> Junio C Hamano wrote:
>> The latest maintenance release GIT 1.5.4.4 is available at the
>> usual places:
>>
>>   http://www.kernel.org/pub/software/scm/git/
>>
>>   git-1.5.4.4.tar.{gz,bz2}			(tarball)
>>   git-htmldocs-1.5.4.4.tar.{gz,bz2}		(preformatted docs)
>>   git-manpages-1.5.4.4.tar.{gz,bz2}		(preformatted docs)
>>   RPMS/$arch/git-*-1.5.4.4-1.$arch.rpm	(RPM)
>
> Does it address the following issue, present in git-core-1.5.4.1-1.fc8?
>
> http://marc.info/?l=git&m=120423022832530&w=2

I do not think so.

Is it really an issue, or is it just a warning message unread/unfollowed?

I am comparing the last line you quoted from the command output in that
message, which suggests the user to run 'git prune', and your comment on
the next line in that message that says "I regularly run 'git gc'", and
scratching my head.  I cannot tell if you regularly run 'git prune' or not
from it...

Re: [ANNOUNCE] GIT 1.5.4.4

[Jeff Garzik]

Junio C Hamano wrote:
> Jeff Garzik <jeff@garzik.org> writes:
> 
>> Junio C Hamano wrote:
>>> The latest maintenance release GIT 1.5.4.4 is available at the
>>> usual places:
>>>
>>>   http://www.kernel.org/pub/software/scm/git/
>>>
>>>   git-1.5.4.4.tar.{gz,bz2}			(tarball)
>>>   git-htmldocs-1.5.4.4.tar.{gz,bz2}		(preformatted docs)
>>>   git-manpages-1.5.4.4.tar.{gz,bz2}		(preformatted docs)
>>>   RPMS/$arch/git-*-1.5.4.4-1.$arch.rpm	(RPM)
>> Does it address the following issue, present in git-core-1.5.4.1-1.fc8?
>>
>> http://marc.info/?l=git&m=120423022832530&w=2
> 
> I do not think so.
> 
> Is it really an issue, or is it just a warning message unread/unfollowed?

It's not a warning message, it is an annoying delay that has been added 
to almost -every- local pull, impacting my main kernel workflow.

Further -- as my email demonstrated with examples -- it would repeatedly 
'git gc' on the same repository over and over again, for each 'git pull' 
or 'git rebase' that I did.  That is overly excessive.


> I am comparing the last line you quoted from the command output in that
> message, which suggests the user to run 'git prune', and your comment on
> the next line in that message that says "I regularly run 'git gc'", and
> scratching my head.  I cannot tell if you regularly run 'git prune' or not
> from it...

Yes, I regularly run both 'git gc' and 'git prune'.

But since (ref original email) I was doing some rebasing, there are 
inevitably changesets left dangling after such an operation.

	Jeff

Re: [ANNOUNCE] GIT 1.5.4.4

[Junio C Hamano]

Jeff Garzik <jeff@garzik.org> writes:

> Yes, I regularly run both 'git gc' and 'git prune'.
>
> But since (ref original email) I was doing some rebasing, there are
> inevitably changesets left dangling after such an operation.

Yeah, I'd say it is stupid if "am" ran "gc --auto" for every patch.  I
recall that we had the same issue with git-svn and we made it run once
every 1k round, and we probably should do the same for "am" and "rebase",
running once at the very end.

I notice however that git-am does exactly that.  It runs "gc --auto" only
at the end, and does not run it when it stops upon unapplicable patch.

Perhaps we would want to raise the default "gc --auto" limit?  Currently
when it estimates that you have roughly 6700 objects unpacked it runs
"repack --prune-packed", and if there still are that many unpacked objects
after that, it suggests you to run "git prune" to remove them.  If you are
rebasing, the commits in the old history that are rewritten will _not_
immediately become dangling because they will still be reachable from your
reflog.  If you are getting the message, these objects were already
dangling (ancient commits that are not even reachable from your reflog
entries that are by default kept for 90 days) even before you started your
rebase or am run.

After you finished your day's work on a typical day, what does the output
from "git count-objects -v" and "git fsck-objects" look like, I wonder?

Re: [ANNOUNCE] GIT 1.5.4.4

[Jeff Garzik]

Junio C Hamano wrote:
> Jeff Garzik <jeff@garzik.org> writes:
> 
>> Yes, I regularly run both 'git gc' and 'git prune'.
>>
>> But since (ref original email) I was doing some rebasing, there are
>> inevitably changesets left dangling after such an operation.
> 
> Yeah, I'd say it is stupid if "am" ran "gc --auto" for every patch.  I
> recall that we had the same issue with git-svn and we made it run once
> every 1k round, and we probably should do the same for "am" and "rebase",
> running once at the very end.

> Perhaps we would want to raise the default "gc --auto" limit?  Currently


That seems quite reasonable.  This "feels" like a threshold-too-low problem.



> when it estimates that you have roughly 6700 objects unpacked it runs
> "repack --prune-packed", and if there still are that many unpacked objects
> after that, it suggests you to run "git prune" to remove them.  If you are
> rebasing, the commits in the old history that are rewritten will _not_
> immediately become dangling because they will still be reachable from your
> reflog.  If you are getting the message, these objects were already
> dangling (ancient commits that are not even reachable from your reflog
> entries that are by default kept for 90 days) even before you started your
> rebase or am run.

My workflow generally looks like this:

	# repo was created in this manner....  this was done ONCE,
	# not every time I apply patches

	git clone --reference ../linux-2.6 ../linux-2.6 libata-dev


	# a patch-applying session

	git checkout master
	git pull ../linux-2.6
	git fetch --tags ../linux-2.6	# yes, still necessary...

	git branch -D ALL NEXT
	git branch -D upstream-fixes upstream-linus

	git checkout -b upstream-fixes master
	git-am --utf8 --signoff -i /g/tmp/mbox	# repeat many times...
	git branch upstream-linus upstream-fixes

	git-checkout sii-lbt && git-rebase master
	git-checkout mv-ahci-pata && git-rebase master
	git-checkout new-eh && git-rebase master
	git branch NEXT master
	git branch ALL new-eh

	git checkout master
	git prune
	git push --force --all $URL

Thus, 'git prune' is run on a very regular basis, but 'git gc' is not.

However, I presume the lack of 'git gc' regularity on libata-dev.git is 
mitigated by the fact that I _do_ run 'git gc' regularly on 
linux-2.6.git (listed in libata-dev's alternatives, as noted by 
git-clone statement above)


> After you finished your day's work on a typical day, what does the output
> from "git count-objects -v" and "git fsck-objects" look like, I wonder?

[jgarzik@pretzel libata-dev]$ git count-objects -v
count: 51
size: 244
in-pack: 475
packs: 4
prune-packable: 0
garbage: 0
[jgarzik@pretzel libata-dev]$ git fsck-objects
[jgarzik@pretzel libata-dev]$




As an aside...  a git-debug-info might be a useful command, wrapping up 
everything you (a git developer) would find interesting from me (a 
humble and appreciative git user).  Users could attach the output from 
git-debug-info to emails, when discussing problems in their repositories.

	Jeff