[ANNOUNCE] GIT 1.5.0-rc3

It's been a week and a half, and here comes the -rc3

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

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

Hopefully this will be the last -rc before the final 1.5.0.

This contains the "git user's manual" by J. Bruce Fields.  While
it still has its own "To Do" section, it has already been in a
very good shape for some time, giving information with coherence
and guiding a new user in a carefully chosen order of topics
into much more pleasant git experience than before.

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

Changes since v1.5.0-rc2 are as follows:

Alex Riesen (5):
  Insert ACTIVESTATE_STRING in Git.pm
  Force Activestate Perl to tie git command pipe handle to a handle class
  Cleanup uninitialized value in chomp
  Allow default core.logallrefupdates to be overridden with template's config
  Fix git-update-index to work with relative pathnames.

Alexandre Julliard (1):
  vc-git.el: Take into account the destination name in vc-checkout.

Andy Parkins (5):
  New files in git weren't being downloaded during CVS update
  If abbrev is set to zero in git-describe, don't add the unique suffix
  Allow the tag signing key to be specified in the config file
  UNIX reference time of 1970-01-01 00:00 is UTC timezone, not local time zone
  Heavily expanded update hook to send more useful emails than the old hook

Aneesh Kumar K.V (2):
  blameview: Use git-cat-file to read the file content.
  Update git-cat-file documentation

Bill Lear (1):
  Document --check option to git diff.

David Kågedal (1):
  Improved error message from git-rebase

Eric Wong (1):
  git-svn: remove leading slash when printing removed directories

J. Bruce Fields (31):
  Documentation: add git user's manual
  Documentation: expand preface and todo's
  Documentation: git-rebase discussion, miscellaneous user-manual updates
  Documentation: more user-manual todo's
  Documentation: reorder development section, todo's
  Documentation: begin discussion of git-remote in user manual
  Documentation: rev-list -> rev-parse, other typos, start examples
  user manual: answer some comments from Junio
  user-manual: replace init-db by init
  user-manual: reindent
  user-manual:  rewrap, fix heading levels
  user-manual: add "quick start" as chapter 1
  user-manual: minor quickstart reorganization
  user-manual: clarify difference between tag and branch
  user-manual: update references discussion
  user-manual: update git-gc discussion
  user-manual: stub discussion of fsck and reflog
  user-manual: reorganize fetch discussion, add internals, etc.
  user-manual: git-fsck, dangling objects
  user-manual: fsck-objects -> fsck
  user-manual: repo-config -> config
  user-manual: add references to git-config man page
  user-manual: typo fix
  user-manual: fix a header level
  user-manual: reflogs, other recovery
  user-manual: rewrap a few long lines
  user-manual: minor "TODO" updates
  user-manual: document git-show-branch example
  user-manual: SHA1 -> object name
  user-manual: point to README for gitweb information
  user-manual: todo's

Jakub Narebski (3):
  Documentation/config.txt: Document config file syntax better
  t/t1300-repo-config.sh: value continued on next line
  Documentation/config.txt: Correct info about subsection name

Jason Riedy (1):
  Use inttypes.h rather than stdint.h.

Jeff King (4):
  format-patch: fix bug with --stdout in a subdirectory
  contrib/vim: update syntax for changed commit template
  diffcore-pickaxe: fix infinite loop on zero-length needle
  Add a sample program 'blameview' to show how to use git-blame --incremental

Johannes Schindelin (2):
  annotate: use pager
  reflog inspection: introduce shortcut "-g"

Johannes Sixt (1):
  Add a missing fork() error check.

