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
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
Jeff Garzik <[email protected]> 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...
Junio C Hamano wrote:
> Jeff Garzik <[email protected]> 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
Jeff Garzik <[email protected]> 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?
Junio C Hamano wrote:
> Jeff Garzik <[email protected]> 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