* [ANNOUNCE] GIT 1.5.1 @ 2007-04-04 9:12 Junio C Hamano 2007-04-04 9:38 ` Andy Parkins 2007-04-04 18:26 ` A note from the maintainer Junio C Hamano 0 siblings, 2 replies; 8+ messages in thread From: Junio C Hamano @ 2007-04-04 9:12 UTC (permalink / raw) To: git; +Cc: linux-kernel The latest feature release GIT 1.5.1 is available at the usual places: http://www.kernel.org/pub/software/scm/git/ git-1.5.1.tar.{gz,bz2} (tarball) git-htmldocs-1.5.1.tar.{gz,bz2} (preformatted docs) git-manpages-1.5.1.tar.{gz,bz2} (preformatted docs) RPMS/$arch/git-*-1.5.1-1.$arch.rpm (RPM) ---------------------------------------------------------------- GIT v1.5.1 Release Notes ======================== Updates since v1.5.0 -------------------- * Deprecated commands and options. - git-diff-stages and git-resolve have been removed. * New commands and options. - "git log" and friends take --reverse, which instructs them to give their output in the order opposite from their usual. They typically output from new to old, but with this option their output would read from old to new. "git shortlog" usually lists older commits first, but with this option, they are shown from new to old. - "git log --pretty=format:<string>" to allow more flexible custom log output. - "git diff" learned --ignore-space-at-eol. This is a weaker form of --ignore-space-change. - "git diff --no-index pathA pathB" can be used as diff replacement with git specific enhancements. - "git diff --no-index" can read from '-' (standard input). - "git diff" also learned --exit-code to exit with non-zero status when it found differences. In the future we might want to make this the default but that would be a rather big backward incompatible change; it will stay as an option for now. - "git diff --quiet" is --exit-code with output turned off, meant for scripted use to quickly determine if there is any tree-level difference. - Textual patch generation with "git diff" without -w/-b option has been significantly optimized. "git blame" got faster because of the same change. - "git log" and "git rev-list" has been optimized significantly when they are used with pathspecs. - "git branch --track" can be used to set up configuration variables to help it easier to base your work on branches you track from a remote site. - "git format-patch --attach" now emits attachments. Use --inline to get an inlined multipart/mixed. - "git name-rev" learned --refs=<pattern>, to limit the tags used for naming the given revisions only to the ones matching the given pattern. - "git remote update" is to run "git fetch" for defined remotes to update tracking branches. - "git cvsimport" can now take '-d' to talk with a CVS repository different from what are recorded in CVS/Root (overriding it with environment CVSROOT does not work). - "git bundle" can help sneaker-netting your changes between repositories. - "git mergetool" can help 3-way file-level conflict resolution with your favorite graphical merge tools. - A new configuration "core.symlinks" can be used to disable symlinks on filesystems that do not support them; they are checked out as regular files instead. - You can name a commit object with its first line of the message. The syntax to use is ':/message text'. E.g. $ git show ":/object name: introduce ':/<oneline prefix>' notation" means the same thing as: $ git show 28a4d940443806412effa246ecc7768a21553ec7 - "git bisect" learned a new command "run" that takes a script to run after each revision is checked out to determine if it is good or bad, to automate the bisection process. - "git log" family learned a new traversal option --first-parent, which does what the name suggests. * Updated behavior of existing commands. - "git-merge-recursive" used to barf when there are more than one common ancestors for the merge, and merging them had a rename/rename conflict. This has been fixed. - "git fsck" does not barf on corrupt loose objects. - "git rm" does not remove newly added files without -f. - "git archimport" allows remapping when coming up with git branch names from arch names. - git-svn got almost a rewrite. - core.autocrlf configuration, when set to 'true', makes git to convert CRLF at the end of lines in text files to LF when reading from the filesystem, and convert in reverse when writing to the filesystem. The variable can be set to 'input', in which case the conversion happens only while reading from the filesystem but files are written out with LF at the end of lines. Currently, which paths to consider 'text' (i.e. be subjected to the autocrlf mechanism) is decided purely based on the contents, but the plan is to allow users to explicitly override this heuristic based on paths. - The behavior of 'git-apply', when run in a subdirectory, without --index nor --cached were inconsistent with that of the command with these options. This was fixed to match the behavior with --index. A patch that is meant to be applied with -p1 from the toplevel of the project tree can be applied with any custom -p<n> option. A patch that is not relative to the toplevel needs to be applied with -p<n> option with or without --index (or --cached). - "git diff" outputs a trailing HT when pathnames have embedded SP on +++/--- header lines, in order to help "GNU patch" to parse its output. "git apply" was already updated to accept this modified output format since ce74618d (Sep 22, 2006). - "git cvsserver" runs hooks/update and honors its exit status. - "git cvsserver" can be told to send everything with -kb. - "git diff --check" also honors the --color output option. - "git name-rev" used to stress the fact that a ref is a tag too much, by saying something like "v1.2.3^0~22". It now says "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does not talk about an ancestor of the commit that is tagged, which makes sense). - "git rev-list --boundary" now shows boundary markers for the commits omitted by --max-age and --max-count condition. - The configuration mechanism now reads $(prefix)/etc/gitconfig. - "git apply --verbose" shows what preimage lines were wanted when it couldn't find them. - "git status" in a read-only repository got a bit saner. - "git fetch" (hence "git clone" and "git pull") are less noisy when the output does not go to tty. - "git fetch" between repositories with many refs were slow even when there are not many changes that needed transferring. This has been sped up by partially rewriting the heaviest parts in C. - "git mailinfo" which splits an e-mail into a patch and the meta-information was rewritten, thanks to Don Zickus. It handles nested multipart better. The command was broken for a brief period on 'master' branch since 1.5.0 but the breakage is fixed now. - send-email learned configurable bcc and chain-reply-to. - "git remote show $remote" also talks about branches that would be pushed if you run "git push remote". - Using objects from packs is now seriously optimized by clever use of a cache. This should be most noticeable in git-log family of commands that involve reading many tree objects. In addition, traversing revisions while filtering changes with pathspecs is made faster by terminating the comparison between the trees as early as possible. * Hooks - The part to send out notification e-mails was removed from the sample update hook, as it was not an appropriate place to do so. The proper place to do this is the new post-receive hook. An example hook has been added to contrib/hooks/. * Others - git-revert, git-gc and git-cherry-pick are now built-ins. Fixes since v1.5.0 ------------------ These are all in v1.5.0.x series. * Documentation updates - Clarifications and corrections to 1.5.0 release notes. - The main documentation did not link to git-remote documentation. - Clarified introductory text of git-rebase documentation. - Converted remaining mentions of update-index on Porcelain documents to git-add/git-rm. - Some i18n.* configuration variables were incorrectly described as core.*; fixed. - added and clarified core.bare, core.legacyheaders configurations. - updated "git-clone --depth" documentation. - user-manual updates. - Options to 'git remote add' were described insufficiently. - Configuration format.suffix was not documented. - Other formatting and spelling fixes. - user-manual has better cross references. - gitweb installation/deployment procedure is now documented. * Bugfixes - git-upload-pack closes unused pipe ends; earlier this caused many zombies to hang around. - git-rerere was recording the contents of earlier hunks duplicated in later hunks. This prevented resolving the same conflict when performing the same merge the other way around. - git-add and git-update-index on a filesystem on which executable bits are unreliable incorrectly reused st_mode bits even when the path changed between symlink and regular file. - git-daemon marks the listening sockets with FD_CLOEXEC so that it won't be leaked into the children. - segfault from git-blame when the mandatory pathname parameter was missing was fixed; usage() message is given instead. - git-rev-list did not read $GIT_DIR/config file, which means that did not honor i18n.logoutputencoding correctly. - Automated merge conflict handling when changes to symbolic links conflicted were completely broken. The merge-resolve strategy created a regular file with conflict markers in it in place of the symbolic link. The default strategy, merge-recursive was even more broken. It removed the path that was pointed at by the symbolic link. Both of these problems have been fixed. - 'git diff maint master next' did not correctly give combined diff across three trees. - 'git fast-import' portability fix for Solaris. - 'git show-ref --verify' without arguments did not error out but segfaulted. - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra slashes after a/ and b/. - 'git format-patch' produced too long filenames if the commit message had too long line at the beginning. - Running 'make all' and then without changing anything running 'make install' still rebuilt some files. This was inconvenient when building as yourself and then installing as root (especially problematic when the source directory is on NFS and root is mapped to nobody). - 'git-rerere' failed to deal with two unconflicted paths that sorted next to each other. - 'git-rerere' attempted to open(2) a symlink and failed if there was a conflict. Since a conflicting change to a symlink would not benefit from rerere anyway, the command now ignores conflicting changes to symlinks. - 'git-repack' did not like to pass more than 64 arguments internally to underlying 'rev-list' logic, which made it impossible to repack after accumulating many (small) packs in the repository. - 'git-diff' to review the combined diff during a conflicted merge were not reading the working tree version correctly when changes to a symbolic link conflicted. It should have read the data using readlink(2) but read from the regular file the symbolic link pointed at. - 'git-remote' did not like period in a remote's name. - 'git.el' honors the commit coding system from the configuration. - 'blameview' in contrib/ correctly digs deeper when a line is clicked. - 'http-push' correctly makes sure the remote side has leading path. Earlier it started in the middle of the path, and incorrectly. - 'git-merge' did not exit with non-zero status when the working tree was dirty and cannot fast forward. It does now. - 'cvsexportcommit' does not lose yet-to-be-used message file. - int-vs-size_t typefix when running combined diff on files over 2GB long. - 'git apply --whitespace=strip' should not touch unmodified lines. - 'git-mailinfo' choke when a logical header line was too long. - 'git show A..B' did not error out. Negative ref ("not A" in this example) does not make sense for the purpose of the command, so now it errors out. - 'git fmt-merge-msg --file' without file parameter did not correctly error out. - 'git archimport' barfed upon encountering a commit without summary. - 'git index-pack' did not protect itself from getting a short read out of pread(2). - 'git http-push' had a few buffer overruns. - Build dependency fixes to rebuild fetch.o when other headers change. - git.el does not add duplicate sign-off lines. - git-commit shows the full stat of the resulting commit, not just about the files in the current directory, when run from a subdirectory. - "git-checkout -m '@{8 hours ago}'" had a funny failure from eval; fixed. - git-merge (hence git-pull) did not refuse fast-forwarding when the working tree had local changes that would have conflicted with it. - a handful small fixes to gitweb. - build procedure for user-manual is fixed not to require locally installed stylesheets. - "git commit $paths" on paths whose earlier contents were already updated in the index were failing out. * Tweaks - sliding mmap() inefficiently mmaped the same region of a packfile with an access pattern that used objects in the reverse order. This has been made more efficient. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCE] GIT 1.5.1 2007-04-04 9:12 [ANNOUNCE] GIT 1.5.1 Junio C Hamano @ 2007-04-04 9:38 ` Andy Parkins 2007-04-04 10:16 ` Junio C Hamano 2007-04-04 18:26 ` A note from the maintainer Junio C Hamano 1 sibling, 1 reply; 8+ messages in thread From: Andy Parkins @ 2007-04-04 9:38 UTC (permalink / raw) To: git; +Cc: Junio C Hamano On Wednesday 2007 April 04 10:12, Junio C Hamano wrote: > * Deprecated commands and options. > > - git-diff-stages and git-resolve have been removed. For future reference: If a feature has been removed then it isn't really correct to call it "deprecated". Deprecate means "to disapprove of" or, in this context, that "the use of this feature is discouraged and a suitable alternative probably exists". To deprecate a feature implies that one could still use it if you wanted but it should not be relied on to exist in the future. If a feature no longer exists then describing it as "removed" is sufficient. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@gmail.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCE] GIT 1.5.1 2007-04-04 9:38 ` Andy Parkins @ 2007-04-04 10:16 ` Junio C Hamano 2007-04-04 11:09 ` Matthieu Moy 0 siblings, 1 reply; 8+ messages in thread From: Junio C Hamano @ 2007-04-04 10:16 UTC (permalink / raw) To: Andy Parkins; +Cc: git Andy Parkins <andyparkins@gmail.com> writes: > On Wednesday 2007 April 04 10:12, Junio C Hamano wrote: > >> * Deprecated commands and options. >> >> - git-diff-stages and git-resolve have been removed. > > For future reference: > ... Thanks -- that's very true. I meant that they are loooong deprecated, and finally we removed them in this release. I do not think there are any candidate for scheduled removal right now, but I suspect perhaps applymbox might go sometime in the future. We will deprecate them and after a long period of time (well, long is a relative word but in git timescale it probably means 6 months) will remove them. But I do not see it happening any time soon. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCE] GIT 1.5.1 2007-04-04 10:16 ` Junio C Hamano @ 2007-04-04 11:09 ` Matthieu Moy 2007-04-06 5:41 ` Junio C Hamano 0 siblings, 1 reply; 8+ messages in thread From: Matthieu Moy @ 2007-04-04 11:09 UTC (permalink / raw) To: git Junio C Hamano <junkio@cox.net> writes: > Thanks -- that's very true. I meant that they are loooong > deprecated, and finally we removed them in this release. In a perfect world, the release notes would mention the reason for the removal (e.g. "use git foo-bar instead"). -- Matthieu ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCE] GIT 1.5.1 2007-04-04 11:09 ` Matthieu Moy @ 2007-04-06 5:41 ` Junio C Hamano 2007-04-06 7:24 ` Matthieu Moy 0 siblings, 1 reply; 8+ messages in thread From: Junio C Hamano @ 2007-04-06 5:41 UTC (permalink / raw) To: Matthieu Moy; +Cc: git Matthieu Moy <Matthieu.Moy@imag.fr> writes: > Junio C Hamano <junkio@cox.net> writes: > >> Thanks -- that's very true. I meant that they are loooong >> deprecated, and finally we removed them in this release. > > In a perfect world, the release notes would mention the reason for the > removal (e.g. "use git foo-bar instead"). Soon after 1.5.0 was released, I think we said these two were not used in practice and declared them as deprecated. So there is no "use this instead". In a perfect world, nobody would kibitz, but instead everybody reads, understands and remembers the discussion that led to the change ;-) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCE] GIT 1.5.1 2007-04-06 5:41 ` Junio C Hamano @ 2007-04-06 7:24 ` Matthieu Moy 0 siblings, 0 replies; 8+ messages in thread From: Matthieu Moy @ 2007-04-06 7:24 UTC (permalink / raw) To: git Junio C Hamano <junkio@cox.net> writes: > Soon after 1.5.0 was released, I think we said these two were > not used in practice and declared them as deprecated. So there > is no "use this instead". $ man git-resolve | grep -i 'use .* instead' Reformatting git-resolve(1), please wait... DEPRECATED and will be removed in 1.5.1. Use git-merge instead. ;-) -- Matthieu ^ permalink raw reply [flat|nested] 8+ messages in thread
* A note from the maintainer 2007-04-04 9:12 [ANNOUNCE] GIT 1.5.1 Junio C Hamano 2007-04-04 9:38 ` Andy Parkins @ 2007-04-04 18:26 ` Junio C Hamano 2007-05-20 9:54 ` Junio C Hamano 1 sibling, 1 reply; 8+ messages in thread From: Junio C Hamano @ 2007-04-04 18:26 UTC (permalink / raw) To: git Now a new feature release is out, it's time to welcome new people to the list. This message talks about how git.git is managed, and how you can work with it. * IRC and Mailing list Many active members of development community hang around on #git IRC channel. Its log is available at: http://colabti.de/irclogger/irclogger_log/git The development however is primarily done on this mailing list you are reading right now. If you have patches, please send them to the list, following Documentation/SubmittingPatches. I usually read all patches posted to the list, and follow almost all the discussions on the list, unless the topic is about an obscure corner that I do not personally use. But I am obviously not perfect. If you sent a patch that you did not hear from anybody for three days, that is a very good indication that it was dropped on the floor --- please do not hesitate to remind me. The list archive is available at a few public sites as well: http://marc.theaimsgroup.com/?l=git http://news.gmane.org/gmane.comp.version-control.git and some people seem to prefer to read it over NNTP: nntp://news.gmane.org/gmane.comp.version-control.git * Repositories, branches and documentation. My public git.git repository is at: git://git.kernel.org/pub/scm/git/git.git/ This is mirrored at Pasky's site at git://repo.or.cz/git.git/ but the first has a few hours mirroring delay after I publish updates, and the latter, being a mirror of former, lags behind it further. Immediately after I publish to the primary repository at kernel.org, I also push into an alternate here: git://repo.or.cz/alt-git.git/ Impatient people would have better luck with the last one (but the last repository does not have "html", "man" and "todo" branches, described next). There are three branches in git.git repository that are not about the source tree of git: "todo", "html" and "man". The first one was meant to contain TODO list for me, but I am not good at maintaining such a list so it is not as often updated as it could/should be. It also contains some helper scripts I use to maintain git. The "html" and "man" are autogenerated documentation from the tip of the "master" branch; the tip of "html" is extracted to be visible at kernel.org at: http://www.kernel.org/pub/software/scm/git/docs/ The above URL is the top-level documentation page, and it has links to documentation of older releases. The script to maintain these two documentation branches are found in "todo" branch as dodoc.sh, if you are interested. It is a good demonstration of how to use an update hook to automate a task. There are four branches in git.git repository that track the source tree of git: "master", "maint", "next", and "pu". The "master" branch is meant to contain what are very well tested and ready to be used in a production setting. There could occasionally be minor breakages or brown paper bag bugs but they are not expected to be anything major. Every now and then, a "feature release" is cut from the tip of this branch and they typically are named with three dotted decimal digits. The last such release was v1.5.1 done on April 4th this year. Whenever a feature release is made, "maint" branch is forked off from "master" at that point. Obvious, safe and urgent fixes after a feature release are applied to this branch and maintenance releases are cut from it. The maintenance releases are named with four dotted decimal, named after the feature release they are updates to; the last such release was v1.5.0.7. New features never goes to this branch. This branch is also merged into "master" to propagate the fixes forward. A trivial and safe enhancement goes directly on top of "master". A new development, either initiated by myself or more often by somebody who found his or her own itch to scratch, does not usually happen on "master", however. Instead, a separate topic branch is forked from the tip of "master", and it first is tested in isolation; I may make minimum fixups at this point. Usually there are a handful such topic branches that are running ahead of "master" in git.git repository. I do not publish the tip of these branches in my public repository, however, partly to keep the number of branches that downstream developers need to worry about low, and primarily because I am lazy. I judge the quality of topic branches, taking advices from the mailing list discussions. Some of them start out as "good idea but obviously is broken in some areas (e.g. breaks the existing testsuite)" and then with some more work (either by the original contributor or help from other people on the list) becomes "more or less done and can now be tested by wider audience". Luckily, most of them start out in the latter, better shape. The "next" branch is to merge and test topic branches in the latter category. In general, the branch always contains the tip of "master". It might not be quite rock-solid production ready, but is expected to work more or less without major breakage. I usually use "next" version of git for my own work, so it cannot be _that_ broken to prevent me from pushing the changes out. The "next" branch is where new and exciting things take place. The above three branches, "master", "maint" and "next" are never rewound, so you should be able to safely track them (this automatically means the topics that have been merged into "next" are not rebased, and you can find the tip of topic branches you are interested in out of "git log next" output). The "pu" (proposed updates) branch bundles all the remainder of topic branches. The "pu" branch, and topic branches that are only in "pu", are subject to rebasing in general. When a topic that was in "pu" proves to be in testable shape, it graduates to "next". I do this with: git checkout next git merge that-topic-branch Sometimes, an idea that looked promising turns out to be not so hot and the topic can be dropped from "pu" in such a case. A topic that is in "next" is expected to be tweaked and fixed to perfection before it is merged to "master". Similarly to the above I do it with this: git checkout master git merge that-topic-branch git branch -d that-topic-branch However, being in "next" is not a guarantee to appear in the next release (being in "master" is such a guarantee, unless it is later found seriously broken and reverted), or even in any future release. There even were cases that topics needed a few reverting before graduating to "master", or a topic that already was in "next" were reverted from "next" because fatal flaws were found in them later. Starting from v1.5.0, "master" and "maint" have release notes for the next release in Documentation/RelNotes-* files, so that I do not have to run around summarizing what happened just before the release. * Other people's trees, trusted lieutenants and credits. Documentation/SubmittingPatches outlines who your changes should be sent to. As described in contrib/README, I would delegate fixes and enhancements in contrib/ area to primary contributors of them. Although the following are included in git.git repository, they have their own authoritative repository and maintainers: git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui project, which is found at: git://repo.or.cz/git-gui.git gitk -- this file is maintained by Paul Packerras, at: git://git.kernel.org/pub/scm/gitk/gitk.git I would like to thank everybody who helped to raise git into the current shape. Especially I would like to thank the git list regulars whose help I have relied on and expect to continue relying on heavily: - Linus on general design issues. - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, and Rene Scharfe on general implementation issues. - Shawn and Nicolas Pitre on pack issues. - Martin Langhoff on cvsserver and cvsimport. - Paul Packerras on gitk. - Eric Wong on git-svn. - Jakub Narebski and Luben Tuikov on gitweb. - J. Bruce Fields on documentaton issues. ^ permalink raw reply [flat|nested] 8+ messages in thread
* A note from the maintainer 2007-04-04 18:26 ` A note from the maintainer Junio C Hamano @ 2007-05-20 9:54 ` Junio C Hamano 0 siblings, 0 replies; 8+ messages in thread From: Junio C Hamano @ 2007-05-20 9:54 UTC (permalink / raw) To: git Now a new feature release is out, it's a good time to welcome new people to the list. This message talks about how git.git is managed, and how you can work with it. * IRC and Mailing list Many active members of development community hang around on #git IRC channel. Its log is available at: http://colabti.de/irclogger/irclogger_log/git The development however is primarily done on this mailing list you are reading right now. If you have patches, please send them to the list, following Documentation/SubmittingPatches. I usually try to read all patches posted to the list, and follow almost all the discussions on the list, unless the topic is about an obscure corner that I do not personally use. But I am obviously not perfect. If you sent a patch that you did not hear from anybody for three days, that is a very good indication that it was dropped on the floor --- please do not hesitate to remind me. The list archive is available at a few public sites as well: http://marc.theaimsgroup.com/?l=git http://news.gmane.org/gmane.comp.version-control.git http://www.spinics.net/lists/git/ and some people seem to prefer to read it over NNTP: nntp://news.gmane.org/gmane.comp.version-control.git * Repositories, branches and documentation. My public git.git repository is at: git://git.kernel.org/pub/scm/git/git.git/ Immediately after I publish to the primary repository at kernel.org, I also push into an alternate here: git://repo.or.cz/alt-git.git/ Impatient people would have better luck with the latter one, but it does not have "html" and "man" branches (described below). There are three branches in git.git repository that are not about the source tree of git: "todo", "html" and "man". The first one was meant to contain TODO list for me, but I am not good at maintaining such a list so it is not as often updated as it could/should be. It also contains some helper scripts I use to maintain git. The "html" and "man" are autogenerated documentation from the tip of the "master" branch; the tip of "html" is extracted to be visible at kernel.org at: http://www.kernel.org/pub/software/scm/git/docs/ The above URL is the top-level documentation page, and it has links to documentation of older releases. The script to maintain these two documentation branches are found in "todo" branch as dodoc.sh, if you are interested. It is a good demonstration of how to use an update hook to automate a task. There are four branches in git.git repository that track the source tree of git: "master", "maint", "next", and "pu". I may add more maintenance branches (e.g. "maint-1.5.1") if we have huge backward incompatible feature updates in the future to keep an older release alive; I may not, but the distributed nature of git means any volunteer can run a stable-tree like that himself. The "master" branch is meant to contain what are very well tested and ready to be used in a production setting. There could occasionally be minor breakages or brown paper bag bugs but they are not expected to be anything major. Every now and then, a "feature release" is cut from the tip of this branch and they typically are named with three dotted decimal digits. The last such release was v1.5.2 done on May 20th this year. Whenever a feature release is made, "maint" branch is forked off from "master" at that point. Obvious, safe and urgent fixes after a feature release are applied to this branch and maintenance releases are cut from it. The maintenance releases are named with four dotted decimal, named after the feature release they are updates to; the last such release was v1.5.1.6. New features never go to this branch. This branch is also merged into "master" to propagate the fixes forward. A trivial and safe enhancement goes directly on top of "master". A new development, either initiated by myself or more often by somebody who found his or her own itch to scratch, does not usually happen on "master", however. Instead, a separate topic branch is forked from the tip of "master", and it first is tested in isolation; I may make minimum fixups at this point. Usually there are a handful such topic branches that are running ahead of "master" in git.git repository. I do not publish the tip of these branches in my public repository, however, partly to keep the number of branches that downstream developers need to worry about low, and primarily because I am lazy. I judge the quality of topic branches, taking advices from the mailing list discussions. Some of them start out as "good idea but obviously is broken in some areas (e.g. breaks the existing testsuite)" and then with some more work (either by the original contributor or help from other people on the list) becomes "more or less done and can now be tested by wider audience". Luckily, most of them start out in the latter, better shape. The "next" branch is to merge and test topic branches in the latter category. In general, the branch always contains the tip of "master". It might not be quite rock-solid production ready, but is expected to work more or less without major breakage. I usually use "next" version of git for my own work, so it cannot be _that_ broken to prevent me from pushing the changes out. The "next" branch is where new and exciting things take place. The above three branches, "master", "maint" and "next" are never rewound, so you should be able to safely track them (this automatically means the topics that have been merged into "next" are not rebased, and you can find the tip of topic branches you are interested in from the output of "git log next"). The "pu" (proposed updates) branch bundles all the remainder of topic branches. The "pu" branch, and topic branches that are only in "pu", are subject to rebasing in general. When a topic that was in "pu" proves to be in testable shape, it graduates to "next". I do this with: git checkout next git merge that-topic-branch Sometimes, an idea that looked promising turns out to be not so hot and the topic can be dropped from "pu" in such a case. A topic that is in "next" is expected to be tweaked and fixed to perfection before it is merged to "master" (that's why "master" can be expected to stay very stable). Similarly to the above I do it with this: git checkout master git merge that-topic-branch git branch -d that-topic-branch However, being in "next" is not a guarantee to appear in the next release (being in "master" is such a guarantee, unless it is later found seriously broken and reverted), or even in any future release. There even were cases that topics needed reverting a few commits in them before graduating to "master", or a topic that already was in "next" were entirely reverted from "next" because fatal flaws were found in them later. Starting from v1.5.0, "master" and "maint" have release notes for the next release in Documentation/RelNotes-* files, so that I do not have to run around summarizing what happened just before the release. * Other people's trees, trusted lieutenants and credits. Documentation/SubmittingPatches outlines who your changes should be sent to. As described in contrib/README, I would delegate fixes and enhancements in contrib/ area to primary contributors of them. Although the following are included in git.git repository, they have their own authoritative repository and maintainers: git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui project, which is found at: git://repo.or.cz/git-gui.git gitk -- this file is maintained by Paul Mackerras, at: git://git.kernel.org/pub/scm/gitk/gitk.git I would like to thank everybody who helped to raise git into the current shape. Especially I would like to thank the git list regulars whose help I have relied on and expect to continue relying on heavily: - Linus on general design issues. - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, and Rene Scharfe on general implementation issues. - Shawn and Nicolas Pitre on pack issues. - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport. - Paul Mackerras on gitk. - Eric Wong on git-svn. - Jakub Narebski, Peter Baudis, and Luben Tuikov on gitweb. - J. Bruce Fields on documentaton issues. * This document The latest copy of this document is found in git.git repository, on 'todo' branch, as MaintNotes. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-05-20 9:54 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-04-04 9:12 [ANNOUNCE] GIT 1.5.1 Junio C Hamano 2007-04-04 9:38 ` Andy Parkins 2007-04-04 10:16 ` Junio C Hamano 2007-04-04 11:09 ` Matthieu Moy 2007-04-06 5:41 ` Junio C Hamano 2007-04-06 7:24 ` Matthieu Moy 2007-04-04 18:26 ` A note from the maintainer Junio C Hamano 2007-05-20 9:54 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).