Junio C Hamano (43):
  User manual: fix typos in examples
  Documentation/tutorial-2: Fix interesting typo in an example.
  Revert "prune: --grace=time"
  Make sure git_connect() always give two file descriptors.
  is_repository_shallow(): prototype fix.
  shallow repository: disable unsupported operations for now.
  git-gc: do not run git-prune by default.
  cvsimport: activate -a option, really.
  .mailmap: fix screw-ups in Uwe's name
  honor --author even with --amend, -C, and -c.
  reflog gc: a tag that does not point at a commit is not a crime.
  git-checkout -m: fix merge case
  git-daemon documentation on enabling services.
  ls-remote and clone: accept --upload-pack=<path> as well.
  Refactor the pack header reading function out of receive-pack.c
  Allow fetch-pack to decide keeping the fetched pack without exploding
  fetch-pack: remove --keep-auto and make it the default.
  Consolidate {receive,fetch}.unpackLimit
  Allow non-developer to clone, checkout and fetch more easily.
  parse-remote: do not barf on a remote shorthand without any refs to fetch.
  show-branch -g: default to HEAD
  Documentation: pack-refs --all vs default behaviour
  Make sure we do not write bogus reflog entries.
  git-merge: leave sensible reflog message when used as the first level UI.
  create_symref: check error return from open().
  write_in_full: size_t is unsigned.
  Don't force everybody to call setup_ident().
  git-blame --porcelain: quote filename in c-style when needed.
  Update describe documentation.
  Document 'git-blame --incremental'
  git-fsck-objects is now synonym to git-fsck
  Two small typofixes.
  lock_any_ref_for_update(): do not accept malformatted refs.
  git-commit -s: no extra space when sign-offs appear at the end already.
  git-blame: somewhat better commenting.
  git-send-email: remove debugging output.
  Fix git-tag -u
  Documentation: "git-checkout <tree> <path>" takes any tree-ish
  t9200: Re-code non-ascii path test in UTF-8
  t9200: do not test -x bit if the filesystem does not support it.
  git main documentation: point at the user's manual.
  Do not use hardcoded path to xhmtl.xsl to generate user's manual
  GIT v1.5.0-rc3

Linus Torvalds (5):
  fsck-objects: refactor checking for connectivity
  Fix seriously broken "git pack-refs"
  Add dangling objects tips.
  git-blame --incremental
  git-push through git protocol

