[Announce] GIT v1.5.0-rc2

This hopefully is pretty much it for 1.5.0 modulo potential bugs especially in newer topics. Aside from many bugfixes, changes since -rc1 are:

 - 'git log' is now reflog aware, and 'git show-branch' which
   knew about reflog already has become much more useful with
   reflogs.

 - the porcelain/ancillary/plumbing categorization in the git
   main documentation has been reviewed and updated.

 - merge and pull operations are much less chatty.

 - operation in a bare repositories is more pleasant.

 - the default file extension for format-patch output is .patch
   now.

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

Bob Proulx (1):
      git-revert: Fix die before git-sh-setup defines it.

Chris Wedgwood (1):
      cache.h; fix a couple of prototypes

David Kågedal (2):
      Shell syntax fix in git-reset
      Document --ignore-if-in-upstream in git-format-patch

Doug Maxey (1):
      gitk: add current directory to main window title

Eric Wong (2):
      git-svn: fix tests to work with older svn
      git-svn: print and flush authentication prompts to STDERR

Jason Riedy (4):
      Start all test scripts with /bin/sh.
      Set _ALL_SOURCE for AIX, but avoid its struct list.
      Replace "echo -n" with printf in shell scripts.
      Solaris 5.8 returns ENOTDIR for inappropriate renames.

Jeff King (1):
      git-pull: disallow implicit merging to detached HEAD

Johannes Schindelin (9):
      Fix spurious compile error
      config_set_multivar(): disallow newlines in keys
      show_date(): fix relative dates
      apply --cached: fix crash in subdirectory
      Do not verify filenames in a bare repository
      Teach the revision walker to walk by reflogs with --walk-reflogs
      --walk-reflogs: disallow uninteresting commits
      --walk-reflogs: actually find the right commit by date.
      --walk-reflogs: do not crash with cyclic reflog ancestry

Junio C Hamano (69):
      reflog-expire: brown paper bag fix.
      merge-recursive: do not report the resulting tree object name
      Explain "Not a git repository: '.git'".
      glossary typofix
      Make git-prune-packed a bit more chatty.
      Define cd_to_toplevel shell function in git-sh-setup
      Use cd_to_toplevel in scripts that implement it by hand.
      Allow whole-tree operations to be started from a subdirectory
      Use log output encoding in --pretty=email headers.
      t3901: test "format-patch | am" pipe with i18n
      git-commit documentation: -a adds and also removes
      Consistent message encoding while reusing log from an existing commit.
      More tests in t3901.
      git log documentation: teach -<n> form.
      Add describe test.
      Documentation: merge-output is not too verbose now.
      Use merge-recursive in git-revert/git-cherry-pick
      git reflog expire: document --stale-fix option.
      Fix git-fetch while on detached HEAD not to give needlessly alarming
        errors
      git-push documentation: remaining bits
      git-rm documentation: remove broken behaviour from the example.
      tutorial: shorthand for remotes but show distributed nature of git
      git-commit documentation: remove comment on unfixed git-rm
      Use merge-recursive in git-checkout -m (branch switching)
      Document where configuration files are in config.txt
      git-commit: document log message formatting convention
      Documentation/SubmittingPatches: Gnus tips
      Documentation/git-tag: the command can be used to also verify a tag.
      Documentation/git-tools.txt: mention tig and refer to wiki
      Documentation/git-tar-tree.txt: default umask is now 002
      Documentation/git-status.txt: mention color configuration
      Documentation/git-whatchanged.txt: show -<n> instead of --max-count.
      Documentation/git-sh-setup.txt: programmer's docs
      Documentation: detached HEAD
      Make a short-and-sweet "git-add -i" synonym for "git-add --interactive"
      Documentation: describe shallow repository
      Documentation/glossary.txt: unpacked objects are loose.
      Documentation/glossary.txt: describe remotes/ tracking and packed-refs
      Introduce 'git-format-patch --suffix=.patch'
      git-format-patch: do not crash with format.headers without value.
      Documentation/git-resolve: deprecated.
      Documentation: suggest corresponding Porcelain-level in plumbing docs.
      Documentation: m can be relative in "git-blame -Ln,m"
      Documentation/git-parse-remote.txt: we deal with config vars as well
      git-format-patch -3
      Add --summary to git-format-patch by default
      git-format-patch: make --binary on by default
      git-format-patch: the default suffix is now .patch, not .txt
      Use fixed-size integers for .idx file I/O
      Documentation: move command list in git.txt into separate files.
      Documentation: sync git.txt command list and manual page title
      Documentation: Generate command lists.
      for_each_reflog_ent: do not leak FILE *
      refs.c::read_ref_at(): fix bogus munmap() call.
      Documentation: generated cmds-*.txt does not depend on git.txt
      Documentation/git.txt: command re-classification
      dwim_ref(): Separate name-to-ref DWIM code out.
      Extend read_ref_at() to be usable from places other than sha1_name.
      show-branch --reflog: show the reflog message at the top.
      show-branch --reflog: tighten input validation.
      show-branch --reflog: fix show_date() call
      Stop ignoring Documentation/README
      git-tag -d: allow deleting multiple tags at once.
      branch -f: no reason to forbid updating the current branch in a
        bare repo.
      git-rebase: allow rebasing a detached HEAD.
      log --walk-reflog: documentation
      reflog-walk: build fixes
      Fix --walk-reflog with --pretty=oneline
      GIT v1.5.0-rc2

Linus Torvalds (2):
      Clean up write_in_full() users
      Fix up totally buggered read_or_die()

Matthias Lederhofer (2):
      prune-packed: add -q to usage
      prune: --grace=time

Michael S. Tsirkin (1):
      fix documentation for git-commit --no-verify

Nicolas Pitre (4):
      use 'init' instead of 'init-db' for shipped docs and tools
      simplify the "no changes added to commit" message
      some doc updates
      sanitize content of README file

Peter Baumann (1):
      Make gitk work when launched in a subdirectory

Quy Tonthat (1):
      git-remote: no longer silent on unknown commands.

René Scharfe (1):
      Documentation: a few spelling fixes

Santi Béjar (1):
      tutorial: Use only separate layout

Shawn O. Pearce (18):
      Improve merge performance by avoiding in-index merges.
      Hide output about SVN::Core not being found during tests.
      Remove read_or_die in favor of better error messages.
      Remove unnecessary call_depth parameter in merge-recursive.
      Allow the user to control the verbosity of merge-recursive.
      Enable output buffering in merge-recursive.
      Display a progress meter during merge-recursive.
      Convert output messages in merge-recursive to past tense.
      Always perfer annotated tags in git-describe.
      Hash tags by commit SHA1 in git-describe.
      Use binary searching on large buckets in git-describe.
      Improve git-describe performance by reducing revision listing.
      Correct priority of lightweight tags in git-describe.
      Remove hash in git-describe in favor of util slot.
      Use nice names in conflict markers during cherry-pick/revert.
      Document the master@{n} reflog query syntax.
      Refer users to git-rev-parse for revision specification syntax.
      Document pack .idx file format upgrade strategy.

