# [RFH] An early draft of v1.5.0 release notes 20 messages from 2006-12-27 to 2007-01-10. Participants: Junio C Hamano, Shawn Pearce, Jakub Narebski, Johannes Schindelin, Eric Wong. Thread: https://gitlist.dev/t/6123 ## Junio C Hamano, 2006-12-27 07:39 Subject: [RFH] An early draft of v1.5.0 release notes Message-ID: <7vvejx948y.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vvejx948y.fsf%40assigned-by-dhcp.cox.net ``` This is still rough, but I think we have a pretty good idea what will and what won't be in v1.5.0 by now, and end-of-year is a good slow time to summarize what we have done. One thing I am wondering is if delta from v1.4.4.3 is good enough for the intended audience of this release notes. I am reasonably sure that the name v1.5.0 will attract more people than usual and there will be many people upgrading directly from ancient versions such as v1.1.6 or v1.2.0, and there are a handful "one-way-street upgrades" and quite a few user visible changes that already have happened before v1.4.4. Namely: - Pack-compatible loose object headers, introduced between v1.4.1 and v1.4.2; repository cannot be read with ancient version of git anymore -- this is a one-way street but core.legacyheaders is still not enabled by default); - delta-base-offset pack encoding, introduced between v1.4.2 and v1.4.3; this is also a one-way street. - '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 timer users. - 'git archive' superseded 'git tar' in v1.4.3; - 'git pack-refs' appeared in v1.4.4; - '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 v1.4.0 invention. In the following, I am assuming that jc/utf8 and jc/fsck-reflog topics currently in 'next' will be part of v1.5.0. -- >8 -- 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. Say "git add ." if you want to. - git-add tries to be more friendly to users by offering an interactive mode. - git-commit used to refuse to commit if 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 ... can be used to revert index entries for selected paths. - git-update-index is much less visible. * Repository layout - 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). - 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. - git-clone used to be buggy and copied refs outside refs/heads and refs/tags; it doesn't anymore. - git-branch and git-show-branch know remote tracking branches. - git-push can now be used to delete a remote branch or a tag. * 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. - 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. Existing repositories that have been using reflog may get complaints from fsck-objects; please run "git reflog expire --all" first to remove reflog entries that refer to commits that are no longer in the repository before attempting to repack it. - git-branch knows how to rename branches and moves existing reflog data from the old branch to the new one. * Packed refs - Repositories with hundreds of tags have been paying large overhead, both in storage and in runtime. 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 colorize setting are consolidated under color.* namespace (older diff.color.*, status.color.* are still supported). * Less external dependency - We have been depended on "merge" program from RCS suite for the file-level 3-way merge, but now we lost this dependency. - The original implementation of git-merge-recursive which was in Python has been removed; we have C implementation of it now. - git-shortlog is not in Perl anymore, and more importantly it does not have to be piped output from git-log. It can traverse the commit ancestry itself. * 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 (which will never change). A non UTF-8 commit encoding however _must_ be explicitly set with i18n.commitencoding in the repository configuration; otherwise git-commit-tree will complain if the log message does not look like a valid UTF-8 string. - A commit object recorded in non UTF-8 encoding records the encoding i18n.commitencoding specified in the originating repository in a new "encoding" header. This information is used by git-log and friends to reencode the message to UTF-8 when displaying. * User support - Quite a lot of documentation updates. - Bash completion scripts have been updated heavily. - Better error messages for often used Porcelainish commands. ---------------------------------------------------------------- (shortlog since v1.4.4.3 here) ``` ## Shawn Pearce, 2006-12-27 08:18 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <20061227081819.GB23022@spearce.org> URL: https://gitlist.dev/e/20061227081819.GB23022%40spearce.org In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > This is still rough, but I think we have a pretty good idea what > will and what won't be in v1.5.0 by now, and end-of-year is a > good slow time to summarize what we have done. This is certainly a good idea. And your summary was pretty good too, I enjoyed the read. This group has certainly accomplished quite a bit lately! Just a few comments: > - Pack-compatible loose object headers, introduced between > v1.4.1 and v1.4.2; repository cannot be read with ancient > version of git anymore -- this is a one-way street but > core.legacyheaders is still not enabled by default); > > - delta-base-offset pack encoding, introduced between v1.4.2 > and v1.4.3; this is also a one-way street. Perhaps you can clarify that using these means the repository cannot be used with an earlier version of Git? You may also want to highlight why these features are good, answering the question "Why should I enable them if it breaks backwards compatibility?". Isn't the new packed-refs format also a one-way street? If you use them for tags on a web server and the client is using a very old http commit walker, what happens? > - git-clone used to be buggy and copied refs outside refs/heads > and refs/tags; it doesn't anymore. I mentioned to you on #git this morning that I don't think this is noteworthy for this release. You missed talking about the mess of pack files created by git-push now, especially with pushes over 100 objects. ;-) > - git-push can now be used to delete a remote branch or a tag. You should mention this requires server side support too. I read that and assumed I could just upgrade my client and push to delete - which isn't the case, and I know its not... but I still read it that way. > - "git show-branch" learned showing the reflog data with the > new --reflog option. I had hoped we could get 'git reflog show' into 1.5.0 but the current discussion with Johannes seems like that's unlikely. > - We have been depended on "merge" program from RCS suite for > the file-level 3-way merge, but now we lost this dependency. Perhaps just reword as: We no longer require the "merge" program from the RCS suite. All 3-way file-level merges are now done internally. > - git-shortlog is not in Perl anymore, and more importantly it > does not have to be piped output from git-log. It can > traverse the commit ancestry itself. The "traverse the commit ancestry itself" part is not very readable for the average user. How about instead: git-shortlog is no longer a Perl script. git-shortlog also no longer requires output piped from git-log; it can accept revision parameters directly on the command line. -- Shawn. ``` ## Jakub Narebski, 2006-12-27 10:12 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: URL: https://gitlist.dev/e/emtgps%24f1q%241%40sea.gmane.org In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > This is still rough, but I think we have a pretty good idea what > will and what won't be in v1.5.0 by now, and end-of-year is a > good slow time to summarize what we have done. Very nice idea! Perhaps those release notes can find it's way into either v1.5.0 commit, or v1.5.0 tag comment? Just a few comments: > - git-add without any argument does not add everything > anymore. Say "git add ." if you want to. > > - git-add tries to be more friendly to users by offering an > interactive mode. Perhaps information that git-add can be used to add ignored files with -f option should be added? Or is it not important enough? > - 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. > > Existing repositories that have been using reflog may get > complaints from fsck-objects; please run "git reflog expire > --all" first to remove reflog entries that refer to commits > that are no longer in the repository before attempting to > repack it. That's a bit bad, as it forces to lose some info... but that info was not that useful anyway. > - A commit object recorded in non UTF-8 encoding records the > encoding i18n.commitencoding specified in the originating > repository in a new "encoding" header. This information is > used by git-log and friends to reencode the message to UTF-8 > when displaying. I don't quite like it. Why if someone uses different encoding that utf-8 because his terminal is not set to utf-8? Having suddenly what looks like garbage on output, while input was in local encoding (and specified in i18n.commitencoding) is a bit suprising... > ---------------------------------------------------------------- > (shortlog since v1.4.4.3 here) I'd rather have description a la "what's cooking" here... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Junio C Hamano, 2006-12-27 10:24 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v1wml8wmw.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Jakub Narebski writes: > That's a bit bad, as it forces to lose some info... but that > info was not that useful anyway. I am tired of listening to this useless FUD of yours. You lost the information when you pruned away the underlying objects; you are not losing information when you expire the reflog entries that became useless long time ago. > I don't quite like it. Why if someone uses different encoding > that utf-8 because his terminal is not set to utf-8? Having suddenly > what looks like garbage on output, while input was in local encoding > (and specified in i18n.commitencoding) is a bit suprising... If Luben wants UTF-8 in his project, but somebody he pulled from was mistakenly used latin-1, then the commit pulled record latin-1 while Luben has i18n.commitencoding in his repository set to UTF-8. Output will be done in UTF-8 for Luben. For the originator of that latin-1 commit, i18n.commitencoding says latin-1 (and that was the only reason he managed to create such a commit) and git show of that commit would not involve recoding. At least that is the idea. Have you spotted a bug, perhaps? >> (shortlog since v1.4.4.3 here) > > I'd rather have description a la "what's cooking" here... Send the summary to the list and I'll append it to the release notes. ``` ## Junio C Hamano, 2006-12-27 10:50 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <7vvejx7gty.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vvejx7gty.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Jakub Narebski writes: > Just a few comments: > >> - git-add without any argument does not add everything >> anymore. Say "git add ." if you want to. > > Perhaps information that git-add can be used to add ignored files > with -f option should be added? Or is it not important enough? Thanks. Will change the above bullet to this: - 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. ``` ## Johannes Schindelin, 2006-12-27 11:54 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0612271251060.19693%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Wed, 27 Dec 2006, Junio C Hamano wrote: > Jakub Narebski writes: > > > I don't quite like it. Why if someone uses different encoding > > that utf-8 because his terminal is not set to utf-8? Having suddenly > > what looks like garbage on output, while input was in local encoding > > (and specified in i18n.commitencoding) is a bit suprising... > > If Luben wants UTF-8 in his project, but somebody he pulled from was > mistakenly used latin-1, then the commit pulled record latin-1 while > Luben has i18n.commitencoding in his repository set to UTF-8. Output > will be done in UTF-8 for Luben. For the originator of that latin-1 > commit, i18n.commitencoding says latin-1 (and that was the only reason > he managed to create such a commit) and git show of that commit would > not involve recoding. I think that this is a misunderstanding. Maybe the config variable is misnamed. As is clearly visible from the commit messages, this whole stuff is meant to reencode to whatever encoding the caller of git-log likes, not just UTF-8. And it defaults to UTF-8, overridable by i18n.commitEncoding. BTW I think that latin-1 is not a valid encoding name (at least in my setup it isn't), so we should rather talk about iso-8859-1. Ciao, Dscho ``` ## Jakub Narebski, 2006-12-27 12:12 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <200612271312.15877.jnareb@gmail.com> URL: https://gitlist.dev/e/200612271312.15877.jnareb%40gmail.com In-Reply-To: <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Jakub Narebski writes: >> Junio C Hamano wrote: >>> >>>  - 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. >>> >>>    Existing repositories that have been using reflog may get >>>    complaints from fsck-objects; please run "git reflog expire >>>    --all" first to remove reflog entries that refer to commits >>>    that are no longer in the repository before attempting to >>>    repack it. >> >> That's a bit bad, as it forces to lose some info... but that >> info was not that useful anyway. > > I am tired of listening to this useless FUD of yours. You lost > the information when you pruned away the underlying objects; you > are not losing information when you expire the reflog entries > that became useless long time ago. Sorry, this is a bit of my inner packrat ;-) showing thru. I'd rather use "git reflog expire --pruned" to remove reflog entries which refer to commits which are no longer in the repository; I don't know, perhaps "git reflog expire --all" does that: but there is no Documentation/git-reflog.txt (and I'm not running 'next' nor 'master' but 1.4.4.3). So most probably it is just the case of adding an alias to reflog expire option. >>> - A commit object recorded in non UTF-8 encoding records the >>> encoding i18n.commitencoding specified in the originating >>> repository in a new "encoding" header. This information is >>> used by git-log and friends to reencode the message to UTF-8 >>> when displaying. >> >> I don't quite like it. Why if someone uses different encoding >> that utf-8 because his terminal is not set to utf-8? Having suddenly >> what looks like garbage on output, while input was in local encoding >> (and specified in i18n.commitencoding) is a bit suprising... > > If Luben wants UTF-8 in his project, but somebody he pulled from > was mistakenly used latin-1, then the commit pulled record > latin-1 while Luben has i18n.commitencoding in his repository > set to UTF-8. Output will be done in UTF-8 for Luben. For the > originator of that latin-1 commit, i18n.commitencoding says > latin-1 (and that was the only reason he managed to create such > a commit) and git show of that commit would not involve > recoding. > > At least that is the idea. Have you spotted a bug, perhaps? Perhaps that is the idea, but that idea is not described in above new feature announcement. "... to reencode the message to UTF-8 when displaying, if needed." would cover it, but perhaps better would be to cover this in more detail: "reencode message to UTF-8 if i18n.commitencoding is not set to something other than UTF-8", or "reencode ... to i18n.commitencoding ... if needed". BTW. what happens for NO_ICONV? Just curious... -- Jakub Narebski Poland ``` ## Jakub Narebski, 2006-12-27 12:15 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <200612271315.05250.jnareb@gmail.com> URL: https://gitlist.dev/e/200612271315.05250.jnareb%40gmail.com In-Reply-To: ``` Johannes Schindelin wrote: > BTW I think that latin-1 is not a valid encoding name (at least in my > setup it isn't), so we should rather talk about iso-8859-1. "iconv --list" include l1 and latin1 as aliases to the proper name of encoding, i.e. iso-8859-1; but not latin-2. -- Jakub Narebski Poland ``` ## Junio C Hamano, 2006-12-27 19:45 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <7vpsa55dhw.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vpsa55dhw.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200612271312.15877.jnareb@gmail.com> ``` Jakub Narebski writes: > ... I don't > know, perhaps "git reflog expire --all" does that: but there is no > Documentation/git-reflog.txt (and I'm not running 'next' nor 'master' > but 1.4.4.3)... If that is the case, may I ask you to at least please make it a habit to read what are relevant to the topic under discussion before jumping in? The list traffic is already high enough that I am spending a lot of time just to skim all the messages posted here -- I think that time is better spent on development and improvements. ``` ## Jakub Narebski, 2006-12-28 00:32 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: URL: https://gitlist.dev/e/emv367%24sua%241%40sea.gmane.org In-Reply-To: <200612271312.15877.jnareb@gmail.com> ``` Jakub Narebski wrote: > Junio C Hamano wrote: >> Jakub Narebski writes: >>> Junio C Hamano wrote: >>>> >>>>  - 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. >>>> >>>>    Existing repositories that have been using reflog may get >>>>    complaints from fsck-objects; please run "git reflog expire >>>>    --all" first to remove reflog entries that refer to commits >>>>    that are no longer in the repository before attempting to >>>>    repack it. [...] > I'd rather use "git reflog expire --pruned" to remove reflog entries > which refer to commits which are no longer in the repository; I don't > know, perhaps "git reflog expire --all" does that: but there is no > Documentation/git-reflog.txt (and I'm not running 'next' nor 'master' > but 1.4.4.3). So most probably it is just the case of adding an alias > to reflog expire option. Thanks for adding Documentation/git-reflog.txt. Nevertheless it didn't add the information that "git reflog expire" removes reflog entries that refer to commits that are no longer in the repository (see attached patch). I'm not sure if such technical information should be in git-reflog(1), but does only second, current sha1 in reflog line matters for prune? And does expiring rewrite reflog (previous sha1, making always previous sha1 (first sha1 in reflog line) always to refer some commit in earlier reflog line, or before first reflog line), or only delete lines? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git >From c39e864dec5fc5542e9dd14235a48fa2bb77ed6a Mon Sep 17 00:00:00 2001 From: Jakub Narebski Date: Thu, 28 Dec 2006 01:30:05 +0100 Subject: [PATCH] Add information in git-reflog(1) that "expire" removes pruned entries Add information to Documentation/git-reflog.txt that "expire" subcommand also removes entries which refer to commits that are no longer in repository. Signed-off-by: Jakub Narebski --- Documentation/git-reflog.txt | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt index 55a24d3..04ea51a 100644 --- a/Documentation/git-reflog.txt +++ b/Documentation/git-reflog.txt @@ -22,11 +22,12 @@ updated. This command is to manage the information recorded in it. The subcommand "expire" is used to prune older reflog entries. Entries older than `expire` time, or entries older than `expire-unreachable` time and are not reachable from the current -tip, are removed from the reflog. This is typically not used +tip, are removed from the reflog. Entries which refer to +commits that are no longer in the repository are pruned +regardless of their age. This command is typically not used directly by the end users -- instead, see gitlink:git-gc[1]. - OPTIONS ------- -- 1.4.4.3 ``` ## Junio C Hamano, 2006-12-28 01:45 Subject: An early draft of v1.5.0 release notes (2nd ed) Message-ID: <7vvejw3iaq.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vvejw3iaq.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net> ``` This incorporates comments from the list (thanks). Maybe I should park this in 'todo' branch so that people can review the updates more easily. -- >8 -- Major changes that are not news ------------------------------- There were a handful big changes that happened before this major release. This section is for people who are upgrading from ancient versions. Some of them are one-way street upgrades -- once you use the feature your repository cannot be used with ancient git. - There is a new configuration variable core.legacyheaders that changes the format of loose objects to more efficient to pack and send out of the repository over git native protocol. However, this format cannot be read by git older than v1.4.2; people fetching from your repository using older clients over dumb transports (e.g. http) will also be affected. This is not enabled by default. - Another configuration repack.usedeltabaseoffset further allows packfile to be created in more space efficient format, which cannot be read by git older than v1.4.3. This is not enabled by default. - '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 client can fetch from a repository that packed its tags, but older dumb transports cannot. This 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 timer users. - 'git archive' superseded 'git tar' 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. 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 used to refuse to commit if 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 ... 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). - 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. - 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. * 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. - 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; please run "git reflog expire --all" first to remove reflog entries that refer to commits that are no longer in the repository before attempting to repack it. - git-branch knows how to rename branches and moves existing reflog data from the old branch to the new one. * Packed refs - Repositories with hundreds of tags have been paying large overhead, both in storage and in runtime. 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 colorize 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=", i18n.logoutputencoding configuration, or i18n.commitencoding configuration, in the decreasing order of preference, and defaults to UTF-8. * User support - Quite a lot of documentation updates. - Bash completion scripts have been updated heavily. - Better error messages for often used Porcelainish commands. ``` ## Shawn Pearce, 2006-12-28 02:03 Subject: Re: An early draft of v1.5.0 release notes (2nd ed) Message-ID: <20061228020305.GD16612@spearce.org> URL: https://gitlist.dev/e/20061228020305.GD16612%40spearce.org In-Reply-To: <7vvejw3iaq.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > > -- >8 -- > > Major changes that are not news > ------------------------------- If these major changes aren't news, what are they? Chopped liver? I'm highly confused by the section header. -- Shawn. ``` ## Junio C Hamano, 2006-12-28 02:20 Subject: Re: An early draft of v1.5.0 release notes (2nd ed) Message-ID: <7vmz583goc.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vmz583goc.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061228020305.GD16612@spearce.org> ``` Shawn Pearce writes: > Junio C Hamano wrote: >> >> -- >8 -- >> >> Major changes that are not news >> ------------------------------- > > If these major changes aren't news, what are they? Exactly as described in the part you did not quote: There were a handful big changes that happened before this major release. This section is for people who are upgrading from ancient versions. In other words, they are only to help people who were not paying enough attention to earlier releases. ``` ## Shawn Pearce, 2006-12-28 02:28 Subject: Re: An early draft of v1.5.0 release notes (2nd ed) Message-ID: <20061228022855.GF16612@spearce.org> URL: https://gitlist.dev/e/20061228022855.GF16612%40spearce.org In-Reply-To: <7vmz583goc.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Shawn Pearce writes: > > > Junio C Hamano wrote: > >> > >> -- >8 -- > >> > >> Major changes that are not news > >> ------------------------------- > > > > If these major changes aren't news, what are they? > > Exactly as described in the part you did not quote: > > There were a handful big changes that happened before this major > release. > > This section is for people who are upgrading from ancient > versions. > > In other words, they are only to help people who were not paying > enough attention to earlier releases. OK, yet again I don't quite quote enough. Or read enough. ;-) But maybe you can title the section Major changes since 1.2.x ? Or whatever version preceeded when we started to add that stuff? The section is really for those who are upgrading from ancient versions, but the title of the section implies (at least to me) that these changes aren't something important. Just my (nearly worthless against the Euro) two US pennies... -- Shawn. ``` ## Junio C Hamano, 2006-12-28 02:41 Subject: Re: An early draft of v1.5.0 release notes (2nd ed) Message-ID: <7vejqk3fom.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vejqk3fom.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061228022855.GF16612@spearce.org> ``` Shawn Pearce writes: > The section is really for those who are upgrading from ancient > versions, but the title of the section implies (at least to me) > that these changes aren't something important. True. How about "Something important you should already know but just in case" ;-)? ``` ## Shawn Pearce, 2006-12-28 02:47 Subject: Re: An early draft of v1.5.0 release notes (2nd ed) Message-ID: <20061228024719.GG16612@spearce.org> URL: https://gitlist.dev/e/20061228024719.GG16612%40spearce.org In-Reply-To: <7vejqk3fom.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Shawn Pearce writes: > > > The section is really for those who are upgrading from ancient > > versions, but the title of the section implies (at least to me) > > that these changes aren't something important. > > True. How about "Something important you should already know > but just in case" ;-)? Sure, that's more fun then my proposed text and does summarize the section better. Plus it reminds Git users that maybe they should track our releases a little bit more often than only on "major" version number increments. :-) -- Shawn. ``` ## Eric Wong, 2006-12-28 03:03 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <20061228030317.GA2154@localdomain> URL: https://gitlist.dev/e/20061228030317.GA2154%40localdomain In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > ancient versions such as v1.1.6 or v1.2.0, and there are a > handful "one-way-street upgrades" and quite a few user visible > changes that already have happened before v1.4.4. Namely: Addendum: git-svn related changes: - git-svn now requires the Perl SVN:: libraries, the command-line backend was too slow and limited. - the 'commit' command has been renamed to 'set-tree', and 'dcommit' is the recommended replacement for day-to-day work. -- Eric Wong ``` ## Junio C Hamano, 2006-12-28 05:34 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <7vpsa41t3l.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vpsa41t3l.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061228030317.GA2154@localdomain> ``` Eric Wong writes: > Addendum: > > git-svn related changes: Thanks. ``` ## Junio C Hamano, 2006-12-28 05:54 Subject: Re: An early draft of v1.5.0 release notes (2nd ed) Message-ID: <7vhcvg1s6o.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vhcvg1s6o.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061228024719.GG16612@spearce.org> ``` Shawn Pearce writes: > Junio C Hamano wrote: >> Shawn Pearce writes: >> >> > The section is really for those who are upgrading from ancient >> > versions, but the title of the section implies (at least to me) >> > that these changes aren't something important. >> >> True. How about "Something important you should already know >> but just in case" ;-)? > > Sure, that's more fun then my proposed text and does summarize the > section better. Plus it reminds Git users that maybe they should > track our releases a little bit more often than only on "major" > version number increments. :-) That was a tongue-in-cheek comment. I consider git is still young and I have the right to gripe at the list if something that has been cooking in 'next' without anybody complaining causes a real breakage immediately after it gets pushed out to 'master'. But for the rest of the world, git has already matured enough that there is much less need to be on the bleeding edge for the lack of something crucial in the last released version. And let's face it. Nobody has enough time to keep track of the changes to all tools he uses, it is not unusual to skip a handful of minor versions, and it is a norm to get surprised after an upgrade of any tool because there was a major change in a couple of releases back that he skipped. I do not have the right to complain if the end users do not follow every minor release or every issue of "What's in git.git" messages. Not anymore. So I'd like the introductory section to have more positive spin. I tried rewording it and pushed it out to 'todo' branch. ``` ## Junio C Hamano, 2007-01-10 07:58 Subject: Re: An early draft of v1.5.0 release notes (3rd ed) Message-ID: <7vsleje2jh.fsf_-_@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vsleje2jh.fsf_-_%40assigned-by-dhcp.cox.net In-Reply-To: <7vvejw3iaq.fsf@assigned-by-dhcp.cox.net> ``` Instead of sending the full text, I'll send out the diff against the one I sent out on the 27th last month. Highlights: * Introductory notes have been reworded heavily; * I intend to merge bare repository support and detached HEAD before v1.5.0, so a section each for them has been added; * Sliding mmap and shallow clone are also mentioned. The full text is available as v1.5.0.txt in 'todo' branch. -- v1.5.0.txt | 180 +++++++++++++++++++++++++++++++++++++++++++++++++---------- 1 files changed, 149 insertions(+), 31 deletions(-) diff --git a/v1.5.0.txt b/v1.5.0.txt index 671c14b..9bbe825 100644 --- a/v1.5.0.txt +++ b/v1.5.0.txt @@ -1,37 +1,54 @@ -Major changes that are not news -------------------------------- +GIT v1.5.0 Release Notes +======================== -There were a handful big changes that happened before this major -release. +Old news +-------- This section is for people who are upgrading from ancient -versions. Some of them are one-way street upgrades -- once you -use the feature your repository cannot be used with ancient git. - - - There is a new configuration variable core.legacyheaders that - changes the format of loose objects to more efficient to pack - and send out of the repository over git native protocol. - However, this format cannot be read by git older than v1.4.2; - people fetching from your repository using older clients over - dumb transports (e.g. http) will also be affected. This is - not enabled by default. - - - Another configuration repack.usedeltabaseoffset further - allows packfile to be created in more space efficient format, - which cannot be read by git older than v1.4.3. This is not - enabled by default. +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 client can fetch - from a repository that packed its tags, but older dumb - transports cannot. This is done by an explicit user action, - either by use of "git pack-refs --prune" command or by use of - "git gc" command. + '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 timer users. + this may surprise old timers. - 'git archive' superseded 'git tar' in v1.4.3; @@ -43,7 +60,10 @@ use the feature your repository cannot be used with ancient git. - 'gitweb' became part of git.git during v1.4.0 timeperiod and seriously modified since then. - - reflog is an v1.4.0 invention. + - 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 @@ -80,7 +100,9 @@ Updates in v1.5.0 since v1.4.4 series - 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). + 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; @@ -100,6 +122,26 @@ Updates in v1.5.0 since v1.4.4 series 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. + + - NEEDSWORK: We should disable Porcelain-ish commands that + require a working tree in a bare repository. + * Reflog @@ -118,15 +160,42 @@ Updates in v1.5.0 since v1.4.4 series versions of git. Existing repositories that have been using reflog may get - complaints from fsck-objects; please run "git reflog expire - --all" first to remove reflog entries that refer to commits - that are no longer in the repository before attempting to - repack it. + complaints from fsck-objects and may not be able to run + git-repack; please run "git reflog expire --all" first to + remove reflog entries that refer to commits that are no + longer in the repository when that happens. - git-branch knows how to rename branches and moves existing reflog data from the old branch to the new one. +* 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 + checout -f". + + * Packed refs - Repositories with hundreds of tags have been paying large @@ -181,6 +250,24 @@ Updates in v1.5.0 since v1.4.4 series 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 using a + legacy encoding without setting i18n.commitencoding, but + taken with other improvement, please excuse us for this very + minor one-time inconvenience. + + +* 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 @@ -191,4 +278,35 @@ Updates in v1.5.0 since v1.4.4 series - 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 now. 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. ```