Mark Wooding (3):
  wt-status: Actually accept `color.status.BLAH' configuration variables.
  Documentation/config.txt: Fix documentation of colour config tweaks.
  Make fsck and fsck-objects be builtins.

Nicolas Pitre (3):
  fix suggested branch creation command when detaching head
  git-log -g --pretty=oneline should display the reflog message
  tone down the detached head warning

Peter Eriksen (2):
  sha1_file.c: Avoid multiple calls to find_pack_entry().
  Documentation: --amend cannot be combined with -c/-C/-F.

René Scharfe (1):
  git-blame --incremental: don't use pager

Sam Vilain (1):
  contrib/emacs/vc-git.el: support vc-version-other-window

Santi Béjar (1):
  git-fetch: Allow fetching the remote HEAD

Shawn O. Pearce (6):
  Remove unnecessary found variable from describe.
  Teach git-describe to display distances from tags.
  Compute accurate distances in git-describe before output.
  Teach for-each-ref about a little language called Tcl.
  Don't coredump on bad refs in update-server-info.
  Escape --upload-pack from expr.

Simon 'corecode' Schubert (1):
  Replace perl code with pure shell code

Tom Prince (1):
  Rename git-repo-config to git-config.

Uwe Kleine-König (2):
  rename --exec to --upload-pack for fetch-pack and peek-remote
  make --upload-pack option to git-fetch configurable

On Wednesday, January 31, 2007 at 16:26:36 (-0800) Junio C Hamano writes:

It's been a week and a half, and here comes the -rc3

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

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

There are no such files .*1.5.0-rc3.* on this server.  However, there
are .*1.5.0.rc3.* files.


Bill

torsdag 01 februari 2007 01:26 skrev Junio C Hamano:

Junio C Hamano (43):
  t9200: Re-code non-ascii path test in UTF-8

I sent a patch that converts to "visible" characters when looked
at with iso-8859-1/windows-1252 googles. It also tests the file system before 
executing the test. 

  t9200: do not test -x bit if the filesystem does not support it.

The description is misleading. Git on cygwin chooses to ignore the executable 
flag by default, not because the filesystem won't handle it, but rather that 
enough many *other* applications sets it needlessly, that ignoring it becomes 
less problematic than honouring it.

Adding "git config core.filemode true" at the start of this test verifiies 
that it works on NTFS too. 

-- robin

Thanks everybody for helping to tie the loose ends for the next
release.

Thanks to Nico's handful updates, I think his "reflog on HEAD
itself" series is ready for inclusion, although tonight's update
still has it parked in 'next' (I did try out 'next' with his
latest for a couple of hours today).  I've already updated the
draft release notes for 1.5.0 (v1.5.0.txt in todo branch), with
its inclusion in mind.

I've re-read the three tutorials and tried to fix them up
somewhat to match the recent reality.  I'd appreciate somebody
can look at JBF's user manual.

Several things to note (in the following, substitute $gmane with
http://article.gmane.org/gmane.comp.version-control.git):

 - Working around Tk geometry problem, especially on non Linux+X
   platforms.  I've forwarded Mark Levedahl's patches
   ($gmane/38361) to Paul Mackerras for his blessing; hopefully
   he can Ack and/or suggest improvements.  I'd really like to
   have them in 1.5.0 in some form.

 - Nico's "reflog on HEAD".  I'll merge this tomorrow (I just
   ran out of time today).  I will re-try to break its "git
   reflog expire --stale-fix --all" before actually merging it,
   though.

 - Reverting the patch to allow tracking branch names as the
   value of branch.*.merge ($gmane/38621).  I think it is a good
   idea to revert this before 1.5.0 gets out; just haven't got
   around to do so.

 - Teaching "git blame" to also use the working tree files
   and/or index.  I actually think defaulting to working tree
   when an explicit HEAD is not given (and --cached to use the
   one in the index) makes a lot of sense, but I haven't got
   around to code the latter yet.  Not defaulting to HEAD
   changes semantics, so if we ever are going to do it, I think
   we should do so before 1.5.0.

 - Preventing push from updating the current branch of non-bare
   repository.  I think doing so unconditionally is a bad idea
   (and I have Linus's veto to back it up $gmane/38592), but I
   suspect most people would want the default to be less
   confusing to new people.  If we are ever going to forbid by
   default and allow pusher to force, that would be a behaviour
   change and it would be better to do so before 1.5.0.

 - We might want to allow git-push to use the wildcard refspec,
   like git-fetch does, for symmetry.  It would make the
   mothership-satellite arrangement much more natural
   ($gname/38549).  Unfortunately I haven't had a chance to
   start coding it.  I think however this could be added post
   1.5.0.

 - "git remote add -t -f -m" and rewrite of "git clone" based on
   it ($gmane/38470, $gmane/38545).  While I think this leads us
   in right direction, I do not think 1.5.0 needs to wait for
   it.  Certainly I do not want to reimplement "git clone"
   before 1.5.0, although I think the additions to "git remote add"
   are relatively safe.

 - Catering to filesystems whose readdir() returns pathnames
   that are different from what are used when they were creat()ed
   will not happen ($gmane/38620).


* The 'master' branch has these since v1.5.0-rc3.

 Andy Parkins (1):
  doc: hooks.txt said post-commit default sends an email, it doesn't

 Eric Wong (2):
  git-svn: do not let Git.pm warn if we prematurely close pipes
  Disallow invalid --pretty= abbreviations

 Johannes Schindelin (2):
  Teach the '@{...}' notation to git-log -g
  Update the documentation for the new '@{...}' syntax

 Junio C Hamano (9):
  detached HEAD -- finishing touches
  Use "git checkout -q" in git-bisect
  Tutorial: fix asciidoc formatting of "git add" section.
  Tutorial-2: Adjust git-status output to recent reality.
  core-tutorial: http reference link fix
  fix reflog entries for "git-branch"
  honor GIT_REFLOG_ACTION in git-commit
  Why is it bad to rewind a branch that has already been pushed out?
  combine-diff: special case --unified=0

 Mike Coleman (1):
  Fix some documentation typos and grammar

 Nicolas Pitre (4):
  reword the detached head message a little again
  add a quiet option to git-checkout
  prevent HEAD reflog to be interpreted as current branch reflog
  provide a nice @{...} syntax to always mean the current branch reflog

 Pavel Roskin (2):
  git-config --rename-section could rename wrong section
  Assorted typo fixes

 Shawn O. Pearce (18):
  Pull out remote listing functions in git-remote.
  Teach 'git remote' how to cleanup stale tracking branches.
  Cleanup prepare_packed_git_one to reuse install_packed_git.
  Correct comment in prepare_packed_git_one.
  Refactor open_packed_git to return an error code.
  Don't find objects in packs which aren't available anymore.
  Don't leak file descriptors from unavailable pack files.
  Cleanup subcommand documentation for git-remote.
  Keep untracked files not involved in a merge.
  Default GIT_MERGE_VERBOSITY to 5 during tests.
  bash: Remove short option completions for branch/checkout/diff.
  bash: Classify cat-file and reflog as plumbing.
  bash: Complete long options to git-add.
  bash: Add space after unique command name is completed.
  bash: Classify more commends out of completion.
  bash: Support unique completion on git-config.
  bash: Support unique completion when possible.
  bash: Support internal revlist options better.

On Sun, Feb 04, 2007 at 01:36:29AM -0800, Junio C Hamano wrote:

 - Teaching "git blame" to also use the working tree files
   and/or index.  I actually think defaulting to working tree
   when an explicit HEAD is not given (and --cached to use the
   one in the index) makes a lot of sense, but I haven't got
   around to code the latter yet.  Not defaulting to HEAD
   changes semantics, so if we ever are going to do it, I think
   we should do so before 1.5.0.

Just a thought, but it might be useful to blame the contents of an
arbitrary file (but starting the history at a given pathname). Something
like "git blame --contents /tmp/foo.c file.c", with contents defaulting
to "file.c". There's much discussion of editor interfaces, and this
leaves the possibility of git-blaming the contents of the editor buffer
(after writing it out to a temp file) without having to save changes to
the working tree file.

Admittedly, I think this will be rare, but if you git-blame from an
editor, it seems awkward to either be inaccurate (by blaming the last
saved working tree file, but comparing it to the buffer) or to save the
file as a side effect.

-Peff

On Sun, 4 Feb 2007, Jeff King wrote:

Just a thought, but it might be useful to blame the contents of an
arbitrary file (but starting the history at a given pathname). Something
like "git blame --contents /tmp/foo.c file.c", with contents defaulting
to "file.c". There's much discussion of editor interfaces, and this
leaves the possibility of git-blaming the contents of the editor buffer
(after writing it out to a temp file) without having to save changes to
the working tree file.

I agree, that probably would make most sense. If we do this at all. On the 
other hand, I suspect that most editors would probably want to pipe the 
contents to the program, not write it to a temp-file.

(I think it's a worthy feature, but Junio's patch wasn't exactly pretty, 
so the question boils down to whether it's really worth it).

		Linus

On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote:

On Sun, 4 Feb 2007, Jeff King wrote:

quoted

Just a thought, but it might be useful to blame the contents of an
arbitrary file (but starting the history at a given pathname). Something
like "git blame --contents /tmp/foo.c file.c", with contents defaulting
to "file.c". There's much discussion of editor interfaces, and this
leaves the possibility of git-blaming the contents of the editor buffer
(after writing it out to a temp file) without having to save changes to
the working tree file.

I agree, that probably would make most sense. If we do this at all. On the 
other hand, I suspect that most editors would probably want to pipe the 
contents to the program, not write it to a temp-file.

... and use it with --incremental, as well.  In emacs you can have the
annotation take place as it is being written out relatively easily, by
arranging to have a callback function get called each time more
information is handed back to emacs via a pipe.

						- Ted

Theodore Tso wrote:

On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote:

quoted

On Sun, 4 Feb 2007, Jeff King wrote:

quoted

Just a thought, but it might be useful to blame the contents of an
arbitrary file (but starting the history at a given pathname). Something
like "git blame --contents /tmp/foo.c file.c", with contents defaulting
to "file.c". There's much discussion of editor interfaces, and this
leaves the possibility of git-blaming the contents of the editor buffer
(after writing it out to a temp file) without having to save changes to
the working tree file.

I agree, that probably would make most sense. If we do this at all. On the 
other hand, I suspect that most editors would probably want to pipe the 
contents to the program, not write it to a temp-file.

... and use it with --incremental, as well.  In emacs you can have the
annotation take place as it is being written out relatively easily, by
arranging to have a callback function get called each time more
information is handed back to emacs via a pipe.

So perhaps instead of "git blame --contents /tmp/foo.c file.c" we should
have "cat /tmp/foo.c | git blame --stdin file.c", hmmm? Editor would then
pipe current contents of the buffer to "git blame --stdin --incremental
file.c" (where file.c is the name in tree/in HEAD).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Jakub Narebski [off-list ref] writes:

Theodore Tso wrote:

quoted

On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote:

quoted

On Sun, 4 Feb 2007, Jeff King wrote:

quoted

Just a thought, but it might be useful to blame the contents of an
arbitrary file (but starting the history at a given pathname). Something
like "git blame --contents /tmp/foo.c file.c", with contents defaulting
to "file.c". There's much discussion of editor interfaces, and this
leaves the possibility of git-blaming the contents of the editor buffer
(after writing it out to a temp file) without having to save changes to
the working tree file.

I agree, that probably would make most sense. If we do this at all. On the 
other hand, I suspect that most editors would probably want to pipe the 
contents to the program, not write it to a temp-file.

... and use it with --incremental, as well.  In emacs you can have the
annotation take place as it is being written out relatively easily, by
arranging to have a callback function get called each time more
information is handed back to emacs via a pipe.

So perhaps instead of "git blame --contents /tmp/foo.c file.c" we should
have "cat /tmp/foo.c | git blame --stdin file.c", hmmm? Editor would then
pipe current contents of the buffer to "git blame --stdin --incremental
file.c" (where file.c is the name in tree/in HEAD).

But if we allow the standard convention of using - to mean stdin, the
--contents option would be more flexible, since "--contents -" would
just be a special case.

-- 
David Kågedal