Simon 'corecode' Schubert (2):
      Use fixed-size integers for the on-disk pack structure.
      Use standard -t option for touch.

Uwe Kleine-König (4):
      document --exec for git-push
      Update documentation of fetch-pack, push and send-pack
      make --exec=... option to git-push configurable
      rename --exec to --receive-pack for push and send-pack

By the way, was the pager configured to saner values, so "git diff" on a repository with no changes does not output empty page?

What about my Documentation/config.txt changes?

Jakub Narebski <jnareb@gmail.com> writes:

That's been set to the right way since commit 0abc0260 (October 22, 2006, v1.4.3.2~6) as far as I know.

I was not sure about that one, given a lot of commentary in your message, suggesting more research and revision is needed, like these...

Hi,

On Sun, 21 Jan 2007, Jakub Narebski wrote:

As Junio mentioned: it already does. Maybe you have set the environment variable "LESS", and forgot to include "-F"?

Hth, Dscho

On Sunday, January 21, 2007 at 12:08:25 (+0100) Johannes Schindelin writes:

I can't seem to get this to work, no matter what I do, using the latest 1.5.0-rc2 code. I have the environment variables LESS, PAGER, PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my screen each time it is run, no matter the combinations... Could someone post the magic?

Bill

Hi,

On Tue, 23 Jan 2007, Bill Lear wrote:

Try this:

	PAGER=less LESS=-FRS git diff

Hth, Dscho

On Tuesday, January 23, 2007 at 20:12:36 (+0100) Johannes Schindelin writes:

Replied to Johannes off-line and thought this was working --- sorry for the false positive. It is in one regard: it completely suppresses output if there is less than a full screen of output.

If I do this:

% export PAGER=less % unset LESS % git diff

I get 30 lines of output in my current repository, as I should.

If I then do this:

% LESS=-FRS git diff

I get nothing --- I do see a brief blink of output, but it's as if less swallows it whole and I see nothing but the next prompt.

Hmmm ... I do seem to be using a rather old version of less:

% less --version less 382 Copyright (C) 2002 Mark Nudelman

Could this be the culprit? Will try and see... Nope, downloaded, built, and installed less-394 and I still see the same problem. I also see this problem when I do 'man git-gc', for example --- the manpage just disappears.

If I set LESS to '-F' it fails. If set to '-RS', output is seen but then I see the screen blanked when there is no output from git diff.

This is on Centos 4.3. I have not yet tried this on my Fedora Core 6 laptop, at home...

Bill

Hello Bill,

What about:

	LESS=-FRSX git diff

?

HTH Uwe

On Tuesday, January 23, 2007 at 21:22:32 (+0100) Uwe Kleine-König writes:

Well, I see output when there is output to show, yes, but it still blanks the screen --- or, I should say, scrolls all the way to the bottom --- when there is no difference to show.

I do note that if LESS is not set, git sets it (in pager.c) to just what you have above (FRSX).

Bill

Bill Lear wrote:

Ah, OK, now I got it. Sorry, I understood you wrong. Seems like something that needs fixing in less. At least I cannot find an option for that. But I'm not sure that all people would consider that being a bug.

Best regards Uwe

Hi,

On Tue, 23 Jan 2007, Bill Lear wrote:

It works here, with 381 _and_ 376+iso254.

This looks more like a broken terminal interaction to me.

Ciao, Dscho

Bill Lear <rael@zopyra.com> schrieb:

This is propably caused by activating "Enable Alternate Screen Switching" in xterm. If you have this feature enabled, you get a clean screen (no fragments of the displayed file are shown after quitting less). Try to disable it and see if it works.

-Peter

On Tuesday, January 23, 2007 at 22:09:24 (+0100) Peter Baumann writes:

Tried as instructed: I get output when I should get output. However, when I should get no output, it clears/scrolls all the way down to the bottom of the screen (LESS=-FRS git diff).

Bill

[ Added "less" author Mark Nudelman to Cc: ]

On Tue, 23 Jan 2007, Bill Lear wrote:

I think "less" is actually seriously buggy with -F.

There are two bugs:

 - it will always screw up the screen and move to the end. It does this 
   even if you use -FX which should disable any init sequences, so it's 
   not about that problem.

 - if you resize the terminal while less is waiting for input, less
   will exit entirely without even showing the output. This is very
   noticeable if you do something like "git diff" on a big and cold-cache 
   tree and git takes a few seconds to think, and then you resize the 
   window while it's preparing. Boom. No output AT ALL.

Both bugs are easily seen with this simple command line

	clear ; (sleep 5 ; echo Hello) | less -F

where you would EXPECT that the "Hello" would show up at the first line of the screen (since we cleared the screen and moved to the top left corner), but in fact it doesn't.

And try resizing the terminal to make it bigger during the five-second pause, and now you'll see less not show the "Hello" at _all_. It's just gone (this is true even if the output was _more_ than a screen: try with

	(sleep 10 ; yes ) | less -F

and resize the screen, and it will exit silently after 10 seconds - never showing any output at all! Even though the output is obviously bigger than a screen..

Tested with Kterm, gnome-terminal and xterm. They all behave the same for me.

I don't know exactly what the bug is, but I find the "eof" handling very confusing in the less sources. It makes me suspect that there is something that gets confused by the partial read, sets EOF (since we're on the last line), and then thinks that it should quit, since EOF is set.

I dunno. Mark?

		Linus

On 1/23/2007 12:32 PM, Linus Torvalds wrote:

Hi Linus,

The first issue that you mention (that we move to the bottom of the screen before printing the first line) is behavior that has always existed in less. It's not the init sequence that's doing it; less deliberately moves to lowerleft before printing any output that is intended to go at the bottom of the screen, including both file data and the prompt. This was a design decision from the first version of less, and I've never been brave enough to try to find all the places that would be affected by changing this. For example, less tries to keep track of exactly what's displayed on the screen at all times, and it's harder to do this if we don't know whether some output scrolled the screen or not. It may or may not be a big job to make all the changes that would be required. I will move this up the priority list and take a look at it for the next release of less.

BTW, this issue is documented as enhancement request #112 at http://www.greenwoodsoftware.com/less/bugs.html.

