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 <path> used to refuse to commit if <path> was
different between HEAD and the index (i.e. update-index was
used on it earlier). This check was removed.
- git-rm is much saner and safer. It is used to remove paths
from both the index file and the working tree, and makes sure
you are not losing any local modification before doing so.
- git-reset <tree> <paths>... can be used to revert index
entries for selected paths.
- git-update-index is much less visible.
* Repository layout
- 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)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html