{"thread":{"id":"6123","subject":"[RFH] An early draft of v1.5.0 release notes","startedAt":"2006-12-27T07:39:41Z","lastAt":"2007-01-10T07:58:26Z","messageCount":20,"participants":["Junio C Hamano","Shawn Pearce","Jakub Narebski","Johannes Schindelin","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30332","messageId":"7vvejx948y.fsf@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":null,"subject":"[RFH] An early draft of v1.5.0 release notes","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-27T07:39:41Z","receivedAt":"2006-12-27T07:39:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This is still rough, but I think we have a pretty good idea what\nwill and what won't be in v1.5.0 by now, and end-of-year is a\ngood slow time to summarize what we have done.\n\nOne thing I am wondering is if delta from v1.4.4.3 is good\nenough for the intended audience of this release notes.  I am\nreasonably sure that the name v1.5.0 will attract more people\nthan usual and there will be many people upgrading directly from\nancient versions such as v1.1.6 or v1.2.0, and there are a\nhandful \"one-way-street upgrades\" and quite a few user visible\nchanges that already have happened before v1.4.4.  Namely:\n\n - Pack-compatible loose object headers, introduced between\n   v1.4.1 and v1.4.2; repository cannot be read with ancient\n   version of git anymore -- this is a one-way street but\n   core.legacyheaders is still not enabled by default);\n\n - delta-base-offset pack encoding, introduced between v1.4.2\n   and v1.4.3; this is also a one-way street.\n\n - 'git -p' to paginate anything -- many commands do pagination\n   by default on a tty.  Introduced between v1.4.1 and v1.4.2;\n   this may surprise old timer users.\n\n - 'git archive' superseded 'git tar' in v1.4.3;\n\n - 'git pack-refs' appeared in v1.4.4;\n\n - 'git cvsserver' was new invention in v1.3.0;\n\n - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were\n   seriously enhanced during v1.4.0 timeperiod.\n\n - 'gitweb' became part of git.git during v1.4.0 timeperiod and\n   seriously modified since then.\n\n - reflog is v1.4.0 invention.\n\nIn the following, I am assuming that jc/utf8 and jc/fsck-reflog\ntopics currently in 'next' will be part of v1.5.0.\n\n\n-- >8 --\n\nUpdates in v1.5.0 since v1.4.4 series\n-------------------------------------\n\n* Index manipulation\n\n - git-add is to add contents to the index (aka \"staging area\"\n   for the next commit), whether the file the contents happen to\n   be is an existing one or a newly created one.\n\n - git-add without any argument does not add everything\n   anymore.  Say \"git add .\" if you want to.\n\n - git-add tries to be more friendly to users by offering an\n   interactive mode.\n\n - git-commit <path> used to refuse to commit if <path> was\n   different between HEAD and the index (i.e. update-index was\n   used on it earlier).  This check was removed.\n\n - git-rm is much saner and safer.  It is used to remove paths\n   from both the index file and the working tree, and makes sure\n   you are not losing any local modification before doing so.\n\n - git-reset <tree> <paths>... can be used to revert index\n   entries for selected paths.\n\n - git-update-index is much less visible.\n\n\n* Repository layout\n\n - The data for origin repository is stored in the configuration\n   file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly\n   created clones (the latter is still supported).\n\n - git-clone always uses what is known as \"separate remote\"\n   layout for a newly created repository with a working tree;\n   i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are\n   used to track branches from the origin.  New branches that\n   appear on the origin side after a clone is made are also\n   tracked automatically.\n\n - git-clone used to be buggy and copied refs outside refs/heads\n   and refs/tags; it doesn't anymore.\n\n - git-branch and git-show-branch know remote tracking branches.\n\n - git-push can now be used to delete a remote branch or a tag.\n\n\n* Reflog\n\n - Reflog records the history of where the tip of each branch\n   was at each moment.  This facility is enabled by default for\n   repositories with working trees, and can be accessed with the\n   \"branch@{time}\" and \"branch@{Nth}\" notation.\n\n - \"git show-branch\" learned showing the reflog data with the\n   new --reflog option.\n\n - The commits referred to by reflog entries are now protected\n   against pruning.  The new command \"git reflog expire\" can be\n   used to truncate older reflog entries and entries that refer\n   to commits that have been pruned away previously.\n\n   Existing repositories that have been using reflog may get\n   complaints from fsck-objects; please run \"git reflog expire\n   --all\" first to remove reflog entries that refer to commits\n   that are no longer in the repository before attempting to\n   repack it.\n\n - git-branch knows how to rename branches and moves existing\n   reflog data from the old branch to the new one.\n\n\n* Packed refs\n\n - Repositories with hundreds of tags have been paying large\n   overhead, both in storage and in runtime.  A new command,\n   git-pack-refs, can be used to \"pack\" them in more efficient\n   representation.\n\n - Clones and fetches over dumb transports are now aware of\n   packed refs and can download from repositories that use\n   them.\n\n\n* Configuration\n\n - configuration related to colorize setting are consolidated\n   under color.* namespace (older diff.color.*, status.color.*\n   are still supported).\n\n\n* Less external dependency\n\n - We have been depended on \"merge\" program from RCS suite for\n   the file-level 3-way merge, but now we lost this dependency.\n\n - The original implementation of git-merge-recursive which was\n   in Python has been removed; we have C implementation of it\n   now.\n\n - git-shortlog is not in Perl anymore, and more importantly it\n   does not have to be piped output from git-log.  It can\n   traverse the commit ancestry itself.\n\n\n* I18n\n\n - We have always encouraged the commit message to be encoded in\n   UTF-8, but the users are allowed to use legacy encoding as\n   appropriate for their projects (which will never change).\n   A non UTF-8 commit encoding however _must_ be explicitly set\n   with i18n.commitencoding in the repository configuration;\n   otherwise git-commit-tree will complain if the log message does\n   not look like a valid UTF-8 string.\n\n - A commit object recorded in non UTF-8 encoding records the\n   encoding i18n.commitencoding specified in the originating\n   repository in a new \"encoding\" header.  This information is\n   used by git-log and friends to reencode the message to UTF-8\n   when displaying.\n\n\n* User support\n\n - Quite a lot of documentation updates.\n\n - Bash completion scripts have been updated heavily.\n\n - Better error messages for often used Porcelainish commands.\n\n\n----------------------------------------------------------------\n(shortlog since v1.4.4.3 here)\n"},{"id":"30336","messageId":"20061227081819.GB23022@spearce.org","threadId":"6123","inReplyTo":"7vvejx948y.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-27T08:18:19Z","receivedAt":"2006-12-27T08:18:19Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> This is still rough, but I think we have a pretty good idea what\n> will and what won't be in v1.5.0 by now, and end-of-year is a\n> good slow time to summarize what we have done.\n\nThis is certainly a good idea.  And your summary was pretty good\ntoo, I enjoyed the read.  This group has certainly accomplished\nquite a bit lately!\n\nJust a few comments:\n \n>  - Pack-compatible loose object headers, introduced between\n>    v1.4.1 and v1.4.2; repository cannot be read with ancient\n>    version of git anymore -- this is a one-way street but\n>    core.legacyheaders is still not enabled by default);\n> \n>  - delta-base-offset pack encoding, introduced between v1.4.2\n>    and v1.4.3; this is also a one-way street.\n\nPerhaps you can clarify that using these means the repository\ncannot be used with an earlier version of Git?  You may also want\nto highlight why these features are good, answering the question\n\"Why should I enable them if it breaks backwards compatibility?\".\n\nIsn't the new packed-refs format also a one-way street?  If you\nuse them for tags on a web server and the client is using a very\nold http commit walker, what happens?\n \n>  - git-clone used to be buggy and copied refs outside refs/heads\n>    and refs/tags; it doesn't anymore.\n\nI mentioned to you on #git this morning that I don't think this\nis noteworthy for this release.\n\nYou missed talking about the mess of pack files created by git-push\nnow, especially with pushes over 100 objects.  ;-)\n \n>  - git-push can now be used to delete a remote branch or a tag.\n\nYou should mention this requires server side support too.  I read\nthat and assumed I could just upgrade my client and push to delete\n- which isn't the case, and I know its not...  but I still read it\nthat way.\n \n>  - \"git show-branch\" learned showing the reflog data with the\n>    new --reflog option.\n\nI had hoped we could get 'git reflog show' into 1.5.0 but the\ncurrent discussion with Johannes seems like that's unlikely.\n \n>  - We have been depended on \"merge\" program from RCS suite for\n>    the file-level 3-way merge, but now we lost this dependency.\n\nPerhaps just reword as:\n\n\tWe no longer require the \"merge\" program from the RCS suite.\n\tAll 3-way file-level merges are now done internally.\n \n>  - git-shortlog is not in Perl anymore, and more importantly it\n>    does not have to be piped output from git-log.  It can\n>    traverse the commit ancestry itself.\n\nThe \"traverse the commit ancestry itself\" part is not very\nreadable for the average user.  How about instead:\n\n\tgit-shortlog is no longer a Perl script.  git-shortlog also\n\tno longer requires output piped from git-log; it can accept\n\trevision parameters directly on the command line.\n\n-- \nShawn.\n"},{"id":"30341","messageId":"emtgps$f1q$1@sea.gmane.org","threadId":"6123","inReplyTo":"7vvejx948y.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-27T10:12:56Z","receivedAt":"2006-12-27T10:12:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> This is still rough, but I think we have a pretty good idea what\n> will and what won't be in v1.5.0 by now, and end-of-year is a\n> good slow time to summarize what we have done.\n\nVery nice idea! Perhaps those release notes can find it's way into\neither v1.5.0 commit, or v1.5.0 tag comment?\n\nJust a few comments:\n\n>  - git-add without any argument does not add everything\n>    anymore.  Say \"git add .\" if you want to.\n> \n>  - git-add tries to be more friendly to users by offering an\n>    interactive mode.\n\nPerhaps information that git-add can be used to add ignored files\nwith -f option should be added? Or is it not important enough?\n \n>  - The commits referred to by reflog entries are now protected\n>    against pruning.  The new command \"git reflog expire\" can be\n>    used to truncate older reflog entries and entries that refer\n>    to commits that have been pruned away previously.\n> \n>    Existing repositories that have been using reflog may get\n>    complaints from fsck-objects; please run \"git reflog expire\n>    --all\" first to remove reflog entries that refer to commits\n>    that are no longer in the repository before attempting to\n>    repack it.\n\nThat's a bit bad, as it forces to lose some info... but that\ninfo was not that useful anyway.\n \n>  - A commit object recorded in non UTF-8 encoding records the\n>    encoding i18n.commitencoding specified in the originating\n>    repository in a new \"encoding\" header.  This information is\n>    used by git-log and friends to reencode the message to UTF-8\n>    when displaying.\n\nI don't quite like it. Why if someone uses different encoding\nthat utf-8 because his terminal is not set to utf-8? Having suddenly\nwhat looks like garbage on output, while input was in local encoding\n(and specified in i18n.commitencoding) is a bit suprising...\n \n> ----------------------------------------------------------------\n> (shortlog since v1.4.4.3 here)\n\nI'd rather have description a la \"what's cooking\" here... \n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30342","messageId":"7v1wml8wmw.fsf@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":"emtgps$f1q$1@sea.gmane.org","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-27T10:24:07Z","receivedAt":"2006-12-27T10:24:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> That's a bit bad, as it forces to lose some info... but that\n> info was not that useful anyway.\n\nI am tired of listening to this useless FUD of yours.  You lost\nthe information when you pruned away the underlying objects; you\nare not losing information when you expire the reflog entries\nthat became useless long time ago.\n\n> I don't quite like it. Why if someone uses different encoding\n> that utf-8 because his terminal is not set to utf-8? Having suddenly\n> what looks like garbage on output, while input was in local encoding\n> (and specified in i18n.commitencoding) is a bit suprising...\n\nIf Luben wants UTF-8 in his project, but somebody he pulled from\nwas mistakenly used latin-1, then the commit pulled record\nlatin-1 while Luben has i18n.commitencoding in his repository\nset to UTF-8.  Output will be done in UTF-8 for Luben.  For the\noriginator of that latin-1 commit, i18n.commitencoding says\nlatin-1 (and that was the only reason he managed to create such\na commit) and git show of that commit would not involve\nrecoding.\n\nAt least that is the idea.  Have you spotted a bug, perhaps?\n\n>> (shortlog since v1.4.4.3 here)\n>\n> I'd rather have description a la \"what's cooking\" here... \n\nSend the summary to the list and I'll append it to the release\nnotes.\n"},{"id":"30343","messageId":"7vvejx7gty.fsf@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":"emtgps$f1q$1@sea.gmane.org","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-27T10:50:49Z","receivedAt":"2006-12-27T10:50:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Just a few comments:\n>\n>>  - git-add without any argument does not add everything\n>>    anymore.  Say \"git add .\" if you want to.\n>\n> Perhaps information that git-add can be used to add ignored files\n> with -f option should be added? Or is it not important enough?\n\nThanks.  Will change the above bullet to this:\n\n - git-add without any argument does not add everything\n   anymore.  Use 'git-add .' instead.  Also you can add\n   otherwise ignored files with an -f option.\n"},{"id":"30345","messageId":"Pine.LNX.4.63.0612271251060.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6123","inReplyTo":"7v1wml8wmw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-27T11:54:09Z","receivedAt":"2006-12-27T11:54:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 27 Dec 2006, Junio C Hamano wrote:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n> > I don't quite like it. Why if someone uses different encoding\n> > that utf-8 because his terminal is not set to utf-8? Having suddenly\n> > what looks like garbage on output, while input was in local encoding\n> > (and specified in i18n.commitencoding) is a bit suprising...\n> \n> If Luben wants UTF-8 in his project, but somebody he pulled from was \n> mistakenly used latin-1, then the commit pulled record latin-1 while \n> Luben has i18n.commitencoding in his repository set to UTF-8.  Output \n> will be done in UTF-8 for Luben.  For the originator of that latin-1 \n> commit, i18n.commitencoding says latin-1 (and that was the only reason \n> he managed to create such a commit) and git show of that commit would \n> not involve recoding.\n\nI think that this is a misunderstanding. Maybe the config variable is \nmisnamed. As is clearly visible from the commit messages, this whole stuff \nis meant to reencode to whatever encoding the caller of git-log likes, not \njust UTF-8. And it defaults to UTF-8, overridable by i18n.commitEncoding.\n\nBTW I think that latin-1 is not a valid encoding name (at least in my \nsetup it isn't), so we should rather talk about iso-8859-1.\n\nCiao,\nDscho\n"},{"id":"30347","messageId":"200612271312.15877.jnareb@gmail.com","threadId":"6123","inReplyTo":"7v1wml8wmw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-27T12:12:15Z","receivedAt":"2006-12-27T12:12:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n>> Junio C Hamano wrote:\n>>>\n>>>  - The commits referred to by reflog entries are now protected\n>>>    against pruning.  The new command \"git reflog expire\" can be\n>>>    used to truncate older reflog entries and entries that refer\n>>>    to commits that have been pruned away previously.\n>>>\n>>>    Existing repositories that have been using reflog may get\n>>>    complaints from fsck-objects; please run \"git reflog expire\n>>>    --all\" first to remove reflog entries that refer to commits\n>>>    that are no longer in the repository before attempting to\n>>>    repack it.\n>>\n>> That's a bit bad, as it forces to lose some info... but that\n>> info was not that useful anyway.\n> \n> I am tired of listening to this useless FUD of yours.  You lost\n> the information when you pruned away the underlying objects; you\n> are not losing information when you expire the reflog entries\n> that became useless long time ago.\n\nSorry, this is a bit of my inner packrat ;-) showing thru.\n\nI'd rather use \"git reflog expire --pruned\" to remove reflog entries\nwhich refer to commits which are no longer in the repository; I don't\nknow, perhaps \"git reflog expire --all\" does that: but there is no\nDocumentation/git-reflog.txt (and I'm not running 'next' nor 'master'\nbut 1.4.4.3). So most probably it is just the case of adding an alias\nto reflog expire option.\n\n>>>  - A commit object recorded in non UTF-8 encoding records the\n>>>    encoding i18n.commitencoding specified in the originating\n>>>    repository in a new \"encoding\" header.  This information is\n>>>    used by git-log and friends to reencode the message to UTF-8\n>>>    when displaying.\n>>\n>> I don't quite like it. Why if someone uses different encoding\n>> that utf-8 because his terminal is not set to utf-8? Having suddenly\n>> what looks like garbage on output, while input was in local encoding\n>> (and specified in i18n.commitencoding) is a bit suprising...\n> \n> If Luben wants UTF-8 in his project, but somebody he pulled from\n> was mistakenly used latin-1, then the commit pulled record\n> latin-1 while Luben has i18n.commitencoding in his repository\n> set to UTF-8.  Output will be done in UTF-8 for Luben.  For the\n> originator of that latin-1 commit, i18n.commitencoding says\n> latin-1 (and that was the only reason he managed to create such\n> a commit) and git show of that commit would not involve\n> recoding.\n> \n> At least that is the idea.  Have you spotted a bug, perhaps?\n\nPerhaps that is the idea, but that idea is not described in above\nnew feature announcement. \"... to reencode the message to UTF-8 \nwhen displaying, if needed.\" would cover it, but perhaps better\nwould be to cover this in more detail: \"reencode message to UTF-8\nif i18n.commitencoding is not set to something other than UTF-8\",\nor \"reencode ... to i18n.commitencoding ... if needed\".\n\nBTW. what happens for NO_ICONV? Just curious...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"30348","messageId":"200612271315.05250.jnareb@gmail.com","threadId":"6123","inReplyTo":"Pine.LNX.4.63.0612271251060.19693@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-27T12:15:04Z","receivedAt":"2006-12-27T12:15:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> BTW I think that latin-1 is not a valid encoding name (at least in my \n> setup it isn't), so we should rather talk about iso-8859-1.\n\n\"iconv --list\" include l1 and latin1 as aliases to the proper name\nof encoding, i.e. iso-8859-1; but not latin-2.\n-- \nJakub Narebski\nPoland\n"},{"id":"30358","messageId":"7vpsa55dhw.fsf@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":"200612271312.15877.jnareb@gmail.com","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-27T19:45:47Z","receivedAt":"2006-12-27T19:45:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> ... I don't\n> know, perhaps \"git reflog expire --all\" does that: but there is no\n> Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'\n> but 1.4.4.3)...\n\nIf that is the case, may I ask you to at least please make it a\nhabit to read what are relevant to the topic under discussion\nbefore jumping in?  The list traffic is already high enough that\nI am spending a lot of time just to skim all the messages posted\nhere -- I think that time is better spent on development and\nimprovements.\n"},{"id":"30376","messageId":"emv367$sua$1@sea.gmane.org","threadId":"6123","inReplyTo":"200612271312.15877.jnareb@gmail.com","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-28T00:32:54Z","receivedAt":"2006-12-28T00:32:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n> Junio C Hamano wrote:\n>> Jakub Narebski <jnareb@gmail.com> writes:\n>>> Junio C Hamano wrote:\n>>>>\n>>>>  - The commits referred to by reflog entries are now protected\n>>>>    against pruning.  The new command \"git reflog expire\" can be\n>>>>    used to truncate older reflog entries and entries that refer\n>>>>    to commits that have been pruned away previously.\n>>>>\n>>>>    Existing repositories that have been using reflog may get\n>>>>    complaints from fsck-objects; please run \"git reflog expire\n>>>>    --all\" first to remove reflog entries that refer to commits\n>>>>    that are no longer in the repository before attempting to\n>>>>    repack it.\n[...]\n\n> I'd rather use \"git reflog expire --pruned\" to remove reflog entries\n> which refer to commits which are no longer in the repository; I don't\n> know, perhaps \"git reflog expire --all\" does that: but there is no\n> Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'\n> but 1.4.4.3). So most probably it is just the case of adding an alias\n> to reflog expire option.\n\nThanks for adding Documentation/git-reflog.txt. Nevertheless it didn't\nadd the information that \"git reflog expire\" removes reflog entries that\nrefer to commits that are no longer in the repository (see attached patch).\n\nI'm not sure if such technical information should be in git-reflog(1),\nbut does only second, current sha1 in reflog line matters for prune?\nAnd does expiring rewrite reflog (previous sha1, making always previous\nsha1 (first sha1 in reflog line) always to refer some commit in earlier\nreflog line, or before first reflog line), or only delete lines?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n\n>From c39e864dec5fc5542e9dd14235a48fa2bb77ed6a Mon Sep 17 00:00:00 2001\nFrom: Jakub Narebski <jnareb@gmail.com>\nDate: Thu, 28 Dec 2006 01:30:05 +0100\nSubject: [PATCH] Add information in git-reflog(1) that \"expire\" removes pruned entries\n\nAdd information to Documentation/git-reflog.txt that \"expire\" subcommand\nalso removes entries which refer to commits that are no longer in\nrepository.\n\nSigned-off-by: Jakub Narebski <jnareb@gmail.com>\n---\n Documentation/git-reflog.txt |    5 +++--\n 1 files changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt\nindex 55a24d3..04ea51a 100644\n--- a/Documentation/git-reflog.txt\n+++ b/Documentation/git-reflog.txt\n@@ -22,11 +22,12 @@ updated.  This command is to manage the information recorded in it.\n The subcommand \"expire\" is used to prune older reflog entries.\n Entries older than `expire` time, or entries older than\n `expire-unreachable` time and are not reachable from the current\n-tip, are removed from the reflog.  This is typically not used\n+tip, are removed from the reflog.  Entries which refer to\n+commits that are no longer in the repository are pruned\n+regardless of their age.  This command is typically not used\n directly by the end users -- instead, see gitlink:git-gc[1].\n \n \n-\n OPTIONS\n -------\n \n-- \n1.4.4.3\n\n"},{"id":"30387","messageId":"7vvejw3iaq.fsf@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":"7vvejx948y.fsf@assigned-by-dhcp.cox.net","subject":"An early draft of v1.5.0 release notes (2nd ed)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T01:45:01Z","receivedAt":"2006-12-28T01:45:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This incorporates comments from the list (thanks).  Maybe I\nshould park this in 'todo' branch so that people can review the\nupdates more easily.\n\n-- >8 --\n\nMajor changes that are not news\n-------------------------------\n\nThere were a handful big changes that happened before this major\nrelease.\n\nThis section is for people who are upgrading from ancient\nversions.  Some of them are one-way street upgrades -- once you\nuse the feature your repository cannot be used with ancient git.\n\n - There is a new configuration variable core.legacyheaders that\n   changes the format of loose objects to more efficient to pack\n   and send out of the repository over git native protocol.\n   However, this format cannot be read by git older than v1.4.2;\n   people fetching from your repository using older clients over\n   dumb transports (e.g. http) will also be affected.  This is\n   not enabled by default.\n\n - Another configuration repack.usedeltabaseoffset further\n   allows packfile to be created in more space efficient format,\n   which cannot be read  by git older than v1.4.3.  This is not\n   enabled by default.\n\n - 'git pack-refs' appeared in v1.4.4; this command allows tags\n   to be accessed much more efficiently than the traditional\n   'one-file-per-tag' format.  Older git-native client can fetch\n   from a repository that packed its tags, but older dumb\n   transports cannot.  This is done by an explicit user action,\n   either by use of \"git pack-refs --prune\" command or by use of\n   \"git gc\" command.\n\n - 'git -p' to paginate anything -- many commands do pagination\n   by default on a tty.  Introduced between v1.4.1 and v1.4.2;\n   this may surprise old timer users.\n\n - 'git archive' superseded 'git tar' in v1.4.3;\n\n - 'git cvsserver' was new invention in v1.3.0;\n\n - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were\n   seriously enhanced during v1.4.0 timeperiod.\n\n - 'gitweb' became part of git.git during v1.4.0 timeperiod and\n   seriously modified since then.\n\n - reflog is an v1.4.0 invention.\n\n\nUpdates in v1.5.0 since v1.4.4 series\n-------------------------------------\n\n* Index manipulation\n\n - git-add is to add contents to the index (aka \"staging area\"\n   for the next commit), whether the file the contents happen to\n   be is an existing one or a newly created one.\n\n - git-add without any argument does not add everything\n   anymore.  Use 'git-add .' instead.  Also you can add\n   otherwise ignored files with an -f option.\n\n - git-add tries to be more friendly to users by offering an\n   interactive mode.\n\n - git-commit <path> used to refuse to commit if <path> was\n   different between HEAD and the index (i.e. update-index was\n   used on it earlier).  This check was removed.\n\n - git-rm is much saner and safer.  It is used to remove paths\n   from both the index file and the working tree, and makes sure\n   you are not losing any local modification before doing so.\n\n - git-reset <tree> <paths>... can be used to revert index\n   entries for selected paths.\n\n - git-update-index is much less visible.\n\n\n* Repository layout and objects transfer\n\n - The data for origin repository is stored in the configuration\n   file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly\n   created clones (the latter is still supported).\n\n - git-clone always uses what is known as \"separate remote\"\n   layout for a newly created repository with a working tree;\n   i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are\n   used to track branches from the origin.  New branches that\n   appear on the origin side after a clone is made are also\n   tracked automatically.\n\n - git-branch and git-show-branch know remote tracking branches.\n\n - git-push can now be used to delete a remote branch or a tag.\n   This requires the updated git on the remote side.\n\n - git-push more agressively keeps the transferred objects\n   packed.  Earlier we recommended to monitor amount of loose\n   objects and repack regularly, but you should repack when you\n   accumulated too many small packs this way as well.  Updated\n   git-count-objects helps you with this.\n\n\n* Reflog\n\n - Reflog records the history of where the tip of each branch\n   was at each moment.  This facility is enabled by default for\n   repositories with working trees, and can be accessed with the\n   \"branch@{time}\" and \"branch@{Nth}\" notation.\n\n - \"git show-branch\" learned showing the reflog data with the\n   new --reflog option.\n\n - The commits referred to by reflog entries are now protected\n   against pruning.  The new command \"git reflog expire\" can be\n   used to truncate older reflog entries and entries that refer\n   to commits that have been pruned away previously with older\n   versions of git.\n\n   Existing repositories that have been using reflog may get\n   complaints from fsck-objects; please run \"git reflog expire\n   --all\" first to remove reflog entries that refer to commits\n   that are no longer in the repository before attempting to\n   repack it.\n\n - git-branch knows how to rename branches and moves existing\n   reflog data from the old branch to the new one.\n\n\n* Packed refs\n\n - Repositories with hundreds of tags have been paying large\n   overhead, both in storage and in runtime.  A new command,\n   git-pack-refs, can be used to \"pack\" them in more efficient\n   representation.\n\n - Clones and fetches over dumb transports are now aware of\n   packed refs and can download from repositories that use\n   them.\n\n\n* Configuration\n\n - configuration related to colorize setting are consolidated\n   under color.* namespace (older diff.color.*, status.color.*\n   are still supported).\n\n\n* Less external dependency\n\n - We no longer require the \"merge\" program from the RCS suite.\n   All 3-way file-level merges are now done internally.\n\n - The original implementation of git-merge-recursive which was\n   in Python has been removed; we have C implementation of it\n   now.\n\n - git-shortlog is no longer a Perl script.  It no longer\n   requires output piped from git-log; it can accept revision\n   parameters directly on the command line.\n\n\n* I18n\n\n - We have always encouraged the commit message to be encoded in\n   UTF-8, but the users are allowed to use legacy encoding as\n   appropriate for their projects.  This will continue to be the\n   case.  However, a non UTF-8 commit encoding _must_ be\n   explicitly set with i18n.commitencoding in the repository\n   where a commit is made; otherwise git-commit-tree will\n   complain if the log message does not look like a valid UTF-8\n   string.\n\n - The value of i18n.commitencoding in the originating\n   repository is recorded in the commit object on the \"encoding\"\n   header, if it is not UTF-8.  git-log and friends notice this,\n   and reencodes the message to the log output encoding when\n   displaying, if they are different.  The log output encoding\n   is determined by \"git log --encoding=<encoding>\",\n   i18n.logoutputencoding configuration, or i18n.commitencoding\n   configuration, in the decreasing order of preference, and\n   defaults to UTF-8. \n\n\n* User support\n\n - Quite a lot of documentation updates.\n\n - Bash completion scripts have been updated heavily.\n\n - Better error messages for often used Porcelainish commands.\n"},{"id":"30389","messageId":"20061228020305.GD16612@spearce.org","threadId":"6123","inReplyTo":"7vvejw3iaq.fsf@assigned-by-dhcp.cox.net","subject":"Re: An early draft of v1.5.0 release notes (2nd ed)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T02:03:05Z","receivedAt":"2006-12-28T02:03:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> \n> -- >8 --\n> \n> Major changes that are not news\n> -------------------------------\n\nIf these major changes aren't news, what are they?  Chopped liver?\nI'm highly confused by the section header.\n\n-- \nShawn.\n"},{"id":"30391","messageId":"7vmz583goc.fsf@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":"20061228020305.GD16612@spearce.org","subject":"Re: An early draft of v1.5.0 release notes (2nd ed)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T02:20:03Z","receivedAt":"2006-12-28T02:20:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> Junio C Hamano <junkio@cox.net> wrote:\n>> \n>> -- >8 --\n>> \n>> Major changes that are not news\n>> -------------------------------\n>\n> If these major changes aren't news, what are they?\n\nExactly as described in the part you did not quote:\n\n        There were a handful big changes that happened before this major\n        release.\n\n        This section is for people who are upgrading from ancient\n        versions.\n\nIn other words, they are only to help people who were not paying\nenough attention to earlier releases.\n"},{"id":"30394","messageId":"20061228022855.GF16612@spearce.org","threadId":"6123","inReplyTo":"7vmz583goc.fsf@assigned-by-dhcp.cox.net","subject":"Re: An early draft of v1.5.0 release notes (2nd ed)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T02:28:55Z","receivedAt":"2006-12-28T02:28:55Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> Shawn Pearce <spearce@spearce.org> writes:\n> \n> > Junio C Hamano <junkio@cox.net> wrote:\n> >> \n> >> -- >8 --\n> >> \n> >> Major changes that are not news\n> >> -------------------------------\n> >\n> > If these major changes aren't news, what are they?\n> \n> Exactly as described in the part you did not quote:\n> \n>         There were a handful big changes that happened before this major\n>         release.\n> \n>         This section is for people who are upgrading from ancient\n>         versions.\n> \n> In other words, they are only to help people who were not paying\n> enough attention to earlier releases.\n\nOK, yet again I don't quite quote enough.  Or read enough.  ;-)\n \nBut maybe you can title the section\n\n\tMajor changes since 1.2.x\n\n?  Or whatever version preceeded when we started to add that stuff?\n\nThe section is really for those who are upgrading from ancient\nversions, but the title of the section implies (at least to me)\nthat these changes aren't something important.\n\nJust my (nearly worthless against the Euro) two US pennies...\n\n-- \nShawn.\n"},{"id":"30395","messageId":"7vejqk3fom.fsf@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":"20061228022855.GF16612@spearce.org","subject":"Re: An early draft of v1.5.0 release notes (2nd ed)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T02:41:29Z","receivedAt":"2006-12-28T02:41:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> The section is really for those who are upgrading from ancient\n> versions, but the title of the section implies (at least to me)\n> that these changes aren't something important.\n\nTrue.  How about \"Something important you should already know\nbut just in case\" ;-)?\n"},{"id":"30396","messageId":"20061228024719.GG16612@spearce.org","threadId":"6123","inReplyTo":"7vejqk3fom.fsf@assigned-by-dhcp.cox.net","subject":"Re: An early draft of v1.5.0 release notes (2nd ed)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T02:47:19Z","receivedAt":"2006-12-28T02:47:19Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> Shawn Pearce <spearce@spearce.org> writes:\n> \n> > The section is really for those who are upgrading from ancient\n> > versions, but the title of the section implies (at least to me)\n> > that these changes aren't something important.\n> \n> True.  How about \"Something important you should already know\n> but just in case\" ;-)?\n\nSure, that's more fun then my proposed text and does summarize the\nsection better.  Plus it reminds Git users that maybe they should\ntrack our releases a little bit more often than only on \"major\"\nversion number increments.  :-)\n\n-- \nShawn.\n"},{"id":"30398","messageId":"20061228030317.GA2154@localdomain","threadId":"6123","inReplyTo":"7vvejx948y.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-12-28T03:03:18Z","receivedAt":"2006-12-28T03:03:18Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> ancient versions such as v1.1.6 or v1.2.0, and there are a\n> handful \"one-way-street upgrades\" and quite a few user visible\n> changes that already have happened before v1.4.4.  Namely:\n\nAddendum:\n\ngit-svn related changes:\n\n  - git-svn now requires the Perl SVN:: libraries, the\n    command-line backend was too slow and limited.\n\n  - the 'commit' command has been renamed to 'set-tree', and\n    'dcommit' is the recommended replacement for day-to-day\n    work.\n\n-- \nEric Wong\n"},{"id":"30400","messageId":"7vpsa41t3l.fsf@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":"20061228030317.GA2154@localdomain","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T05:34:38Z","receivedAt":"2006-12-28T05:34:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong <normalperson@yhbt.net> writes:\n\n> Addendum:\n>\n> git-svn related changes:\n\nThanks.\n"},{"id":"30401","messageId":"7vhcvg1s6o.fsf@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":"20061228024719.GG16612@spearce.org","subject":"Re: An early draft of v1.5.0 release notes (2nd ed)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T05:54:23Z","receivedAt":"2006-12-28T05:54:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> Junio C Hamano <junkio@cox.net> wrote:\n>> Shawn Pearce <spearce@spearce.org> writes:\n>> \n>> > The section is really for those who are upgrading from ancient\n>> > versions, but the title of the section implies (at least to me)\n>> > that these changes aren't something important.\n>> \n>> True.  How about \"Something important you should already know\n>> but just in case\" ;-)?\n>\n> Sure, that's more fun then my proposed text and does summarize the\n> section better.  Plus it reminds Git users that maybe they should\n> track our releases a little bit more often than only on \"major\"\n> version number increments.  :-)\n\nThat was a tongue-in-cheek comment.\n\nI consider git is still young and I have the right to gripe at\nthe list if something that has been cooking in 'next' without\nanybody complaining causes a real breakage immediately after it\ngets pushed out to 'master'.  But for the rest of the world, git\nhas already matured enough that there is much less need to be on\nthe bleeding edge for the lack of something crucial in the last\nreleased version.\n\nAnd let's face it.  Nobody has enough time to keep track of the\nchanges to all tools he uses, it is not unusual to skip a\nhandful of minor versions, and it is a norm to get surprised\nafter an upgrade of any tool because there was a major change in\na couple of releases back that he skipped.  I do not have the\nright to complain if the end users do not follow every minor\nrelease or every issue of \"What's in git.git\" messages.  Not\nanymore.\n\nSo I'd like the introductory section to have more positive\nspin.  I tried rewording it and pushed it out to 'todo' branch.\n"},{"id":"31367","messageId":"7vsleje2jh.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6123","inReplyTo":"7vvejw3iaq.fsf@assigned-by-dhcp.cox.net","subject":"Re: An early draft of v1.5.0 release notes (3rd ed)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-10T07:58:26Z","receivedAt":"2007-01-10T07:58:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Instead of sending the full text, I'll send out the diff against\nthe one I sent out on the 27th last month.\n\n Highlights:\n\n * Introductory notes have been reworded heavily;\n\n * I intend to merge bare repository support and detached HEAD\n   before v1.5.0, so a section each for them has been added;\n\n * Sliding mmap and shallow clone are also mentioned.\n\nThe full text is available as v1.5.0.txt in 'todo' branch.\n\n--\n v1.5.0.txt |  180 +++++++++++++++++++++++++++++++++++++++++++++++++----------\n 1 files changed, 149 insertions(+), 31 deletions(-)\n\ndiff --git a/v1.5.0.txt b/v1.5.0.txt\nindex 671c14b..9bbe825 100644\n--- a/v1.5.0.txt\n+++ b/v1.5.0.txt\n@@ -1,37 +1,54 @@\n-Major changes that are not news\n--------------------------------\n+GIT v1.5.0 Release Notes\n+========================\n \n-There were a handful big changes that happened before this major\n-release.\n+Old news\n+--------\n \n This section is for people who are upgrading from ancient\n-versions.  Some of them are one-way street upgrades -- once you\n-use the feature your repository cannot be used with ancient git.\n-\n- - There is a new configuration variable core.legacyheaders that\n-   changes the format of loose objects to more efficient to pack\n-   and send out of the repository over git native protocol.\n-   However, this format cannot be read by git older than v1.4.2;\n-   people fetching from your repository using older clients over\n-   dumb transports (e.g. http) will also be affected.  This is\n-   not enabled by default.\n-\n- - Another configuration repack.usedeltabaseoffset further\n-   allows packfile to be created in more space efficient format,\n-   which cannot be read  by git older than v1.4.3.  This is not\n-   enabled by default.\n+versions of git.  Although all of the changes in this section\n+happened before the current v1.4.4 release, they are summarized\n+here in the v1.5.0 release notes for people who skipped earlier\n+versions.\n+\n+In general, you should not have to worry about incompatibility,\n+and there is no need to perform \"repository conversion\" if you\n+are updating to v1.5.0.  However, some of the changes are\n+one-way street upgrades; once you use them your repository\n+can no longer be used with ancient git.\n+\n+ - There is a configuration variable core.legacyheaders that\n+   changes the format of loose objects so that they are more\n+   efficient to pack and to send out of the repository over git\n+   native protocol, since v1.4.2.  However, loose objects\n+   written in the new format cannot be read by git older than\n+   that version; people fetching from your repository using\n+   older clients over dumb transports (e.g. http) using older\n+   versions of git will also be affected.\n+\n+ - Since v1.4.3, configuration repack.usedeltabaseoffset allows\n+   packfile to be created in more space efficient format, which\n+   cannot be read by git older than that version.\n+\n+The above two are not enabled by default and you explicitly have\n+to ask for them, because these two features make repositories\n+unreadable by older versions of git, and in v1.5.0 we still do\n+not enable them by default for the same reason.  We will change\n+this default probably 1 year after 1.4.2's release, when it is\n+reasonable to expect everybody to have new enough version of\n+git.\n \n  - 'git pack-refs' appeared in v1.4.4; this command allows tags\n    to be accessed much more efficiently than the traditional\n-   'one-file-per-tag' format.  Older git-native client can fetch\n-   from a repository that packed its tags, but older dumb\n-   transports cannot.  This is done by an explicit user action,\n-   either by use of \"git pack-refs --prune\" command or by use of\n-   \"git gc\" command.\n+   'one-file-per-tag' format.  Older git-native clients can\n+   still fetch from a repository that packed and pruned refs\n+   (the server side needs to run the up-to-date version of git),\n+   but older dumb transports cannot.  Packing of refs is done by\n+   an explicit user action, either by use of \"git pack-refs\n+   --prune\" command or by use of \"git gc\" command.\n \n  - 'git -p' to paginate anything -- many commands do pagination\n    by default on a tty.  Introduced between v1.4.1 and v1.4.2;\n-   this may surprise old timer users.\n+   this may surprise old timers.\n \n  - 'git archive' superseded 'git tar' in v1.4.3;\n \n@@ -43,7 +60,10 @@ use the feature your repository cannot be used with ancient git.\n  - 'gitweb' became part of git.git during v1.4.0 timeperiod and\n    seriously modified since then.\n \n- - reflog is an v1.4.0 invention.\n+ - reflog is an v1.4.0 invention.  This allows you to name a\n+   revision that a branch used to be at (e.g. \"git diff\n+   master@{yesterday} master\" allows you to see changes since\n+   yesterday's tip of the branch).\n \n \n Updates in v1.5.0 since v1.4.4 series\n@@ -80,7 +100,9 @@ Updates in v1.5.0 since v1.4.4 series\n \n  - The data for origin repository is stored in the configuration\n    file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly\n-   created clones (the latter is still supported).\n+   created clones.  The latter is still supported and there is\n+   no need to convert your existing repository if you are\n+   already comfortable with your workflow with the layout.\n \n  - git-clone always uses what is known as \"separate remote\"\n    layout for a newly created repository with a working tree;\n@@ -100,6 +122,26 @@ Updates in v1.5.0 since v1.4.4 series\n    accumulated too many small packs this way as well.  Updated\n    git-count-objects helps you with this.\n \n+ - A new command, git-remote, can help you manage your remote\n+   tracking branch definitions.\n+\n+\n+* Bare repositories\n+\n+ - Certain commands change their behaviour in a bare repository\n+   (i.e. a repository without associated working tree).  We use\n+   a fairly conservative heuristic (if $GIT_DIR is \".git\", or\n+   ends with \"/.git\", the repository is not bare) to decide if a\n+   repository is bare, but \"core.bare\" configuration variable\n+   can be used to override the heuristic when it misidentifies\n+   your repository.\n+\n+ - git-fetch used to complain updating the current branch but\n+   this is now allowed for a bare repository.\n+\n+ - NEEDSWORK: We should disable Porcelain-ish commands that\n+   require a working tree in a bare repository.\n+\n \n * Reflog\n \n@@ -118,15 +160,42 @@ Updates in v1.5.0 since v1.4.4 series\n    versions of git.\n \n    Existing repositories that have been using reflog may get\n-   complaints from fsck-objects; please run \"git reflog expire\n-   --all\" first to remove reflog entries that refer to commits\n-   that are no longer in the repository before attempting to\n-   repack it.\n+   complaints from fsck-objects and may not be able to run\n+   git-repack; please run \"git reflog expire --all\" first to\n+   remove reflog entries that refer to commits that are no\n+   longer in the repository when that happens.\n \n  - git-branch knows how to rename branches and moves existing\n    reflog data from the old branch to the new one.\n \n \n+* Detached HEAD\n+\n+ - You can give non-branch to \"git checkout\" now.  This will\n+   dissociate your HEAD from any of your branches.  A typical\n+   use of this feature is to \"look around\".  E.g.\n+\n+\t$ git checkout v2.6.16\n+\t... compile, test, etc.\n+\t$ git checkout v2.6.17\n+\t... compile, test, etc.\n+\n+ - After detaching your HEAD, you can go back to an existing\n+   branch with usual \"git checkout $branch\".  Also you can\n+   start a new branch using \"git checkout -b $newbranch\".\n+\n+ - You can even pull from other repositories, make merges and\n+   commits while your HEAD is detached.  Also you can use \"git\n+   reset\" to jump to arbitrary commit.\n+\n+   Going back to undetached state by \"git checkout $branch\" can\n+   lose the current stat you arrived in these ways, and \"git\n+   checkout\" refuses when the detached HEAD is not pointed by\n+   any existing ref (an existing branch, a remote tracking\n+   branch or a tag).  This safety can be overriden with \"git\n+   checout -f\".\n+\n+\n * Packed refs\n \n  - Repositories with hundreds of tags have been paying large\n@@ -181,6 +250,24 @@ Updates in v1.5.0 since v1.4.4 series\n    configuration, in the decreasing order of preference, and\n    defaults to UTF-8. \n \n+ - Tools for e-mailed patch application now default to -u\n+   behaviour; i.e. it always re-codes from the e-mailed encoding\n+   to the encoding specified with i18n.commitencoding.  This\n+   unfortunately forces projects that have happily using a\n+   legacy encoding without setting i18n.commitencoding, but\n+   taken with other improvement, please excuse us for this very\n+   minor one-time inconvenience.\n+\n+\n+* Foreign SCM interfaces\n+\n+  - git-svn now requires the Perl SVN:: libraries, the\n+    command-line backend was too slow and limited.\n+\n+  - the 'commit' subcommand of git-svn has been renamed to\n+    'set-tree', and 'dcommit' is the recommended replacement for\n+    day-to-day work.\n+\n \n * User support\n \n@@ -191,4 +278,35 @@ Updates in v1.5.0 since v1.4.4 series\n  - Better error messages for often used Porcelainish commands.\n \n \n+* Sliding mmap\n+\n+ - We used to assume that we can mmap the whole packfile while\n+   in use, but with a large project this consumes huge virtual\n+   memory space and truly huge ones would not fit in the\n+   userland address space on 32-bit platforms.  We now mmap huge\n+   packfile in pieces to avoid this problem.\n+\n+\n+* Shallow clones\n+\n+ - There is a partial support for 'shallow' repositories that\n+   keeps only recent history now.  A 'shallow clone' is created\n+   by specifying how deep that truncated history should be.\n+\n+   Currently a shallow repository has number of limitations:\n+\n+   - Cloning and fetching _from_ a shallow clone are not\n+     supported (nor tested -- so they might work by accident but\n+     they are not expected to).\n+\n+   - Pushing from nor into a shallow clone are not expected to\n+     work.\n+\n+   - Merging inside a shallow repository would work as long as a\n+     merge base is found in the recent history, but otherwise it\n+     will be like merging unrelated histories and may result in\n+     huge conflicts.\n \n+   but this would be more than adequate for people who want to\n+   look at near the tip of a big project with a deep history and\n+   send patches in e-mail format.\n"}]}