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