Your second issue is definitely a bug.  Less's handling of -F and eof in 
general is indeed rather baroque and confusing, and probably needs a 
complete revision.  Some of the complexity comes from being portable to 
many (not necessarily Unix-like) systems.  But in this case, I think the 
early exit is happening because less makes the decision about whether to 
quit due to -F based on the state of the input when the first prompt 
occurs.  When less receives SIGWIND, it repaints the screen and 
*reprompts*.  So if it gets this signal before the first screen is 
completely filled, it tries to prompt, somehow gets confused and thinks 
that the partially filled screen is evidence of a short file, and exits. 
  I will add this to the bug list and try to fix it in the next release.

--Mark

On Wed, 24 Jan 2007, Mark Nudelman wrote:

I don't dispute that the "move to the bottom of the screen" is probably a good feature in general, but it is _not_ a good feature when -F is in effect (similar to the init/exit sequence being a horrible thing to do when -F is in effect).

So the problem is that it basically makes -F largely useless.. The whole _point_ of anybody using -F is that it turns off the "pager" feature for small output that fits on a page, wouldn't you say?

(The reason the init/exit sequence doesn't mix with -F is that many terminal descriptions basically have a "switch to secondary screen" for init, and "switch back" for exit, which means that together with -F, small output simply won't be shown at all - or perhaps it just flickers too quickly for the user to see it).

So this really is only a -F issue.

Now, for the init/exit sequence, at least we have -X to turn that off (and git does indeed default to using "FRSX" if the user doesn't have any LESS environment variable set), so perhaps the "move to end of screen" could also get another flag? That way it would be something that users can control - but see above on why I pretty much guarantee that anybody who uses -F would want to use the new flag too.

Yeah, I tried to look at the sources, and ran awya screaming ;)

		Linus

On Tue, 23 Jan 2007, Linus Torvalds wrote:

Heh. This extremely hacky patch works around the second bug.

It does so by simply adding a "select()" on the input before even starting "less", which will mean that by the time less starts, it always has something to read, and that in turn hides the bug with resizing the terminal window while less is waiting for input.

I'm sure there's still a window for the bug to trigger, but I can no longer trivially reproduce the problem any more.

(The way to reproduce the problem is to do some pager operation that takes a while in git, and resizing the window while git is thinking about the output. I use

	git diff --stat v2.6.12..

in the kernel tree to do something where it takes a while for git to start outputting information)

Without this patch, I can easily just resize the window while git is thinking, and the end result is that "less" will exit early and indeed leave the tty in a broken state with no echo etc. With this patch, less doesn't get confused.

NOTE! To see this problem, you must use the LESS environment that git provides by default (LESS=FRSX) and not have your own environment set that overrides the git ones (or if you do, it must have -F set).

Is it ugly? Yes. Does it work? Yes. Do we want to apply it? You decide.

		Linus

---

Linus Torvalds <torvalds@linux-foundation.org> writes:

I would not call it ugly.

I once consiered to fork another process in between the pager and the caller here and make it buffer "the first screenful" before actually spawning the pager, or write out the short output itself without spawning, to fix the "no output but the cursor goes to the end" problem. THAT's ugly.

But I do not think your patch is ugly, and it would help normal people who work in a windowed environment (I did not see the need for it myself since I usually never resize the terminal -- even working inside X my terminals are usually fixed size and are always running "screen").

Hi all, I'm not sure if you are still interested in this, but I have posted a beta release of less (less-401) which I believe fixes both of these problems. See http://www.greenwoodsoftware.com/less. If you try it, let me know how it works for you.

--Mark

On 1/23/2007 12:32 PM, Linus Torvalds wrote:

BTW, as the upcoming v1.5.0 release will introduce quite a bit of surface changes (although at the really core it still is the old git and old ways should continue to work), I am wondering if it would help people to try out and find wrinkles before the real thing for me to cut a tarball and a set of RPM packages.

Comments?

Also, in the same spirit of giving the release an early exposure, here is the current draft of 1.5.0 release notes.

-- >8 -- cut here -- >8 --

GIT v1.5.0 Release Notes (draft) ================================

Old news --------

This section is for people who are upgrading from ancient versions of git. Although all of the changes in this section happened before the current v1.4.4 release, they are summarized here in the v1.5.0 release notes for people who skipped earlier versions.

In general, you should not have to worry about incompatibility, and there is no need to perform "repository conversion" if you are updating to v1.5.0. However, some of the changes are one-way street upgrades; once you use them your repository can no longer be used with ancient git.

 - There is a configuration variable core.legacyheaders that
   changes the format of loose objects so that they are more
   efficient to pack and to send out of the repository over git
   native protocol, since v1.4.2.  However, loose objects
   written in the new format cannot be read by git older than
   that version; people fetching from your repository using
   older clients over dumb transports (e.g. http) using older
   versions of git will also be affected.

 - Since v1.4.3, configuration repack.usedeltabaseoffset allows
   packfile to be created in more space efficient format, which
   cannot be read by git older than that version.

