threads / announce / 12274

[ANNOUNCE] GIT 1.5.4.3

Subject: [ANNOUNCE] GIT 1.5.4.3

## tl;dr

7 messages between Feb 23, 2008 and Mar 11, 2008.

replies: 6people: 2as markdown or json

Junio C Hamano· Feb 23, 2008, 21:07 UTC · lore

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
Junio C Hamano· Mar 9, 2008, 10:46 UTC · re: Junio C Hamano · lore

[ANNOUNCE] GIT 1.5.4.4

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
Jeff Garzik· Mar 9, 2008, 16:56 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 1.5.4.4

Junio C Hamano wrote:
Show 9 quoted lines
> 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
Junio C Hamano· Mar 9, 2008, 20:28 UTC · re: Jeff Garzik · lore

Re: [ANNOUNCE] GIT 1.5.4.4

Jeff Garzik <jeff@garzik.org> writes:
Show 14 quoted lines
> 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...

Jeff Garzik· Mar 9, 2008, 21:42 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 1.5.4.4

Junio C Hamano wrote:
Show 19 quoted lines
> 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.

Show 5 quoted lines
> 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
Junio C Hamano· Mar 10, 2008, 06:34 UTC · re: Jeff Garzik · lore

Re: [ANNOUNCE] GIT 1.5.4.4

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?

Jeff Garzik· Mar 11, 2008, 19:11 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 1.5.4.4

Junio C Hamano wrote:
Show 11 quoted lines
> 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.
Show 9 quoted lines
> 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

← back to recent threads