{"thread":{"id":"6187","subject":"Draft v1.5.0 release notes","startedAt":"2007-01-02T00:08:39Z","lastAt":"2007-01-02T08:23:06Z","messageCount":5,"participants":["Junio C Hamano","Steven Grimm","Shawn O. Pearce","David Kågedal"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30635","messageId":"7vlkkm47eg.fsf@assigned-by-dhcp.cox.net","threadId":"6187","inReplyTo":null,"subject":"Draft v1.5.0 release notes","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T00:08:39Z","receivedAt":"2007-01-02T00:08:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The latest draft is kept as 'todo:v1.5.0.txt'.  Since I've\nmerged the shallow clone changes, I've added a few sentences for\nthe series as well.\n\n--\n\nGIT v1.5.0 Release Notes\n========================\n\nOld news\n--------\n\nThis section is for people who are upgrading from ancient\nversions of git.  Although all of the changes in this section\nhappened before the current v1.4.4 release, they are summarized\nhere in the v1.5.0 release notes for people who skipped earlier\nversions.\n\nIn general, you should not have to worry about incompatibility,\nand there is no need to perform \"repository conversion\" if you\nare updating to v1.5.0.  However, some of the changes are\none-way street upgrades; once you use them your repository\ncan 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, this format cannot\n   be read by git older than that version; people fetching from\n   your repository using older clients over dumb transports\n   (e.g. http) using older versions of git will also be\n   affected.  This is not enabled by default.\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.  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 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 timers.\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.  This alows 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\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 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   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* 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' command has been renamed to 'set-tree', and\n    'dcommit' is the recommended replacement for day-to-day\n    work.\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* 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"},{"id":"30646","messageId":"4599C3E8.5060209@midwinter.com","threadId":"6187","inReplyTo":"7vlkkm47eg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Draft v1.5.0 release notes","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-02T02:31:04Z","receivedAt":"2007-01-02T02:31:04Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\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, this format cannot\n>    be read by git older than that version; people fetching from\n>    your repository using older clients over dumb transports\n>    (e.g. http) using older versions of git will also be\n>    affected.  This is not enabled by default.\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.  This is not\n>    enabled by default.\n>   \n\nFor people in non-public development environments, where there's \nabsolutely no possibility of someone hitting a repo with an old client, \npresumably these options should both be enabled. I wonder if it makes \nsense to add an option to git-init-db to create a configuration file \nwith all the latest stuff enabled -- or better still, something like\n\ngit-init-db --min-version=1.4.2\n\nthat would enable all the non-backward-compatible stuff in the newly \ncreated repository. And then a special case \"--min-version=current\" to \nuse all the most optimal settings for the current release, useful in \nenvironments like corporate LANs where the tool versions are centrally \nmanaged.\n\nLikewise, something like\n\ngit-repo-config --min-version=1.5.0\n\ncould be used to set all the options in an existing repo (presumably \nthis would not allow you to move backwards, just upgrade) for cases \nwhere clients are known to have all upgraded to at least a particular \nversion.\n\nMaybe that last purpose would be better served by a \"git-upgrade\" \ncommand that, for example, could rebuild old packfiles in the new more \nefficient format and write out the appropriate configuration. Though one \nwould have to take pains to point out that running that command was NOT \na required step when upgrading to a new git release, and would in fact \nbe a bad idea for projects being accessed by older clients.\n\n-Steve\n"},{"id":"30647","messageId":"20070102025748.GA27690@spearce.org","threadId":"6187","inReplyTo":"4599C3E8.5060209@midwinter.com","subject":"Re: Draft v1.5.0 release notes","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-02T02:57:48Z","receivedAt":"2007-01-02T02:57:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Steven Grimm <koreth@midwinter.com> wrote:\n> Junio C Hamano wrote:\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, this format cannot\n> >   be read by git older than that version; people fetching from\n> >   your repository using older clients over dumb transports\n> >   (e.g. http) using older versions of git will also be\n> >   affected.  This is not enabled by default.\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.  This is not\n> >   enabled by default.\n> >  \n> \n> For people in non-public development environments where there's \n> absolutely no possibility of someone hitting a repo with an old client, \n> presumably these options should both be enabled.\n\nOr even in public ones, but where access by dumb clients isn't\noffered (only anonymous or ssh based git native protocol is used).\n\n> I wonder if it makes \n> sense to add an option to git-init-db to create a configuration file \n> with all the latest stuff enabled -- or better still, something like\n> \n> git-init-db --min-version=1.4.2\n\nThat's an interesting idea.  Most users don't invoke init-db directly\nhowever, they are using clone to copy someone else's repository.\nBut that option could easily be offered on both commands, with\nclone just passing it through to init-db.\n \n> that would enable all the non-backward-compatible stuff in the newly \n> created repository. And then a special case \"--min-version=current\" to \n> use all the most optimal settings for the current release, useful in \n> environments like corporate LANs where the tool versions are centrally \n> managed.\n\nActually I wonder if \"--min-version=current\" shouldn't just be the\ndefault.  Most users are going to init-db or clone locally and use\nonly the current version of Git (or later) against that repository.\n\nThough that probably would break someone who runs multiple versions\nof Git on the same system, because they have some strange reason\nfor doing so[*1*].  And it would certainly cause problems for\nusers who then rsync that repository (or scp it) to a webhost and\nexpect users with older versions of Git to be able to access it\nwith a commit-walker client.  But that would be less of a problem\nif we could teach users to first clone their repository before\npublishing it, e.g.:\n\n    git clone --bare --min-version=1.2 . ../myproj.git\n\n\n*1*: I'm not talking about Git developers here.  I think most Git\n     developers run a `production` version of Git that they use for\n     actual revisioning, and other versions for testing, and those\n     testing versions are only used against testing repositories\n     that hold non-live data.\n\n-- \nShawn.\n"},{"id":"30661","messageId":"87vejp7v0m.fsf@morpheus.local","threadId":"6187","inReplyTo":"7vlkkm47eg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Draft v1.5.0 release notes","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-01-02T07:22:33Z","receivedAt":"2007-01-02T07:22:33Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\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' command has been renamed to 'set-tree', and\n>     'dcommit' is the recommended replacement for day-to-day\n>     work.\n\nThe second item in this list is misleading.  It states that the\n\"comit\" subcommand has been renamed.  But I don't believe it's the\n\"commit\" subcommand of the \"git\" command.  So what is it a subcommand\nto?\n\n-- \nDavid Kågedal\n"},{"id":"30662","messageId":"20070102082306.GE27690@spearce.org","threadId":"6187","inReplyTo":"87vejp7v0m.fsf@morpheus.local","subject":"Re: Draft v1.5.0 release notes","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-02T08:23:06Z","receivedAt":"2007-01-02T08:23:06Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David K?gedal <davidk@lysator.liu.se> wrote:\n> Junio C Hamano <junkio@cox.net> writes:\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' command has been renamed to 'set-tree', and\n> >     'dcommit' is the recommended replacement for day-to-day\n> >     work.\n> \n> The second item in this list is misleading.  It states that the\n> \"comit\" subcommand has been renamed.  But I don't believe it's the\n> \"commit\" subcommand of the \"git\" command.  So what is it a subcommand\n> to?\n\ngit-svn.  As in `git svn commit` is now `git svn set-tree`.\n\nI agree with your point though.  My early readings of the above\nquoted section just assumed git-svn, as I knew that was what Junio\nwas talking about.  Now that I read it again, I have to agree that\nit is not quite as clear as I had originally thought.\n\n-- \nShawn.\n"}]}