The above two are not enabled by default and you explicitly have to ask for them, because these two features make repositories unreadable by older versions of git, and in v1.5.0 we still do not enable them by default for the same reason. We will change this default probably 1 year after 1.4.2's release, when it is reasonable to expect everybody to have new enough version of git.

 - 'git pack-refs' appeared in v1.4.4; this command allows tags
   to be accessed much more efficiently than the traditional
   'one-file-per-tag' format.  Older git-native clients can
   still fetch from a repository that packed and pruned refs
   (the server side needs to run the up-to-date version of git),
   but older dumb transports cannot.  Packing of refs is done by
   an explicit user action, either by use of "git pack-refs
   --prune" command or by use of "git gc" command.

 - 'git -p' to paginate anything -- many commands do pagination
   by default on a tty.  Introduced between v1.4.1 and v1.4.2;
   this may surprise old timers.

 - 'git archive' superseded 'git tar-tree' in v1.4.3;

 - 'git cvsserver' was new invention in v1.3.0;

 - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
   seriously enhanced during v1.4.0 timeperiod.

 - 'gitweb' became part of git.git during v1.4.0 timeperiod and
   seriously modified since then.

 - reflog is an v1.4.0 invention.  This allows you to name a
   revision that a branch used to be at (e.g. "git diff
   master@{yesterday} master" allows you to see changes since
   yesterday's tip of the branch).

Updates in v1.5.0 since v1.4.4 series -------------------------------------

* Index manipulation

 - git-add is to add contents to the index (aka "staging area"
   for the next commit), whether the file the contents happen to
   be is an existing one or a newly created one.

 - git-add without any argument does not add everything
   anymore.  Use 'git-add .' instead.  Also you can add
   otherwise ignored files with an -f option.

 - git-add tries to be more friendly to users by offering an
   interactive mode.

 - git-commit <path> used to refuse to commit if <path> was
   different between HEAD and the index (i.e. update-index was
   used on it earlier).  This check was removed.

 - git-rm is much saner and safer.  It is used to remove paths
   from both the index file and the working tree, and makes sure
   you are not losing any local modification before doing so.

 - git-reset <tree> <paths>... can be used to revert index
   entries for selected paths.

 - git-update-index is much less visible.

* Repository layout and objects transfer

 - The data for origin repository is stored in the configuration
   file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
   created clones.  The latter is still supported and there is
   no need to convert your existing repository if you are
   already comfortable with your workflow with the layout.

 - git-clone always uses what is known as "separate remote"
   layout for a newly created repository with a working tree;
   i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
   used to track branches from the origin.  

 - New branches that appear on the origin side after a clone is
   made are also tracked automatically.  This is done with an
   wildcard refspec "refs/heads/*:refs/remotes/origin/*", which
   older git does not understand, so if you clone with 1.5.0,
   you would need to downgrade remote.*.fetch in the
   configuration file to specify each branch you are interested
   in individually if you plan to fetch into the repository with
   older versions of git (but why would you?).

 - git-branch and git-show-branch know remote tracking branches.

 - git-push can now be used to delete a remote branch or a tag.
   This requires the updated git on the remote side.

 - git-push more agressively keeps the transferred objects
   packed.  Earlier we recommended to monitor amount of loose
   objects and repack regularly, but you should repack when you
   accumulated too many small packs this way as well.  Updated
   git-count-objects helps you with this.

 - A new command, git-remote, can help you manage your remote
   tracking branch definitions.

* Bare repositories

 - Certain commands change their behaviour in a bare repository
   (i.e. a repository without associated working tree).  We use
   a fairly conservative heuristic (if $GIT_DIR is ".git", or
   ends with "/.git", the repository is not bare) to decide if a
   repository is bare, but "core.bare" configuration variable
   can be used to override the heuristic when it misidentifies
   your repository.

 - git-fetch used to complain updating the current branch but
   this is now allowed for a bare repository.  So is the use of
   'git-branch -f' to update the current branch.

 - Porcelain-ish commands that require a working tree refuses to
   work in a bare repository.

* Reflog

 - Reflog records the history of where the tip of each branch
   was at each moment.  This facility is enabled by default for
   repositories with working trees, and can be accessed with the
   "branch@{time}" and "branch@{Nth}" notation.

 - "git show-branch" learned showing the reflog data with the
   new --reflog option.  "git log" has --walk-reflogs option to
   view reflog entries in a more verbose manner.

 - git-branch knows how to rename branches and moves existing
   reflog data from the old branch to the new one.

 - The commits referred to by reflog entries are now protected
   against pruning.  The new command "git reflog expire" can be
   used to truncate older reflog entries and entries that refer
   to commits that have been pruned away previously with older
   versions of git.

   Existing repositories that have been using reflog may get
   complaints from fsck-objects and may not be able to run
   git-repack, if you had run git-prune from older git; please
   run "git reflog expire --stale-fix --all" first to remove
   reflog entries that refer to commits that are no longer in
   the repository when that happens.

* Crufts removal

 - We used to say "old commits are retrievable using reflog and
   'master@{yesterday}' syntax as long as you haven't run
   git-prune".  We no longer have to say the latter half of the
   above sentence, as git-prune does not remove things reachable
   from reflog entries.

 - 'git-prune' by default does not remove _everything_
   unreachable, as there is a one-day grace period built-in.

 - There is a toplevel garbage collector script, 'git-gc', that
   is an easy way to run 'git-repack -a -d', 'git-reflog gc',
   and 'git-prune'.

* Detached HEAD

 - You can give non-branch to "git checkout" now.  This will
   dissociate your HEAD from any of your branches.  A typical
   use of this feature is to "look around".  E.g.

	$ git checkout v2.6.16
	... compile, test, etc.
	$ git checkout v2.6.17
	... compile, test, etc.

 - After detaching your HEAD, you can go back to an existing
   branch with usual "git checkout $branch".  Also you can
   start a new branch using "git checkout -b $newbranch".

 - You can even pull from other repositories, make merges and
   commits while your HEAD is detached.  Also you can use "git
   reset" to jump to arbitrary commit.

   Going back to undetached state by "git checkout $branch" can
   lose the current stat you arrived in these ways, and "git
   checkout" refuses when the detached HEAD is not pointed by
   any existing ref (an existing branch, a remote tracking
   branch or a tag).  This safety can be overriden with "git
   checkout -f $branch".

* Packed refs

 - Repositories with hundreds of tags have been paying large
   overhead, both in storage and in runtime, due to the
   traditional one-ref-per-file format.  A new command,
   git-pack-refs, can be used to "pack" them in more efficient
   representation.

 - Clones and fetches over dumb transports are now aware of
   packed refs and can download from repositories that use
   them.

* Configuration

 - configuration related to color setting are consolidated under
   color.* namespace (older diff.color.*, status.color.* are
   still supported).

* Less external dependency

 - We no longer require the "merge" program from the RCS suite.
   All 3-way file-level merges are now done internally.

 - The original implementation of git-merge-recursive which was
   in Python has been removed; we have C implementation of it
   now.

 - git-shortlog is no longer a Perl script.  It no longer
   requires output piped from git-log; it can accept revision
   parameters directly on the command line.

* I18n

 - We have always encouraged the commit message to be encoded in
   UTF-8, but the users are allowed to use legacy encoding as
   appropriate for their projects.  This will continue to be the
   case.  However, a non UTF-8 commit encoding _must_ be
   explicitly set with i18n.commitencoding in the repository
   where a commit is made; otherwise git-commit-tree will
   complain if the log message does not look like a valid UTF-8
   string.

 - The value of i18n.commitencoding in the originating
   repository is recorded in the commit object on the "encoding"
   header, if it is not UTF-8.  git-log and friends notice this,
   and reencodes the message to the log output encoding when
   displaying, if they are different.  The log output encoding
   is determined by "git log --encoding=<encoding>",
   i18n.logoutputencoding configuration, or i18n.commitencoding
   configuration, in the decreasing order of preference, and
   defaults to UTF-8. 

 - Tools for e-mailed patch application now default to -u
   behaviour; i.e. it always re-codes from the e-mailed encoding
   to the encoding specified with i18n.commitencoding.  This
   unfortunately forces projects that have happily been using a
   legacy encoding without setting i18n.commitencoding to set
   the configuration, but taken with other improvement, please
   excuse us for this very minor one-time inconvenience.

* e-mailed patches

 - See the above I18n section.

 - git-format-patch now enables --binary without being asked.
   git-am does _not_ default to it, as sending binary patch via
   e-mail is unusual and is harder to review than textual
   patches and it is prudent to require the person who is
   applying the patch to explicitly ask for it.

 - The default suffix for git-format-patch output is now ".patch",
   not ".txt".  This can be changed with --suffix=.txt option,
   or "format.suffix = .txt" in the configuration.

* Foreign SCM interfaces

  - git-svn now requires the Perl SVN:: libraries, the
    command-line backend was too slow and limited.

  - the 'commit' subcommand of git-svn has been renamed to
    'set-tree', and 'dcommit' is the recommended replacement for
    day-to-day work.

* User support

 - Quite a lot of documentation updates.

 - Bash completion scripts have been updated heavily.

 - Better error messages for often used Porcelainish commands.

* Sliding mmap

 - We used to assume that we can mmap the whole packfile while
   in use, but with a large project this consumes huge virtual
   memory space and truly huge ones would not fit in the
   userland address space on 32-bit platforms.  We now mmap huge
   packfile in pieces to avoid this problem.

* Shallow clones

 - There is a partial support for 'shallow' repositories that
   keeps only recent history.  A 'shallow clone' is created by
   specifying how deep that truncated history should be.

   Currently a shallow repository has number of limitations:

   - Cloning and fetching _from_ a shallow clone are not
     supported (nor tested -- so they might work by accident but
     they are not expected to).

   - Pushing from nor into a shallow clone are not expected to
     work.

   - Merging inside a shallow repository would work as long as a
     merge base is found in the recent history, but otherwise it
     will be like merging unrelated histories and may result in
     huge conflicts.

   but this would be more than adequate for people who want to
   look at near the tip of a big project with a deep history and
   send patches in e-mail format.

On Sunday, January 21, 2007 at 03:20:06 (-0800) Junio C Hamano writes:

I asked this in the context of the "fatal: protocol error" thread, but can I install the 1.5.0rcX on my machine and use it with our company repository, running 1.4.4.1?

In any case, I think trying to find wrinkles before the real thing is certainly healthy.

Bill

Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?

Bill

On Sunday, January 21, 2007 at 07:42:56 (-0600) Bill Lear writes:

Bill Lear:

git clone git://git.kernel.org/pub/scm/git/git.git

Then checkout the commit tagged 'v1.5.0-rc2'.

There are no such tarballs (yet) on:

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

Hi,

On Sun, 21 Jan 2007, Bill Lear wrote:

Direct your browser to

http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f

BTW please don't top post. It uses bandwidth unnecessarily (both in terms of megabytes and attention).

Ciao, Dscho

Johannes Schindelin wrote:

Better URL is

  http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2

Hi,

On Sun, 21 Jan 2007, Jakub Narebski wrote:

It is a better URL. Somehow I fscked up when I tried it, so I had the impression that does not work. But it does.

Sorry, Dscho

Johannes Schindelin wrote:

Most probably you wrote '1.5.0-rc2' instead of 'v1.5.0-rc2' (with 'v' prefix).

Hi Junio !

On Sun, Jan 21, 2007 at 03:20:06AM -0800, Junio C Hamano wrote:

Anything you can do to make tester's life easier will always slightly increase the number of testers. Hint: how often do you try random software that requires that you first install CVS, SVN or arch just to get it, compared to how often you try random software provided as tar.gz ? Pre-release tar.gz and rpms coupled with a freshmeat announcement should get you a bunch of testers and newcomers. This will give the new doc a real trial, and will help discover traps in which beginners often fall.

(...)

I know it's a bit late to ask, but if new on-disk format changes, isn't it time to bump the version to 2.0 ? It would be easier for many people to remember that GIT 1.X uses format version 1 and that GIT 2.X uses format version 2 with backwards compatibility with 1.X. I also think that 1.5 is much more different from 1.0 than a mid-term 2.0 would be from current 1.5.

That said, kudos for the nice changelog !

Regards, Willy

Willy Tarreau wrote:

RPMS are nicely divided into (sub)packages, so you need CVS indtalled only if you install git-cvs package, for example to interact with CVS. git-core has minimal dependencies.

To compile git you truly don't need other software installed (1.5.0 for example does not require RCS anymore for RCS merge).

Willy Tarreau <w@1wt.eu> writes:

One worry I had about releasing git-1.5.0-rc2-1.rpm and friends just like the "official" ones was that people might have scripts to automate downloading & updating of packages, and they may not like to get "beta" installed for them.

I wonder if kernel.org machines are also affected...

I think we could have gone either way (as you said, it is probably a bit too late to discuss this), but it should probably be Ok to stay at 1.X as long as these one-way-street format updates are turned off by default.

And the above happened way before this round and people have hopefully been happily using. For example, v1.4.2 was done early August 2006.

Junio C Hamano wrote:

Put them in a different directory hierarchy if you don't want to make them installed.

In general, though, I would agree that the major number should change if there is an incompatible change.

	-hpa

On Sun, 21 Jan 2007, H. Peter Anvin wrote:

Maybe when those incompatible features are enabled by default. Right now they're not.

Nicolas

Junio C Hamano <junkio@cox.net> wrote:

Then put them into a "testing" or "pre-release" directory...

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

Ok, thanks for the suggestion.

The preview RPMs for i386 and x86_64 and an SRPM are available at:

	/pub/software/scm/git/testing/

The tarball for 1.5.0-rc2 is found at:

	/pub/software/scm/git/git-1.5.0.rc2.tar.gz

along with tarballs of preformatted htmldocs and manpages.

Junio C Hamano <junkio@cox.net> wrote:

[...]

Huh?

What are possible values of that variable? What happens if it is set/unset? I'd suppose that if it is set, you get the old format, but that isn't clear.

Same as above.

I don't see an upgrade path here that doesn't involve keeping cruft "new feature is on" variables around indefinitely... Why not just a repository version?

[...]

[...]

I suppose "git add ." works for 'adding everything' only at the top?

Why not tell about "git add -i"?

[...]

[...]

Where is such a branch rooted?

Does this leave you on that branch, or still in limbo?

s/undetached/attached/

What happens if there are changes in the tracked files?

[...]

A bit of detail on how to specify shallowness would be nice here...

Very nice work, thanks!

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

All are valid questions, but the release notes will be too long if it made into "migration manual plus full documentation of new features". Its purpose is to list things you would want to pay attention to.

The new feature will be on regardless of the configuration at some point, perhaps in GIT 2.0. For now it isn't, and that is another reason the release notes do not have to (and probably should not for the sake of brevity) talk about gory details to turn the feature on. If we were to do the feature in "incompatible by default" way, the release notes should talk about how to turn it off and keep the old way.

Thanks, will update.  s/mode\.$/mode ("git-add -i")./

I did not think it needs to be mentioned as "git checkout -b $newbranch" has always been "git checkout -b $newbranch HEAD" and this is not changed with detached HEAD. Maybe I should add "... to start a new branch at that commit" at the end of the sentence. Thanks.

Perhaps "s/\.$/, while still keeping your HEAD detached./". Will update.

The answer is "just like normal checkout does", but I think that level of detail does not belong to the release notes. The list of features is meant to be just to introduce what new things there are, and people interested should learn the details from the documentation.

The same comment as the above applies here.

Hi,

On Sun, 21 Jan 2007, Junio C Hamano wrote:

You should probably mention that it is not necessary to run git-pack-refs by hand: git-gc is what you want.

BTW have I praised y'all for inventing git-gc? It is _awesome_. I think I will turn into a DWIM geek yet; it is soooo much more convenient to issue "git gc" from time to time, than to think exactly about what I want to clean up right now.

Should we introduce "git config" in time for the "let's please end-users" release (1.5.0)?

... instead of $GIT_DIR/refs/heads/, making the difference between remotely tracked and local branches more obvious.

... (use the command line switch "-r" to list only tracked branches.)

... (use "git push <remote> :refs/heads/<branch>" to delete "branch".)

It might make sense to enable something similar for git-fetch in time for 1.5.0.

It might make sense to reformulate that:

	Reflog records the history from the view point of the local 
	repository. In other words, regardless of the real history,
	the reflog shows the history as seen by one particular repository
	(this enables you to ask "what was the current revision in _this_
	repository, yesterday at 1pm?").

Did I mention that I really _love_ git-gc?

I am no native speaker, but should that not be "we have a C implementation" instead?

I fully expect people to complain that a config like this

	format.suffix = .txt

does not work. better say ...

	or setting the config variable "format.suffix" to ".txt".

Amen. I think this really helped a lot of people already.

Maybe we should go the "restrict first, and loosen later" approach? I.e. forbid git-upload-pack to run if is_repository_shallow()?

Maybe forbid git-push and git-receive-pack to run if is_repository_shallow()?

(I _think_ git-push should be safe, but not git-receive-pack.)

Ciao, Dscho

Johannes Schindelin wrote:

I think that _both_ sentences are right. Reflog records history of where the tip of each branch was at each moment, logging also what command was used to move tip of branch (was it commit, amending commit, rebase, reset, or creating branch anew, git-am or pull).

But where tip of each branch was is purely local matter. What is global is DAG of commits, refs are always as seen by one particular repository.

Hi,

On Sun, 21 Jan 2007, Jakub Narebski wrote:

What I meant was: people not familiar with git development will probably not understand the shorter, concise statement. They will not know off-hand that there is a difference between the history of development, and the history, as seen from the local repository's viewpoint.

So of course, both sentences are right.

Your point -- that reflog also records the action -- is less important IMHO. It is just meta-data of the local view.

To your second point: the global history remains global, of course. But this is what you _usually_ refer to, when talking about the development history, anyway. Therefore, to motivate reflogs, you should point out the differences between local and global history.

And this means to at least _mention_ the word "local".

Ciao, Dscho

Johannes Schindelin wrote:

So I'd say:

  - Reflog records local history of where the tip of each branch
    was at each moment.

I think both "local" and "tip of branch" are important for understanding reflog.

Hi,

On Mon, 22 Jan 2007, Jakub Narebski wrote:

'kay. Probably the simple addition of "local" is enough. Like it.

Ciao, Dscho

Johannes Schindelin wrote:

Or perhaps this would be better:

   - Reflog records the history of where the tip of each branch
     was at each moment in given repository.

Just nitpicking.

I've read your message only once (may have to come back to think about ramifications of some finer points), but I generally agree. I'd appreciate a patch to the 'todo' branch ;-).

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I think that is sensible.  Let's do this.

-- >8 -- [PATCH] shallow repository: disable unsupported operations for now.

We currently do not support fetching/cloning from a shallow repository nor pushing into one. Make sure these are not attempted so that we do not have to worry about corrupting repositories needlessly.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 receive-pack.c |    3 +++
 upload-pack.c  |    3 ++-
 2 files changed, 5 insertions(+), 1 deletions(-)

I'll be reusing it on the fetch-pack side as well.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

  Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

  >>  - git-push more agressively keeps the transferred objects
  >>    packed.  Earlier we recommended to monitor amount of loose
  >>    objects and repack regularly, but you should repack when you
  >>    accumulated too many small packs this way as well.  Updated
  >>    git-count-objects helps you with this.
  >
  > It might make sense to enable something similar for git-fetch in time for 
  > 1.5.0.

  I have two patches that could become the beginning of this, not
  much tested.  This is the first of the two.

 pack.h         |    5 +++++
 receive-pack.c |   26 ++++++++++++++------------
 sha1_file.c    |   21 +++++++++++++++++++++
 3 files changed, 40 insertions(+), 12 deletions(-)

With --keep-auto option, fetch-pack decides to keep the pack without exploding it just like receive-pack does.

We may want to later make this the default.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 And this is the second half.  It looks larger than it really
 is, because it involves some code movements; it removes two
 separate functions that called get_pack() and moves what they
 did to get_pack() after setup_sideband() happens.

 Although I did test it with --keep-auto with large and small
 packs once each. I haven't tested this at all with the
 git-fetch script.

 fetch-pack.c |   91 +++++++++++++++++++++++++++++++++++++--------------------
 1 files changed, 59 insertions(+), 32 deletions(-)

Hi,

On Mon, 22 Jan 2007, Junio C Hamano wrote:

I like both patches. (Did not have time to test yet, but from looking at the patches, it seems indeed to be mostly code moves.)

You have my vote for sooner rather than later.

Ciao, Dscho

P.S.: These patches make me dream of yet another diff format enhancement: code moves! Of course, for this to be really usable, you'd also have to automatically determine indent changes... You may say I'm a dreamer. But I'm not the only one...

Johannes Schindelin wrote:

I wonder if it could be done with e.g.

Hi,

On Tue, 23 Jan 2007, Jakub Narebski wrote:

There is a more fundamental problem here: both "diff" and "patch" walk the file pair in a direction. The whole "code movement" stuff would break this paradigm. What you found is just _one_ consequence.

But as I said: a man can still dream, can't he?

Ciao, Dscho

On Tue, 23 Jan 2007, Johannes Schindelin wrote:

Seconded.

Nicolas

This makes git-fetch over git native protocol to automatically decide to keep the downloaded pack if the fetch results in more than 100 objects, just like receive-pack invoked by git-push does. This logic is disabled when --keep is explicitly given from the command line, so that a very small clone still keeps the downloaded pack as before.

The 100 threshold can be adjusted with fetch.unpacklimit configuration. We might want to introduce transfer.unpacklimit to consolidate the two unpacklimit variables, which will be a topic for the next patch.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
  Nicolas Pitre <nico@cam.org> writes:

  > On Tue, 23 Jan 2007, Johannes Schindelin wrote:
  >
  >> On Mon, 22 Jan 2007, Junio C Hamano wrote:
  >> 
  >> > We may want to later make this the default.
  >> 
  >> You have my vote for sooner rather than later.
  >
  > Seconded.
  >
  > Nicolas

  Ok, how about this, on top of the previous ones?

 Documentation/config.txt |   10 ++++++++++
 fetch-pack.c             |   31 +++++++++++++++++--------------
 t/t5500-fetch-pack.sh    |    3 ++-
 3 files changed, 29 insertions(+), 15 deletions(-)

Hi,

On Wed, 24 Jan 2007, Junio C Hamano wrote:

Thanks!

Why do you need setup_ident()?

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Because presumably you would be updating the reflog that records who did the fetch?

But then we should do the same ignore_missing_committer_name() we have in receive-pack to allow anonymous fetchers to fetch from outside world, I guess.

Hi,

On Thu, 25 Jan 2007, Junio C Hamano wrote:

Ah yes, that makes sense!

Thank you, Dscho

Junio C Hamano <junkio@cox.net> writes:

This turns out to be more serious than I expected.

The code that uses committer_info() in reflog can barf and die. And I do not think calling ignore_missing_committer_name() upfront like recent receive-pack did in the aplication is a reasonable workaround.

So I am thinking about doing something like the attached patch.

What the patch does.

 - git_committer_info() takes one parameter.  It used to be "if
   this is true, then die() if the name is not available due to
   bad GECOS, otherwise issue a warning once but leave the name
   empty".  The reason was because we wanted to prevent bad
   commits from being made by git-commit-tree (and its
   callers).  The value 0 is only used by "git var -l". 

   Now it takes -1, 0 or 1.  When set to -1, it does not
   complain but uses the pw->pw_name when name is not
   available.  Existing 0 and 1 values mean the same thing as
   they used to mean before.  0 means issue warnings and leave
   it empty, 1 means barf and die.

 - ignore_missing_committer_name() and its existing caller
   (receive-pack, to set the reflog) have been removed.

 - git-format-patch, to come up with the phoney message ID when
   asked to thread, now passes -1 to git_committer_info().  This
   codepath uses only the e-mail part, ignoring the name.  It
   used to barf and die.  The other call in the same program
   when asked to add signed-off-by line based on committer
   identity still passes 1 to make sure it barfs instead of
   adding a bogus s-o-b line.

 - log_ref_write in refs.c, to come up with the name to record
   who initiated the ref update in the reflog, passes -1.  It
   used to barf and die.

The last change means that git-update-ref, git-branch, and commit walker backends can now be used in a repository with reflog by somebody who does not have the user identity required to make a commit. They all used to barf and die.

I've run tests and all of them seem to pass, and also tried "git clone" as a user whose GECOS is empty -- git clone works again now (it was broken when reflog was enabled by default).

But this definitely needs extra sets of eyeballs.

---

The code that uses committer_info() in reflog can barf and die whenever it is asked to update a ref. And I do not think calling ignore_missing_committer_name() upfront like recent receive-pack did in the aplication is a reasonable workaround.

What the patch does.

 - git_committer_info() takes one parameter.  It used to be "if
   this is true, then die() if the name is not available due to
   bad GECOS, otherwise issue a warning once but leave the name
   empty".  The reason was because we wanted to prevent bad
   commits from being made by git-commit-tree (and its
   callers).  The value 0 is only used by "git var -l".

   Now it takes -1, 0 or 1.  When set to -1, it does not
   complain but uses the pw->pw_name when name is not
   available.  Existing 0 and 1 values mean the same thing as
   they used to mean before.  0 means issue warnings and leave
   it empty, 1 means barf and die.

 - ignore_missing_committer_name() and its existing caller
   (receive-pack, to set the reflog) have been removed.

 - git-format-patch, to come up with the phoney message ID when
   asked to thread, now passes -1 to git_committer_info().  This
   codepath uses only the e-mail part, ignoring the name.  It
   used to barf and die.  The other call in the same program
   when asked to add signed-off-by line based on committer
   identity still passes 1 to make sure it barfs instead of
   adding a bogus s-o-b line.

 - log_ref_write in refs.c, to come up with the name to record
   who initiated the ref update in the reflog, passes -1.  It
   used to barf and die.

The last change means that git-update-ref, git-branch, and commit walker backends can now be used in a repository with reflog by somebody who does not have the user identity required to make a commit. They all used to barf and die.

I've run tests and all of them seem to pass, and also tried "git clone" as a user whose GECOS is empty -- git clone works again now (it was broken when reflog was enabled by default).

But this definitely needs extra sets of eyeballs.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 * Here is an updated patch -- the previous one was on top of
   what was never committed, and was useless.

 builtin-log.c  |    2 +-
 cache.h        |    1 -
 ident.c        |   28 +++++++++++-----------------
 receive-pack.c |    2 --
 refs.c         |    2 +-
 5 files changed, 13 insertions(+), 22 deletions(-)

On 1/26/07, Junio C Hamano <junkio@cox.net> wrote:

 enum {
    CMITR_INFO_PW_NAME = -1,
    CMITR_INFO_EMPTY = 0,
    CMITR_INFO_DIE = 1,
 };

-       const char *committer = git_committer_info(CMITR_INFO_DIE);
+       const char *committer = git_committer_info(CMITR_INFO_PW_NAME);

The code becoming increasingly harder to read, doesn't it...

Junio C Hamano wrote:

Instead of using ignore_missing_committer_name(), use get_committer_info(0) in refs.c. cherry-pick 4feaf032d3 from my tree at git://repo.or.cz/git/mingw.git if you want.

Although this approach leaves the name+email in the reflog entry empty instead of writing "unkown"...

-- Hannes

This allows transfer.unpackLimit to specify what these two configuration variables want to set.

We would probably want to deprecate the two separate variables, as I do not see much point in specifying them independently.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 Documentation/config.txt |    5 +++++
 fetch-pack.c             |   14 +++++++++++++-
 receive-pack.c           |   24 ++++++++++++++++--------
 t/t5500-fetch-pack.sh    |    2 +-
 4 files changed, 35 insertions(+), 10 deletions(-)

On Wed, 24 Jan 2007, Junio C Hamano wrote:

Well... since they're already there and not hurting anything I would let them live. Never know how they might be useful.

Nicolas

Junio C Hamano <junkio@cox.net> wrote:

Indeed. I was going to fix this too, but reuse receive.unpackLimit. From my point of view both fetch and receive-pack are recieving objects into this repository; and in either case I want the same behavior with regards to loose object/pack management.

On Tue, 23 Jan 2007, Johannes Schindelin wrote:

It's basically impossible.

Why? You need the context. 

In a _context_less_ diff, it's fairly trivial to indicate code movement: you just say "move bytes x-y into z". However, if you want anything approaching readability and safety, you want context, and that automatically means that you need to have the stuff around the context, which in turn means that you can't sanely do that.

Sure, you could do a diff that has the *context* repeated around the code that moves (and not actually quoting all the movement itself, except for the first and last three lines or something), but that would be really unreadable. A lot more unreadable than what we have now, with delete+add chunks.

Indeed. Much code movement isn't just pure data movement, it's re-indentation too. Making the thing even less tractable.

In other words - you can do it (and we _do_ do it) when you don't do diffs at all, but deltas. Our deltas actually do contain block movement. But diffs? Forget about it.

I am the walrus.

		Linus

Linus Torvalds <torvalds@linux-foundation.org> writes:

Yes, I think that a diff format for code moves wouldn't be useful. What could potentially be useful is a graphical diff browser that can e.g. show two versions side-by-side and show code moves in that. I have a vague memory that the ClearCase merge tool did that.

But as long as the code moves are within a single file, that merge tool could derive that move from an ordinary diff.

Hi,

[Re-Cc'ing Linus]

On Tue, 23 Jan 2007, David Kågedal wrote:

I don't need no steenking graphical tools. I want to read me mailing list, that's it.

Actually, you could even derive a code movement between files from the set of diffs. Though not code copies. But then, we don't do code copies.

Seriously again, your comment got me thinking: it could actually make sense to include the information of code moves and code copies (for easier review) in the "@@ .. @@" lines (or before them, if git apply does not choke on inserting garbage lines before them).

But maybe it is not that good after all: if you review code, you should inspect it (even if it was only moved), since it might have all kinds of side effects, or you might have missed some other aspect before.

Ciao, Dscho

Johannes Schindelin wrote:

It would be nice to have extended git header dealing with code copies (or stuff it in chunk header or above), because sometimes both sides of code movement (removal from one file, adding in next file) can be separated by a few pagefulls of chunks.

On Sun, 21 Jan 2007 03:20:06 -0800, Junio C Hamano wrote:

Thanks, these are very good and really show how much great progress has gone into git recently. Congratulations to everyone who has helped with this!

A few comments:

This "one-way street upgrades" sentence makes the upgrade to 1.5 sound scarier than it really is. It's only after two more paragraphs of fairly dense technical content that the reader is told that none of this stuff is enabled by default yet.

Maybe replace the second sentence with something like:

	As of git v1.5.0 there are some optional changes to the
	repository that allow data to be stored and transferred more
	efficiently. These changes are not enabled by default as they
	will make the repository unusable with git versions before
	v1.4.2. Specifically the available options are:

or something along those lines.

It's not clear what this sentence means. Perhaps add something like:

	, (many mentions of update-index in git output and
	documentation have now been replaced by simpler commands such
	as "git add" or "git rm").

This change has some workflow impact that is not at all obvious from the above description. For example, after cloning git.git, things that used to work like "git checkout -b my-next next" now no longer work, (needing to use "origin/next" instead). And these branches also won't appear in "git branch" output, (without the new -r option).

I think the release notes should spend a little more attention on an issue like this. Maybe a separate section on changes to existing interfaces, (as opposed to most of the other changes which are improvements in the implementation of existing interfaces or just plain new interfaces such as "git remote", "git gc", etc.)

If there is a new section, the previous paragraphs describing the move of cloned origin information from .git/remotes/origin to .git/config might belong there as well, (depending on whether you consider those file contents a user-visible interface or not).

Should mention "-r" here.

What's the syntax for this? I know you don't want to turn the release notes into a user manual, but it'd be nice to have brief mentions of the new interfaces, (like the nice mention of "git add -i" for example). Even with a quick skim through the git-push documentation, I'm not immediately seeing how to delete a remote branch or tag.

I think it's definitely worthwhile to note the fix of race conditions, etc. here. It would be nice to have some short rule such as:

	"git gc" is free from any known race conditions with
	simultaneous git processes modifying the repository. So it's
	perfectly safe to run "git gc" from a cron job.

Or a similarly succinct rule that's actually true, (I think the recent thread suggested "git gc" would only be safe with an extra option---I'd much rather see it be safe by default and make the user ask for extra unsafe pruning with an option).

Rather than "non-branch" I think it would be nice to say something that mentioned tags. Maybe something like:

	You can now use 'git checkout' to checkout tags or any other
	revision, rather than just named branches."

Is git-gc doing this housekeeping? If not, should it be? If so, should it be mentioned here (and in the description of git-gc above)?

Here's another description that could definitely benefit from a very short example command.

-Carl

Thanks for your comments; the attached probably needs proofreading.

The changes in response to the remainder of your comments are quite straightforward and I do not think needs proofreading, so I'll incorporate them and push the result out in 'todo'.

On Mon, 22 Jan 2007 11:28:32 -0800, Junio C Hamano wrote:

You're welcome.

In general, I like it. The git-branch documentation already talks about "remote-tracking branches" so I've rewritten a couple of sentence below to use that same terminology. Also there are a couple of grammar errors related to pluralization, (likely the fault of English being quite a bit less consistent than other languages with subject/verb number agreement, etc.).

      renaming remote 'master' to local 'origin'), the new approach
      puts upstream branches into local "remote-tracking branches"
      with their own namespace. These can be referenced with names
      such as "origin/$upstream_branch_name" and are stored in
      .git/refs/remotes rather than .git/refs/heads where normal
      branches are stored.

Should be "more than one remote repository.". Also I'd add, ", (see the new 'git remote' command)" before the end of that sentence.

Again to use the same terminology, "does not show the remote-tracking branches.".

The 's' on "continues" is incorrect. Perhaps:

	continue to work (and will work in the future as well).

or just drop the parenthetical phrase.

-Carl

Junio C Hamano wrote:

Would they be somewhere besides todo branch of git.git repository, like the v1.5.0 tag comment (content), or the NEWS file?

Jakub Narebski <jnareb@gmail.com> writes:

Most likely the former would happen when the real thing is made.