{"thread":{"id":"13203","subject":"[ANNOUNCE] GIT 1.5.5.1","startedAt":"2008-04-21T22:48:59Z","lastAt":"2008-04-22T20:22:32Z","messageCount":7,"participants":["Junio C Hamano","Dmitry Potapov","Brandon Casey","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74888","messageId":"7vej8yako4.fsf@gitster.siamese.dyndns.org","threadId":"13203","inReplyTo":null,"subject":"[ANNOUNCE] GIT 1.5.5.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-21T22:48:59Z","receivedAt":"2008-04-21T22:48:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The latest maintenance release GIT 1.5.5.1 is available at the\nusual places:\n\n  http://www.kernel.org/pub/software/scm/git/\n\n  git-1.5.5.1.tar.{gz,bz2}\t\t\t(tarball)\n  git-htmldocs-1.5.5.1.tar.{gz,bz2}\t\t(preformatted docs)\n  git-manpages-1.5.5.1.tar.{gz,bz2}\t\t(preformatted docs)\n  RPMS/$arch/git-*-1.5.5.1-1.$arch.rpm\t(RPM)\n\nFortunately there weren't many brown paper bag breakages we needed to fix\nimmediately after releasing 1.5.5, but there do exist some usability and\ndocumentation fixes accumulated on the maintenance branch.  This release\ndelibers them.\n\n----------------------------------------------------------------\n\nChanges since v1.5.5 are as follows:\n\nAlberto Bertogli (1):\n      builtin-apply: Show a more descriptive error on failure when opening a patch\n\nBjörn Steinbrink (1):\n      Fix section about backdating tags in the git-tag docs\n\nCarlos Rica (2):\n      Fix documentation syntax of optional arguments in short options.\n      core-tutorial.txt: Fix showing the current behaviour.\n\nChristian Couder (4):\n      bisect: fix bad rev checking in \"git bisect good\"\n      bisect: report bad rev better\n      bisect: squelch \"fatal: ref HEAD not a symref\" misleading message\n      git-bisect: make \"start\", \"good\" and \"skip\" succeed or fail atomically\n\nClifford Caoile (1):\n      Docs gitk: Explicitly mention the files that gitk uses (~/.gitk)\n\nDaniel Barkalow (1):\n      Fix config key miscount in url.*.insteadOf\n\nDirk Suesserott (1):\n      Documentation/git-request-pull: Fixed a typo (\"send\" -> \"end\")\n\nJakub Narebski (1):\n      gitweb: Fix 'history' view for deleted files with history\n\nJeff King (1):\n      git-fetch: fix status output when not storing tracking ref\n\nJohannes Sixt (1):\n      Document option --only of git commit\n\nJon Loeliger (1):\n      Clarify and fix English in \"git-rm\" documentation\n\nJonas Fonseca (1):\n      git-remote: reject adding remotes with invalid names\n\nJunio C Hamano (7):\n      Document -w option to shortlog\n      Documentation/git-submodule: typofix\n      t7401: squelch garbage output\n      rebase: do not munge commit log message\n      git-am: minor cleanup\n      am: POSIX portability fix\n      GIT 1.5.5.1\n\nLinus Torvalds (2):\n      Ignore leading empty lines while summarizing merges\n      git-am: cope better with an empty Subject: line\n\nMark Levedahl (1):\n      git-submodule - possibly use branch name to describe a module\n\nMatthieu Moy (1):\n      Document that WebDAV doesn't need git on the server, and works over SSL\n\nMichele Ballabio (1):\n      revision.c: make --date-order overriddable\n\nPedro Melo (1):\n      Force the medium pretty format on calls to git log\n\nPing Yin (1):\n      git-submodule: Avoid 'fatal: cannot describe' message\n\nRené Scharfe (1):\n      git-archive: ignore prefix when checking file attribute\n\nScott Collins (1):\n      Clarify documentation of git-cvsserver, particularly in relation to git-shell\n\nShawn Bohrer (2):\n      git clean: Don't automatically remove directories when run within subdirectory\n      git clean: Add test to verify directories aren't removed with a prefix\n"},{"id":"74889","messageId":"20080421235610.GB2631@dpotapov.dyndns.org","threadId":"13203","inReplyTo":"7vej8yako4.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.5.1","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-04-21T23:56:10Z","receivedAt":"2008-04-21T23:56:10Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"Hi Junio,\n\nIt looks like my patch to documentation has been lost. I sent\nit about a week ago, and there has been no feedback to it, so\nI believe it is okay.\n\nThe --prune option for 'git gc' was one of those options that you\nneed to use from time to time, but it was perceived by many users\nas dangerous and many users were completely unaware of it, thus\noften it was not used as intended.\n\nJohannes' patch removed this option, which IMHO was a significant user\ninterface improvement.  Unfortunately, there are still a few places in\nthe documentation where this option is mentioned.  One of them is\n\"Everyday GIT\", which is intended for beginners. I believe it is very\nconfusing for anyone who starts to use GIT to see an undocumented option\namong recommended practice.\n\nSo, please, consider this patch for inclusion or provide any feedback\nas to what kind of improvements may be needed for its inclusion.\n\nThanks,\nDmitry\n\n-- >8 --\nFrom: Dmitry Potapov <dpotapov@gmail.com>\nDate: Mon, 14 Apr 2008 15:52:00 +0400\nSubject: [PATCH] Documentation: git-gc --prune is deprecated\n\n25ee9731c137d0a24b0f4879eb0b0cce9b77d5b0 made the '--prune' option\ndeprecated and removed its description from the git-gc man page. This\npatch removes all references to this option from the rest of the Git\ndocumentation.\n---\n Documentation/everyday.txt    |    6 ++----\n Documentation/git-clone.txt   |   10 ++++++----\n Documentation/user-manual.txt |   17 +----------------\n 3 files changed, 9 insertions(+), 24 deletions(-)\n\ndiff --git a/Documentation/everyday.txt b/Documentation/everyday.txt\nindex fdbd15a..e598cdd 100644\n--- a/Documentation/everyday.txt\n+++ b/Documentation/everyday.txt\n@@ -48,14 +48,12 @@ $ git gc <3>\n repository health reasonably well.\n <2> check how many loose objects there are and how much\n disk space is wasted by not repacking.\n-<3> repacks the local repository and performs other housekeeping tasks. Running\n-without `--prune` is a safe operation even while other ones are in progress.\n+<3> repacks the local repository and performs other housekeeping tasks.\n \n Repack a small project into single pack.::\n +\n ------------\n $ git gc <1>\n-$ git gc --prune\n ------------\n +\n <1> pack all the objects reachable from the refs into one pack,\n@@ -182,7 +180,7 @@ $ git pull <3>\n $ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>\n $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>\n $ git reset --hard ORIG_HEAD <6>\n-$ git gc --prune <7>\n+$ git gc <7>\n $ git fetch --tags <8>\n ------------\n +\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex 9758243..c1bf814 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -65,10 +65,12 @@ OPTIONS\n +\n *NOTE*: this is a possibly dangerous operation; do *not* use\n it unless you understand what it does. If you clone your\n-repository using this option, then delete branches in the\n-source repository and then run linkgit:git-gc[1] using the\n-'--prune' option in the source repository, it may remove\n-objects which are referenced by the cloned repository.\n+repository using this option and then delete a branch or use\n+any other git command that makes any previous existing commit\n+unreachable, then after some time linkgit:git-gc[1] may remove\n+unreachable objects, and this will break the cloned repository.\n+Because some git commands may run git-gc, it may happen at any\n+time after gc.pruneExpire time since commits became unreachable.\n \n \n \ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex 565aeb9..86b91a5 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -1548,22 +1548,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f\n \n Dangling objects are not a problem.  At worst they may take up a little\n extra disk space.  They can sometimes provide a last-resort method for\n-recovering lost work--see <<dangling-objects>> for details.  However, if\n-you wish, you can remove them with linkgit:git-prune[1] or the `--prune`\n-option to linkgit:git-gc[1]:\n-\n--------------------------------------------------\n-$ git gc --prune\n--------------------------------------------------\n-\n-This may be time-consuming.  Unlike most other git operations (including\n-git-gc when run without any options), it is not safe to prune while\n-other git operations are in progress in the same repository.\n-\n-If linkgit:git-fsck[1] complains about sha1 mismatches or missing\n-objects, you may have a much more serious problem; your best option is\n-probably restoring from backups.  See\n-<<recovering-from-repository-corruption>> for a detailed discussion.\n+recovering lost work--see <<dangling-objects>> for details.\n \n [[recovering-lost-changes]]\n Recovering lost changes\n-- \n1.5.5\n\n--\n"},{"id":"74894","messageId":"480D2FEE.3010904@nrlssc.navy.mil","threadId":"13203","inReplyTo":"20080421235610.GB2631@dpotapov.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.5.1","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-04-22T00:23:10Z","receivedAt":"2008-04-22T00:23:10Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Dmitry Potapov wrote:\n\n> Johannes' patch removed this option, which IMHO was a significant user\n> interface improvement.\n\nUnless I missed something, this option has not been removed. The original\npurpose for its existence (which was to cause git-gc to call git-prune)\nhas been removed. The call to git-prune within git-gc will remove _loose_\nunreferenced objects, but _packed_ unreferenced objects are removed by\nrepack. The --prune option to git-gc is still used to adjust the call to\ngit-repack so that packed unreferenced objects are discarded.\n\n> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n> index 9758243..c1bf814 100644\n> --- a/Documentation/git-clone.txt\n> +++ b/Documentation/git-clone.txt\n> @@ -65,10 +65,12 @@ OPTIONS\n>  +\n>  *NOTE*: this is a possibly dangerous operation; do *not* use\n>  it unless you understand what it does. If you clone your\n> -repository using this option, then delete branches in the\n> -source repository and then run linkgit:git-gc[1] using the\n> -'--prune' option in the source repository, it may remove\n> -objects which are referenced by the cloned repository.\n> +repository using this option and then delete a branch or use\n> +any other git command that makes any previous existing commit\n> +unreachable, then after some time linkgit:git-gc[1] may remove\n> +unreachable objects, and this will break the cloned repository.\n> +Because some git commands may run git-gc, it may happen at any\n> +time after gc.pruneExpire time since commits became unreachable.\n\nI agree that something should be said here about shared repositories,\nbut I think this wording is a little complicated (disclosure: I also\nsubmitted some text for this a few weeks ago :). Of course something\nis better than nothing.\n\nHere's the blurb I submitted if you're interested:\n+repository using this option and then delete branches in the\n+source repository, some objects may become unreferenced (or dangling).\n+These objects may be removed by normal git operations (such as git-commit[1])\n+which automatically call git-gc[1]. If these objects are removed and\n+were referenced by the cloned repository, then the cloned repository\n+will become corrupt.\n\n-brandon\n"},{"id":"74895","messageId":"20080422005556.GC2631@dpotapov.dyndns.org","threadId":"13203","inReplyTo":"480D2FEE.3010904@nrlssc.navy.mil","subject":"Re: [ANNOUNCE] GIT 1.5.5.1","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-04-22T00:55:56Z","receivedAt":"2008-04-22T00:55:56Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Apr 21, 2008 at 07:23:10PM -0500, Brandon Casey wrote:\n> Dmitry Potapov wrote:\n> \n> > Johannes' patch removed this option, which IMHO was a significant user\n> > interface improvement.\n> \n> Unless I missed something, this option has not been removed. The original\n> purpose for its existence (which was to cause git-gc to call git-prune)\n> has been removed. The call to git-prune within git-gc will remove _loose_\n> unreferenced objects, but _packed_ unreferenced objects are removed by\n> repack. The --prune option to git-gc is still used to adjust the call to\n> git-repack so that packed unreferenced objects are discarded.\n\nI thought that it had no effect any more, because it had been removed\nfrom the git-gc man page. Now I have looked at the code now, and it seems\nthe difference between running git gc with and without the prune option\nis that with this option the git repack is called with '-a' option while\nwithout it with '-A'. Unfortunately, the '-A' option in the git-repack\nis also undocumented, but based on the reading git-repack.sh, you are\nright. So, now I wonder wether removing the --prune option from the man\npage was the right thing to do.\n\n> \n> > diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n> > index 9758243..c1bf814 100644\n> > --- a/Documentation/git-clone.txt\n> > +++ b/Documentation/git-clone.txt\n> > @@ -65,10 +65,12 @@ OPTIONS\n> >  +\n> >  *NOTE*: this is a possibly dangerous operation; do *not* use\n> >  it unless you understand what it does. If you clone your\n> > -repository using this option, then delete branches in the\n> > -source repository and then run linkgit:git-gc[1] using the\n> > -'--prune' option in the source repository, it may remove\n> > -objects which are referenced by the cloned repository.\n> > +repository using this option and then delete a branch or use\n> > +any other git command that makes any previous existing commit\n> > +unreachable, then after some time linkgit:git-gc[1] may remove\n> > +unreachable objects, and this will break the cloned repository.\n> > +Because some git commands may run git-gc, it may happen at any\n> > +time after gc.pruneExpire time since commits became unreachable.\n> \n> I agree that something should be said here about shared repositories,\n> but I think this wording is a little complicated (disclosure: I also\n> submitted some text for this a few weeks ago :). Of course something\n> is better than nothing.\n> \n> Here's the blurb I submitted if you're interested:\n> +repository using this option and then delete branches in the\n> +source repository, some objects may become unreferenced (or dangling).\n> +These objects may be removed by normal git operations (such as git-commit[1])\n> +which automatically call git-gc[1]. If these objects are removed and\n> +were referenced by the cloned repository, then the cloned repository\n> +will become corrupt.\n\nI like your wording better though I still prefer to mention that\ndeleting branches is just one of many possible commands that may\ncreate unreferenced commits, i.e. something like that:\n\n ... repository using this option and then delete branches (or use any\n other git command that makes any existing commit unreferenced) ...\n\n\nDmitry\n"},{"id":"74918","messageId":"480D8DAB.6070409@viscovery.net","threadId":"13203","inReplyTo":"7vej8yako4.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.5.1","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-04-22T07:03:07Z","receivedAt":"2008-04-22T07:03:07Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> The latest maintenance release GIT 1.5.5.1 is available at the\n> usual places:\n\nThanks a lot!\n\nNote that the tag v1.5.5.1 is still missing from git://repo.or.cz/alt-git\n(but it is present in other git.git sources).\n\n-- Hannes\n"},{"id":"74994","messageId":"480E2268.6050907@nrlssc.navy.mil","threadId":"13203","inReplyTo":"20080422005556.GC2631@dpotapov.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.5.1","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-04-22T17:37:44Z","receivedAt":"2008-04-22T17:37:44Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Dmitry Potapov wrote:\n> On Mon, Apr 21, 2008 at 07:23:10PM -0500, Brandon Casey wrote:\n>> Dmitry Potapov wrote:\n>>\n>>> Johannes' patch removed this option, which IMHO was a significant user\n>>> interface improvement.\n>> Unless I missed something, this option has not been removed. The original\n>> purpose for its existence (which was to cause git-gc to call git-prune)\n>> has been removed. The call to git-prune within git-gc will remove _loose_\n>> unreferenced objects, but _packed_ unreferenced objects are removed by\n>> repack. The --prune option to git-gc is still used to adjust the call to\n>> git-repack so that packed unreferenced objects are discarded.\n> \n> I thought that it had no effect any more, because it had been removed\n> from the git-gc man page. Now I have looked at the code now, and it seems\n> the difference between running git gc with and without the prune option\n> is that with this option the git repack is called with '-a' option while\n> without it with '-A'. Unfortunately, the '-A' option in the git-repack\n> is also undocumented, but based on the reading git-repack.sh, you are\n> right. So, now I wonder wether removing the --prune option from the man\n> page was the right thing to do.\n> \n>>> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n>>> index 9758243..c1bf814 100644\n>>> --- a/Documentation/git-clone.txt\n>>> +++ b/Documentation/git-clone.txt\n>>> @@ -65,10 +65,12 @@ OPTIONS\n>>>  +\n>>>  *NOTE*: this is a possibly dangerous operation; do *not* use\n>>>  it unless you understand what it does. If you clone your\n>>> -repository using this option, then delete branches in the\n>>> -source repository and then run linkgit:git-gc[1] using the\n>>> -'--prune' option in the source repository, it may remove\n>>> -objects which are referenced by the cloned repository.\n>>> +repository using this option and then delete a branch or use\n>>> +any other git command that makes any previous existing commit\n>>> +unreachable, then after some time linkgit:git-gc[1] may remove\n>>> +unreachable objects, and this will break the cloned repository.\n>>> +Because some git commands may run git-gc, it may happen at any\n>>> +time after gc.pruneExpire time since commits became unreachable.\n>> I agree that something should be said here about shared repositories,\n>> but I think this wording is a little complicated (disclosure: I also\n>> submitted some text for this a few weeks ago :). Of course something\n>> is better than nothing.\n>>\n>> Here's the blurb I submitted if you're interested:\n>> +repository using this option and then delete branches in the\n>> +source repository, some objects may become unreferenced (or dangling).\n>> +These objects may be removed by normal git operations (such as git-commit[1])\n>> +which automatically call git-gc[1]. If these objects are removed and\n>> +were referenced by the cloned repository, then the cloned repository\n>> +will become corrupt.\n> \n> I like your wording better though I still prefer to mention that\n> deleting branches is just one of many possible commands that may\n> create unreferenced commits, i.e. something like that:\n> \n>  ... repository using this option and then delete branches (or use any\n>  other git command that makes any existing commit unreferenced) ...\n\nThat's fine, but one of us needs to resubmit. Care to do the honors? :)\n\n-brandon\n"},{"id":"75009","messageId":"20080422202232.GC26950@dpotapov.dyndns.org","threadId":"13203","inReplyTo":"480E2268.6050907@nrlssc.navy.mil","subject":"Re: [ANNOUNCE] GIT 1.5.5.1","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-04-22T20:22:32Z","receivedAt":"2008-04-22T20:22:32Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Apr 22, 2008 at 12:37:44PM -0500, Brandon Casey wrote:\n> Dmitry Potapov wrote:\n> > \n> >  ... repository using this option and then delete branches (or use any\n> >  other git command that makes any existing commit unreferenced) ...\n> \n> That's fine, but one of us needs to resubmit. Care to do the honors? :)\n\nHere it goes:\n\n-- >8 --\nFrom 21a905febd728f8839a1c96d0dfa83d8f252b132 Mon Sep 17 00:00:00 2001\nFrom: Brandon Casey <casey@nrlssc.navy.mil>\nDate: Thu, 3 Apr 2008 13:26:13 -0500\nSubject: [PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc\n\nSince git-gc now always calls prune, even with --auto, unreferenced objects\nmay be removed by more operations than just git-gc. This is important for\nclones created using --shared or --reference.\n\nSigned-off-by: Brandon Casey <casey@nrlssc.navy.mil>\nSigned-off-by: Dmitry Potapov <dpotapov@gmail.com>\n---\n Documentation/git-clone.txt |   13 +++++++++----\n 1 files changed, 9 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex 9758243..9b56442 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -65,10 +65,13 @@ OPTIONS\n +\n *NOTE*: this is a possibly dangerous operation; do *not* use\n it unless you understand what it does. If you clone your\n-repository using this option, then delete branches in the\n-source repository and then run linkgit:git-gc[1] using the\n-'--prune' option in the source repository, it may remove\n-objects which are referenced by the cloned repository.\n+repository using this option and then delete branches (or use any\n+other git command that makes any existing commit unreferenced) in the\n+source repository, some objects may become unreferenced (or dangling).\n+These objects may be removed by normal git operations (such as git-commit[1])\n+which automatically call git-gc[1]. If these objects are removed and\n+were referenced by the cloned repository, then the cloned repository\n+will become corrupt.\n \n \n \n@@ -79,6 +82,8 @@ objects which are referenced by the cloned repository.\n \tan already existing repository as an alternate will\n \trequire fewer objects to be copied from the repository\n \tbeing cloned, reducing network and local storage costs.\n++\n+*NOTE*: see NOTE to --shared option.\n \n --quiet::\n -q::\n-- \n1.5.5\n\n--\n"}]}