{"thread":{"id":"6461","subject":"[Announce] GIT v1.5.0-rc2","startedAt":"2007-01-21T08:56:25Z","lastAt":"2007-03-27T00:07:55Z","messageCount":70,"participants":["Junio C Hamano","Jakub Narebski","Johannes Schindelin","Bill Lear","Willy Tarreau","Michael","H. Peter Anvin","Horst H. von Brand","Nicolas Pitre","Carl Worth","Linus Torvalds","David Kågedal","Uwe Kleine-König","Peter Baumann","Mark Nudelman","Shawn O. Pearce","Johannes Sixt","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"32194","messageId":"7v64b04v2e.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":null,"subject":"[Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-21T08:56:25Z","receivedAt":"2007-01-21T08:56:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This hopefully is pretty much it for 1.5.0 modulo potential bugs\nespecially in newer topics. Aside from many bugfixes, changes\nsince -rc1 are:\n\n - 'git log' is now reflog aware, and 'git show-branch' which\n knew about reflog already has become much more useful with\n reflogs.\n\n - the porcelain/ancillary/plumbing categorization in the git\n main documentation has been reviewed and updated.\n\n - merge and pull operations are much less chatty.\n\n - operation in a bare repositories is more pleasant.\n\n - the default file extension for format-patch output is .patch\n now.\n\n----------------------------------------------------------------\n\nBob Proulx (1):\n git-revert: Fix die before git-sh-setup defines it.\n\nChris Wedgwood (1):\n cache.h; fix a couple of prototypes\n\nDavid Kågedal (2):\n Shell syntax fix in git-reset\n Document --ignore-if-in-upstream in git-format-patch\n\nDoug Maxey (1):\n gitk: add current directory to main window title\n\nEric Wong (2):\n git-svn: fix tests to work with older svn\n git-svn: print and flush authentication prompts to STDERR\n\nJason Riedy (4):\n Start all test scripts with /bin/sh.\n Set _ALL_SOURCE for AIX, but avoid its struct list.\n Replace \"echo -n\" with printf in shell scripts.\n Solaris 5.8 returns ENOTDIR for inappropriate renames.\n\nJeff King (1):\n git-pull: disallow implicit merging to detached HEAD\n\nJohannes Schindelin (9):\n Fix spurious compile error\n config_set_multivar(): disallow newlines in keys\n show_date(): fix relative dates\n apply --cached: fix crash in subdirectory\n Do not verify filenames in a bare repository\n Teach the revision walker to walk by reflogs with --walk-reflogs\n --walk-reflogs: disallow uninteresting commits\n --walk-reflogs: actually find the right commit by date.\n --walk-reflogs: do not crash with cyclic reflog ancestry\n\nJunio C Hamano (69):\n reflog-expire: brown paper bag fix.\n merge-recursive: do not report the resulting tree object name\n Explain \"Not a git repository: '.git'\".\n glossary typofix\n Make git-prune-packed a bit more chatty.\n Define cd_to_toplevel shell function in git-sh-setup\n Use cd_to_toplevel in scripts that implement it by hand.\n Allow whole-tree operations to be started from a subdirectory\n Use log output encoding in --pretty=email headers.\n t3901: test \"format-patch | am\" pipe with i18n\n git-commit documentation: -a adds and also removes\n Consistent message encoding while reusing log from an existing commit.\n More tests in t3901.\n git log documentation: teach - form.\n Add describe test.\n Documentation: merge-output is not too verbose now.\n Use merge-recursive in git-revert/git-cherry-pick\n git reflog expire: document --stale-fix option.\n Fix git-fetch while on detached HEAD not to give needlessly alarming\n errors\n git-push documentation: remaining bits\n git-rm documentation: remove broken behaviour from the example.\n tutorial: shorthand for remotes but show distributed nature of git\n git-commit documentation: remove comment on unfixed git-rm\n Use merge-recursive in git-checkout -m (branch switching)\n Document where configuration files are in config.txt\n git-commit: document log message formatting convention\n Documentation/SubmittingPatches: Gnus tips\n Documentation/git-tag: the command can be used to also verify a tag.\n Documentation/git-tools.txt: mention tig and refer to wiki\n Documentation/git-tar-tree.txt: default umask is now 002\n Documentation/git-status.txt: mention color configuration\n Documentation/git-whatchanged.txt: show - instead of --max-count.\n Documentation/git-sh-setup.txt: programmer's docs\n Documentation: detached HEAD\n Make a short-and-sweet \"git-add -i\" synonym for \"git-add --interactive\"\n Documentation: describe shallow repository\n Documentation/glossary.txt: unpacked objects are loose.\n Documentation/glossary.txt: describe remotes/ tracking and packed-refs\n Introduce 'git-format-patch --suffix=.patch'\n git-format-patch: do not crash with format.headers without value.\n Documentation/git-resolve: deprecated.\n Documentation: suggest corresponding Porcelain-level in plumbing docs.\n Documentation: m can be relative in \"git-blame -Ln,m\"\n Documentation/git-parse-remote.txt: we deal with config vars as well\n git-format-patch -3\n Add --summary to git-format-patch by default\n git-format-patch: make --binary on by default\n git-format-patch: the default suffix is now .patch, not .txt\n Use fixed-size integers for .idx file I/O\n Documentation: move command list in git.txt into separate files.\n Documentation: sync git.txt command list and manual page title\n Documentation: Generate command lists.\n for_each_reflog_ent: do not leak FILE *\n refs.c::read_ref_at(): fix bogus munmap() call.\n Documentation: generated cmds-*.txt does not depend on git.txt\n Documentation/git.txt: command re-classification\n dwim_ref(): Separate name-to-ref DWIM code out.\n Extend read_ref_at() to be usable from places other than sha1_name.\n show-branch --reflog: show the reflog message at the top.\n show-branch --reflog: tighten input validation.\n show-branch --reflog: fix show_date() call\n Stop ignoring Documentation/README\n git-tag -d: allow deleting multiple tags at once.\n branch -f: no reason to forbid updating the current branch in a\n bare repo.\n git-rebase: allow rebasing a detached HEAD.\n log --walk-reflog: documentation\n reflog-walk: build fixes\n Fix --walk-reflog with --pretty=oneline\n GIT v1.5.0-rc2\n\nLinus Torvalds (2):\n Clean up write_in_full() users\n Fix up totally buggered read_or_die()\n\nMatthias Lederhofer (2):\n prune-packed: add -q to usage\n prune: --grace=time\n\nMichael S. Tsirkin (1):\n fix documentation for git-commit --no-verify\n\nNicolas Pitre (4):\n use 'init' instead of 'init-db' for shipped docs and tools\n simplify the \"no changes added to commit\" message\n some doc updates\n sanitize content of README file\n\nPeter Baumann (1):\n Make gitk work when launched in a subdirectory\n\nQuy Tonthat (1):\n git-remote: no longer silent on unknown commands.\n\nRené Scharfe (1):\n Documentation: a few spelling fixes\n\nSanti Béjar (1):\n tutorial: Use only separate layout\n\nShawn O. Pearce (18):\n Improve merge performance by avoiding in-index merges.\n Hide output about SVN::Core not being found during tests.\n Remove read_or_die in favor of better error messages.\n Remove unnecessary call_depth parameter in merge-recursive.\n Allow the user to control the verbosity of merge-recursive.\n Enable output buffering in merge-recursive.\n Display a progress meter during merge-recursive.\n Convert output messages in merge-recursive to past tense.\n Always perfer annotated tags in git-describe.\n Hash tags by commit SHA1 in git-describe.\n Use binary searching on large buckets in git-describe.\n Improve git-describe performance by reducing revision listing.\n Correct priority of lightweight tags in git-describe.\n Remove hash in git-describe in favor of util slot.\n Use nice names in conflict markers during cherry-pick/revert.\n Document the master@{n} reflog query syntax.\n Refer users to git-rev-parse for revision specification syntax.\n Document pack .idx file format upgrade strategy.\n\nSimon 'corecode' Schubert (2):\n Use fixed-size integers for the on-disk pack structure.\n Use standard -t option for touch.\n\nUwe Kleine-König (4):\n document --exec for git-push\n Update documentation of fetch-pack, push and send-pack\n make --exec=... option to git-push configurable\n rename --exec to --receive-pack for push and send-pack\n"},{"id":"32195","messageId":"eovccc$usc$1@sea.gmane.org","threadId":"6461","inReplyTo":"7v64b04v2e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-21T09:40:05Z","receivedAt":"2007-01-21T09:40:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"By the way, was the pager configured to saner values, so \"git diff\"\non a repository with no changes does not output empty page?\n\nWhat about my Documentation/config.txt changes?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32197","messageId":"7vwt3g3b5b.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"eovccc$usc$1@sea.gmane.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-21T10:52:00Z","receivedAt":"2007-01-21T10:52:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> By the way, was the pager configured to saner values, so \"git diff\"\n> on a repository with no changes does not output empty page?\n\nThat's been set to the right way since commit 0abc0260 (October\n22, 2006, v1.4.3.2~6) as far as I know.\n\n> What about my Documentation/config.txt changes?\n\nI was not sure about that one, given a lot of commentary in your\nmessage, suggesting more research and revision is needed, like\nthese...\n\n>>> +All the other lines are recognized as setting variables, in the form\n>>> +'name = value'. If there is no equal sign on the line, the entire line\n>>> +is taken as 'name' and the variable is recognized as boolean \"true\".\n>>> +Variable names are case insensitive.\n>> \n>> They cannot contain anything else than alphanumeric characters, in \n>> particular no whitespace.\n>\n> It is mentioned above \"Syntax\" section, but perhaps it should be repeated.\n> I haven't took a look at code to check what values for section names and\n> for key/variable names are allowed.\n> ...\n>> One thing that left me puzzled after reading the description was\n>> what a user can do with \"subsection\". It is unclear from the\n>> description if [section \"sub.section\"], [section \"sub.sec=ti.on\"]\n>> or worse yet, [section \"sub\\nsection with an embbedded LF\"] are\n>> allowed. The rest seemed sane.\n>\n> I'm not sure what is allowed in section name, and in subsection name,\n> so for now I have left it as is. I can amend this commit, or add new\n> commit explaining this.\n"},{"id":"32199","messageId":"Pine.LNX.4.63.0701211207500.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"eovccc$usc$1@sea.gmane.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-21T11:08:25Z","receivedAt":"2007-01-21T11:08:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Jan 2007, Jakub Narebski wrote:\n\n> By the way, was the pager configured to saner values, so \"git diff\" on a \n> repository with no changes does not output empty page?\n\nAs Junio mentioned: it already does. Maybe you have set the environment \nvariable \"LESS\", and forgot to include \"-F\"?\n\nHth,\nDscho\n"},{"id":"32203","messageId":"7v3b6439uh.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"7v64b04v2e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-21T11:20:06Z","receivedAt":"2007-01-21T11:20:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"BTW, as the upcoming v1.5.0 release will introduce quite a bit of\nsurface changes (although at the really core it still is the old\ngit and old ways should continue to work), I am wondering if it\nwould help people to try out and find wrinkles before the real\nthing for me to cut a tarball and a set of RPM packages.\n\nComments?\n\nAlso, in the same spirit of giving the release an early\nexposure, here is the current draft of 1.5.0 release notes.\n\n-- >8 -- cut here -- >8 --\n\nGIT v1.5.0 Release Notes (draft)\n================================\n\nOld news\n--------\n\nThis section is for people who are upgrading from ancient\nversions of git. Although all of the changes in this section\nhappened before the current v1.4.4 release, they are summarized\nhere in the v1.5.0 release notes for people who skipped earlier\nversions.\n\nIn general, you should not have to worry about incompatibility,\nand there is no need to perform \"repository conversion\" if you\nare updating to v1.5.0. However, some of the changes are\none-way street upgrades; once you use them your repository\ncan no longer be used with ancient git.\n\n - There is a configuration variable core.legacyheaders that\n changes the format of loose objects so that they are more\n efficient to pack and to send out of the repository over git\n native protocol, since v1.4.2. However, loose objects\n written in the new format cannot be read by git older than\n that version; people fetching from your repository using\n older clients over dumb transports (e.g. http) using older\n versions of git will also be affected.\n\n - Since v1.4.3, configuration repack.usedeltabaseoffset allows\n packfile to be created in more space efficient format, which\n cannot be read by git older than that version.\n\nThe above two are not enabled by default and you explicitly have\nto ask for them, because these two features make repositories\nunreadable by older versions of git, and in v1.5.0 we still do\nnot enable them by default for the same reason. We will change\nthis default probably 1 year after 1.4.2's release, when it is\nreasonable to expect everybody to have new enough version of\ngit.\n\n - 'git pack-refs' appeared in v1.4.4; this command allows tags\n to be accessed much more efficiently than the traditional\n 'one-file-per-tag' format. Older git-native clients can\n still fetch from a repository that packed and pruned refs\n (the server side needs to run the up-to-date version of git),\n but older dumb transports cannot. Packing of refs is done by\n an explicit user action, either by use of \"git pack-refs\n --prune\" command or by use of \"git gc\" command.\n\n - 'git -p' to paginate anything -- many commands do pagination\n by default on a tty. Introduced between v1.4.1 and v1.4.2;\n this may surprise old timers.\n\n - 'git archive' superseded 'git tar-tree' in v1.4.3;\n\n - 'git cvsserver' was new invention in v1.3.0;\n\n - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were\n seriously enhanced during v1.4.0 timeperiod.\n\n - 'gitweb' became part of git.git during v1.4.0 timeperiod and\n seriously modified since then.\n\n - reflog is an v1.4.0 invention. This allows you to name a\n revision that a branch used to be at (e.g. \"git diff\n master@{yesterday} master\" allows you to see changes since\n yesterday's tip of the branch).\n\n\nUpdates in v1.5.0 since v1.4.4 series\n-------------------------------------\n\n* Index manipulation\n\n - git-add is to add contents to the index (aka \"staging area\"\n for the next commit), whether the file the contents happen to\n be is an existing one or a newly created one.\n\n - git-add without any argument does not add everything\n anymore. Use 'git-add .' instead. Also you can add\n otherwise ignored files with an -f option.\n\n - git-add tries to be more friendly to users by offering an\n interactive mode.\n\n - git-commit used to refuse to commit if was\n different between HEAD and the index (i.e. update-index was\n used on it earlier). This check was removed.\n\n - git-rm is much saner and safer. It is used to remove paths\n from both the index file and the working tree, and makes sure\n you are not losing any local modification before doing so.\n\n - git-reset ... can be used to revert index\n entries for selected paths.\n\n - git-update-index is much less visible.\n\n\n* Repository layout and objects transfer\n\n - The data for origin repository is stored in the configuration\n file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly\n created clones. The latter is still supported and there is\n no need to convert your existing repository if you are\n already comfortable with your workflow with the layout.\n\n - git-clone always uses what is known as \"separate remote\"\n layout for a newly created repository with a working tree;\n i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are\n used to track branches from the origin. \n\n - New branches that appear on the origin side after a clone is\n made are also tracked automatically. This is done with an\n wildcard refspec \"refs/heads/*:refs/remotes/origin/*\", which\n older git does not understand, so if you clone with 1.5.0,\n you would need to downgrade remote.*.fetch in the\n configuration file to specify each branch you are interested\n in individually if you plan to fetch into the repository with\n older versions of git (but why would you?).\n\n - git-branch and git-show-branch know remote tracking branches.\n\n - git-push can now be used to delete a remote branch or a tag.\n This requires the updated git on the remote side.\n\n - git-push more agressively keeps the transferred objects\n packed. Earlier we recommended to monitor amount of loose\n objects and repack regularly, but you should repack when you\n accumulated too many small packs this way as well. Updated\n git-count-objects helps you with this.\n\n - A new command, git-remote, can help you manage your remote\n tracking branch definitions.\n\n\n* Bare repositories\n\n - Certain commands change their behaviour in a bare repository\n (i.e. a repository without associated working tree). We use\n a fairly conservative heuristic (if $GIT_DIR is \".git\", or\n ends with \"/.git\", the repository is not bare) to decide if a\n repository is bare, but \"core.bare\" configuration variable\n can be used to override the heuristic when it misidentifies\n your repository.\n\n - git-fetch used to complain updating the current branch but\n this is now allowed for a bare repository. So is the use of\n 'git-branch -f' to update the current branch.\n\n - Porcelain-ish commands that require a working tree refuses to\n work in a bare repository.\n\n\n* Reflog\n\n - Reflog records the history of where the tip of each branch\n was at each moment. This facility is enabled by default for\n repositories with working trees, and can be accessed with the\n \"branch@{time}\" and \"branch@{Nth}\" notation.\n\n - \"git show-branch\" learned showing the reflog data with the\n new --reflog option. \"git log\" has --walk-reflogs option to\n view reflog entries in a more verbose manner.\n\n - git-branch knows how to rename branches and moves existing\n reflog data from the old branch to the new one.\n\n - The commits referred to by reflog entries are now protected\n against pruning. The new command \"git reflog expire\" can be\n used to truncate older reflog entries and entries that refer\n to commits that have been pruned away previously with older\n versions of git.\n\n Existing repositories that have been using reflog may get\n complaints from fsck-objects and may not be able to run\n git-repack, if you had run git-prune from older git; please\n run \"git reflog expire --stale-fix --all\" first to remove\n reflog entries that refer to commits that are no longer in\n the repository when that happens.\n\n\n* Crufts removal\n\n - We used to say \"old commits are retrievable using reflog and\n 'master@{yesterday}' syntax as long as you haven't run\n git-prune\". We no longer have to say the latter half of the\n above sentence, as git-prune does not remove things reachable\n from reflog entries.\n\n - 'git-prune' by default does not remove _everything_\n unreachable, as there is a one-day grace period built-in.\n\n - There is a toplevel garbage collector script, 'git-gc', that\n is an easy way to run 'git-repack -a -d', 'git-reflog gc',\n and 'git-prune'.\n\n\n* Detached HEAD\n\n - You can give non-branch to \"git checkout\" now. This will\n dissociate your HEAD from any of your branches. A typical\n use of this feature is to \"look around\". E.g.\n\n\t$ git checkout v2.6.16\n\t... compile, test, etc.\n\t$ git checkout v2.6.17\n\t... compile, test, etc.\n\n - After detaching your HEAD, you can go back to an existing\n branch with usual \"git checkout $branch\". Also you can\n start a new branch using \"git checkout -b $newbranch\".\n\n - You can even pull from other repositories, make merges and\n commits while your HEAD is detached. Also you can use \"git\n reset\" to jump to arbitrary commit.\n\n Going back to undetached state by \"git checkout $branch\" can\n lose the current stat you arrived in these ways, and \"git\n checkout\" refuses when the detached HEAD is not pointed by\n any existing ref (an existing branch, a remote tracking\n branch or a tag). This safety can be overriden with \"git\n checkout -f $branch\".\n\n\n* Packed refs\n\n - Repositories with hundreds of tags have been paying large\n overhead, both in storage and in runtime, due to the\n traditional one-ref-per-file format. A new command,\n git-pack-refs, can be used to \"pack\" them in more efficient\n representation.\n\n - Clones and fetches over dumb transports are now aware of\n packed refs and can download from repositories that use\n them.\n\n\n* Configuration\n\n - configuration related to color setting are consolidated under\n color.* namespace (older diff.color.*, status.color.* are\n still supported).\n\n\n* Less external dependency\n\n - We no longer require the \"merge\" program from the RCS suite.\n All 3-way file-level merges are now done internally.\n\n - The original implementation of git-merge-recursive which was\n in Python has been removed; we have C implementation of it\n now.\n\n - git-shortlog is no longer a Perl script. It no longer\n requires output piped from git-log; it can accept revision\n parameters directly on the command line.\n\n\n* I18n\n\n - We have always encouraged the commit message to be encoded in\n UTF-8, but the users are allowed to use legacy encoding as\n appropriate for their projects. This will continue to be the\n case. However, a non UTF-8 commit encoding _must_ be\n explicitly set with i18n.commitencoding in the repository\n where a commit is made; otherwise git-commit-tree will\n complain if the log message does not look like a valid UTF-8\n string.\n\n - The value of i18n.commitencoding in the originating\n repository is recorded in the commit object on the \"encoding\"\n header, if it is not UTF-8. git-log and friends notice this,\n and reencodes the message to the log output encoding when\n displaying, if they are different. The log output encoding\n is determined by \"git log --encoding=\",\n i18n.logoutputencoding configuration, or i18n.commitencoding\n configuration, in the decreasing order of preference, and\n defaults to UTF-8. \n\n - Tools for e-mailed patch application now default to -u\n behaviour; i.e. it always re-codes from the e-mailed encoding\n to the encoding specified with i18n.commitencoding. This\n unfortunately forces projects that have happily been using a\n legacy encoding without setting i18n.commitencoding to set\n the configuration, but taken with other improvement, please\n excuse us for this very minor one-time inconvenience.\n\n\n* e-mailed patches\n\n - See the above I18n section.\n\n - git-format-patch now enables --binary without being asked.\n git-am does _not_ default to it, as sending binary patch via\n e-mail is unusual and is harder to review than textual\n patches and it is prudent to require the person who is\n applying the patch to explicitly ask for it.\n\n - The default suffix for git-format-patch output is now \".patch\",\n not \".txt\". This can be changed with --suffix=.txt option,\n or \"format.suffix = .txt\" in the configuration.\n\n\n* Foreign SCM interfaces\n\n - git-svn now requires the Perl SVN:: libraries, the\n command-line backend was too slow and limited.\n\n - the 'commit' subcommand of git-svn has been renamed to\n 'set-tree', and 'dcommit' is the recommended replacement for\n day-to-day work.\n\n\n* User support\n\n - Quite a lot of documentation updates.\n\n - Bash completion scripts have been updated heavily.\n\n - Better error messages for often used Porcelainish commands.\n\n\n* Sliding mmap\n\n - We used to assume that we can mmap the whole packfile while\n in use, but with a large project this consumes huge virtual\n memory space and truly huge ones would not fit in the\n userland address space on 32-bit platforms. We now mmap huge\n packfile in pieces to avoid this problem.\n\n\n* Shallow clones\n\n - There is a partial support for 'shallow' repositories that\n keeps only recent history. A 'shallow clone' is created by\n specifying how deep that truncated history should be.\n\n Currently a shallow repository has number of limitations:\n\n - Cloning and fetching _from_ a shallow clone are not\n supported (nor tested -- so they might work by accident but\n they are not expected to).\n\n - Pushing from nor into a shallow clone are not expected to\n work.\n\n - Merging inside a shallow repository would work as long as a\n merge base is found in the recent history, but otherwise it\n will be like merging unrelated histories and may result in\n huge conflicts.\n\n but this would be more than adequate for people who want to\n look at near the tip of a big project with a deep history and\n send patches in e-mail format.\n"},{"id":"32204","messageId":"17843.28128.851749.558017@lisa.zopyra.com","threadId":"6461","inReplyTo":"7v3b6439uh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-21T13:42:56Z","receivedAt":"2007-01-21T13:42:56Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Sunday, January 21, 2007 at 03:20:06 (-0800) Junio C Hamano writes:\n>BTW, as the upcoming v1.5.0 release will introduce quite a bit of\n>surface changes (although at the really core it still is the old\n>git and old ways should continue to work), I am wondering if it\n>would help people to try out and find wrinkles before the real\n>thing for me to cut a tarball and a set of RPM packages.\n>\n>Comments?\n\nI asked this in the context of the \"fatal: protocol error\"\nthread, but can I install the 1.5.0rcX on my machine and use\nit with our company repository, running 1.4.4.1?\n\nIn any case, I think trying to find wrinkles before the real\nthing is certainly healthy.\n\n\nBill\n"},{"id":"32205","messageId":"20070121134308.GA24090@1wt.eu","threadId":"6461","inReplyTo":"7v3b6439uh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Willy Tarreau","fromEmail":"w@1wt.eu","sentAt":"2007-01-21T13:43:08Z","receivedAt":"2007-01-21T13:43:08Z","isPatch":false,"sender":{"key":"w@1wt.eu","avatar":"https://avatars.githubusercontent.com/u/8141789?v=4"},"body":"Hi Junio !\n\nOn Sun, Jan 21, 2007 at 03:20:06AM -0800, Junio C Hamano wrote:\n> BTW, as the upcoming v1.5.0 release will introduce quite a bit of\n> surface changes (although at the really core it still is the old\n> git and old ways should continue to work), I am wondering if it\n> would help people to try out and find wrinkles before the real\n> thing for me to cut a tarball and a set of RPM packages.\n> \n> Comments?\n\nAnything you can do to make tester's life easier will always slightly\nincrease the number of testers. Hint: how often do you try random\nsoftware that requires that you first install CVS, SVN or arch just to\nget it, compared to how often you try random software provided as tar.gz ?\nPre-release tar.gz and rpms coupled with a freshmeat announcement should\nget you a bunch of testers and newcomers. This will give the new doc a\nreal trial, and will help discover traps in which beginners often fall.\n\n> Also, in the same spirit of giving the release an early\n> exposure, here is the current draft of 1.5.0 release notes.\n\n(...)\n\n> - There is a configuration variable core.legacyheaders that\n> changes the format of loose objects so that they are more\n> efficient to pack and to send out of the repository over git\n> native protocol, since v1.4.2. However, loose objects\n> written in the new format cannot be read by git older than\n> that version; people fetching from your repository using\n> older clients over dumb transports (e.g. http) using older\n> versions of git will also be affected.\n> \n> - Since v1.4.3, configuration repack.usedeltabaseoffset allows\n> packfile to be created in more space efficient format, which\n> cannot be read by git older than that version.\n\nI know it's a bit late to ask, but if new on-disk format changes, isn't\nit time to bump the version to 2.0 ? It would be easier for many people to\nremember that GIT 1.X uses format version 1 and that GIT 2.X uses format\nversion 2 with backwards compatibility with 1.X. I also think that 1.5\nis much more different from 1.0 than a mid-term 2.0 would be from current\n1.5.\n\nThat said, kudos for the nice changelog !\n\nRegards,\nWilly\n"},{"id":"32206","messageId":"17843.28673.205993.946369@lisa.zopyra.com","threadId":"6461","inReplyTo":"17843.28128.851749.558017@lisa.zopyra.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-21T13:52:01Z","receivedAt":"2007-01-21T13:52:01Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?\n\n\nBill\n\nOn Sunday, January 21, 2007 at 07:42:56 (-0600) Bill Lear writes:\n>On Sunday, January 21, 2007 at 03:20:06 (-0800) Junio C Hamano writes:\n>>BTW, as the upcoming v1.5.0 release will introduce quite a bit of\n>>surface changes (although at the really core it still is the old\n>>git and old ways should continue to work), I am wondering if it\n>>would help people to try out and find wrinkles before the real\n>>thing for me to cut a tarball and a set of RPM packages.\n>>\n>>Comments?\n>\n>I asked this in the context of the \"fatal: protocol error\"\n>thread, but can I install the 1.5.0rcX on my machine and use\n>it with our company repository, running 1.4.4.1?\n>\n>In any case, I think trying to find wrinkles before the real\n>thing is certainly healthy.\n>\n>\n>Bill\n>-\n>To unsubscribe from this list: send the line \"unsubscribe git\" in\n>the body of a message to majordomo@vger.kernel.org\n>More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"32210","messageId":"200701211602.59130.barra_cuda@katamail.com","threadId":"6461","inReplyTo":"17843.28673.205993.946369@lisa.zopyra.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Michael","fromEmail":"barra_cuda@katamail.com","sentAt":"2007-01-21T15:02:58Z","receivedAt":"2007-01-21T15:02:58Z","isPatch":false,"sender":{"key":"barra_cuda@katamail.com","avatar":"https://avatars.githubusercontent.com/u/16371673?v=4"},"body":"Bill Lear:\n> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?\n\ngit clone git://git.kernel.org/pub/scm/git/git.git\n\nThen checkout the commit tagged 'v1.5.0-rc2'.\n\nThere are no such tarballs (yet) on:\n\nhttp://www.kernel.org/pub/software/scm/git/\n"},{"id":"32211","messageId":"eovvg3$i6m$1@sea.gmane.org","threadId":"6461","inReplyTo":"20070121134308.GA24090@1wt.eu","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-21T15:06:22Z","receivedAt":"2007-01-21T15:06:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Willy Tarreau wrote:\n> On Sun, Jan 21, 2007 at 03:20:06AM -0800, Junio C Hamano wrote:\n\n>> BTW, as the upcoming v1.5.0 release will introduce quite a bit of\n>> surface changes (although at the really core it still is the old\n>> git and old ways should continue to work), I am wondering if it\n>> would help people to try out and find wrinkles before the real\n>> thing for me to cut a tarball and a set of RPM packages.\n>> \n>> Comments?\n> \n> Anything you can do to make tester's life easier will always slightly\n> increase the number of testers. Hint: how often do you try random\n> software that requires that you first install CVS, SVN or arch just to\n> get it, compared to how often you try random software provided as tar.gz ?\n> Pre-release tar.gz and rpms coupled with a freshmeat announcement should\n> get you a bunch of testers and newcomers. This will give the new doc a\n> real trial, and will help discover traps in which beginners often fall.\n\nRPMS are nicely divided into (sub)packages, so you need CVS indtalled\nonly if you install git-cvs package, for example to interact with CVS.\ngit-core has minimal dependencies.\n\nTo compile git you truly don't need other software installed (1.5.0\nfor example does not require RCS anymore for RCS merge).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32218","messageId":"7v7ivg1a25.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"20070121134308.GA24090@1wt.eu","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-21T18:58:26Z","receivedAt":"2007-01-21T18:58:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Willy Tarreau writes:\n\n> Anything you can do to make tester's life easier will always slightly\n> increase the number of testers.\n> ...\n> Pre-release tar.gz and rpms coupled with a freshmeat announcement should\n> get you a bunch of testers and newcomers. This will give the new doc a\n> real trial, and will help discover traps in which beginners often fall.\n\nOne worry I had about releasing git-1.5.0-rc2-1.rpm and friends\njust like the \"official\" ones was that people might have scripts\nto automate downloading & updating of packages, and they may not\nlike to get \"beta\" installed for them.\n\nI wonder if kernel.org machines are also affected...\n\n>> Also, in the same spirit of giving the release an early\n>> exposure, here is the current draft of 1.5.0 release notes.\n>\n> (...)\n>\n>> - There is a configuration variable core.legacyheaders that\n>> changes the format of loose objects so that they are more\n>> efficient to pack and to send out of the repository over git\n>> native protocol, since v1.4.2. However, loose objects\n>> written in the new format cannot be read by git older than\n>> that version; people fetching from your repository using\n>> older clients over dumb transports (e.g. http) using older\n>> versions of git will also be affected.\n>> \n>> - Since v1.4.3, configuration repack.usedeltabaseoffset allows\n>> packfile to be created in more space efficient format, which\n>> cannot be read by git older than that version.\n>\n> I know it's a bit late to ask, but if new on-disk format changes, isn't\n> it time to bump the version to 2.0? It would be easier for many people to\n> remember that GIT 1.X uses format version 1 and that GIT 2.X uses format\n> version 2 with backwards compatibility with 1.X. I also think that 1.5\n> is much more different from 1.0 than a mid-term 2.0 would be from current\n> 1.5.\n\nI think we could have gone either way (as you said, it is\nprobably a bit too late to discuss this), but it should probably\nbe Ok to stay at 1.X as long as these one-way-street format\nupdates are turned off by default.\n\nAnd the above happened way before this round and people have\nhopefully been happily using. For example, v1.4.2 was done\nearly August 2006.\n"},{"id":"32223","messageId":"200701211946.l0LJkTMV022057@laptop13.inf.utfsm.cl","threadId":"6461","inReplyTo":"7v3b6439uh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2007-01-21T19:46:29Z","receivedAt":"2007-01-21T19:46:29Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> BTW, as the upcoming v1.5.0 release will introduce quite a bit of\n> surface changes (although at the really core it still is the old\n> git and old ways should continue to work), I am wondering if it\n> would help people to try out and find wrinkles before the real\n> thing for me to cut a tarball and a set of RPM packages.\n> \n> Comments?\n> \n> Also, in the same spirit of giving the release an early\n> exposure, here is the current draft of 1.5.0 release notes.\n> \n> -- >8 -- cut here -- >8 --\n> \n> GIT v1.5.0 Release Notes (draft)\n> ================================\n> \n> Old news\n> --------\n\n[...]\n\n> - There is a configuration variable core.legacyheaders that\n> changes the format of loose objects so that they are more\n> efficient to pack and to send out of the repository over git\n> native protocol, since v1.4.2. However, loose objects\n> written in the new format cannot be read by git older than\n> that version; people fetching from your repository using\n> older clients over dumb transports (e.g. http) using older\n> versions of git will also be affected.\n\nHuh?\n\nWhat are possible values of that variable? What happens if it is set/unset?\nI'd suppose that if it is set, you get the old format, but that isn't clear.\n\n> - Since v1.4.3, configuration repack.usedeltabaseoffset allows\n> packfile to be created in more space efficient format, which\n> cannot be read by git older than that version.\n\nSame as above.\n\n> The above two are not enabled by default and you explicitly have\n> to ask for them, because these two features make repositories\n> unreadable by older versions of git, and in v1.5.0 we still do\n> not enable them by default for the same reason. We will change\n> this default probably 1 year after 1.4.2's release, when it is\n> reasonable to expect everybody to have new enough version of\n> git.\n\nI don't see an upgrade path here that doesn't involve keeping cruft \"new\nfeature is on\" variables around indefinitely... Why not just a repository\nversion?\n\n[...]\n\n> Updates in v1.5.0 since v1.4.4 series\n> -------------------------------------\n> \n> * Index manipulation\n\n[...]\n\n> - git-add without any argument does not add everything\n> anymore. Use 'git-add .' instead. Also you can add\n> otherwise ignored files with an -f option.\n\nI suppose \"git add .\" works for 'adding everything' only at the top?\n\n> - git-add tries to be more friendly to users by offering an\n> interactive mode.\n\nWhy not tell about \"git add -i\"?\n\n[...]\n\n> * Detached HEAD\n\n[...]\n\n> - After detaching your HEAD, you can go back to an existing\n> branch with usual \"git checkout $branch\". Also you can\n> start a new branch using \"git checkout -b $newbranch\".\n\nWhere is such a branch rooted?\n\n> - You can even pull from other repositories, make merges and\n> commits while your HEAD is detached. Also you can use \"git\n> reset\" to jump to arbitrary commit.\n\nDoes this leave you on that branch, or still in limbo?\n\n> Going back to undetached state by \"git checkout $branch\" can\n\ns/undetached/attached/\n\n> lose the current stat you arrived in these ways, and \"git\n> checkout\" refuses when the detached HEAD is not pointed by\n> any existing ref (an existing branch, a remote tracking\n> branch or a tag). This safety can be overriden with \"git\n> checkout -f $branch\".\n\nWhat happens if there are changes in the tracked files?\n\n[...]\n\n> * Shallow clones\n> \n> - There is a partial support for 'shallow' repositories that\n> keeps only recent history. A 'shallow clone' is created by\n> specifying how deep that truncated history should be.\n\nA bit of detail on how to specify shallowness would be nice here...\n\n\nVery nice work, thanks!\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"32220","messageId":"45B3C3B4.6000706@zytor.com","threadId":"6461","inReplyTo":"7v7ivg1a25.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-01-21T19:49:08Z","receivedAt":"2007-01-21T19:49:08Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> One worry I had about releasing git-1.5.0-rc2-1.rpm and friends\n> just like the \"official\" ones was that people might have scripts\n> to automate downloading & updating of packages, and they may not\n> like to get \"beta\" installed for them.\n> \n> I wonder if kernel.org machines are also affected...\n> \n\nPut them in a different directory hierarchy if you don't want to make \nthem installed.\n\n>> I know it's a bit late to ask, but if new on-disk format changes, isn't\n>> it time to bump the version to 2.0? It would be easier for many people to\n>> remember that GIT 1.X uses format version 1 and that GIT 2.X uses format\n>> version 2 with backwards compatibility with 1.X. I also think that 1.5\n>> is much more different from 1.0 than a mid-term 2.0 would be from current\n>> 1.5.\n> \n> I think we could have gone either way (as you said, it is\n> probably a bit too late to discuss this), but it should probably\n> be Ok to stay at 1.X as long as these one-way-street format\n> updates are turned off by default.\n> \n> And the above happened way before this round and people have\n> hopefully been happily using. For example, v1.4.2 was done\n> early August 2006.\n\nIn general, though, I would agree that the major number should change if \nthere is an incompatible change.\n\n\t-hpa\n"},{"id":"32221","messageId":"200701212001.l0LK1ofV022758@laptop13.inf.utfsm.cl","threadId":"6461","inReplyTo":"7v7ivg1a25.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2007-01-21T20:01:50Z","receivedAt":"2007-01-21T20:01:50Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Willy Tarreau writes:\n> > Anything you can do to make tester's life easier will always slightly\n> > increase the number of testers.\n> > ...\n> > Pre-release tar.gz and rpms coupled with a freshmeat announcement should\n> > get you a bunch of testers and newcomers. This will give the new doc a\n> > real trial, and will help discover traps in which beginners often fall.\n> \n> One worry I had about releasing git-1.5.0-rc2-1.rpm and friends\n> just like the \"official\" ones was that people might have scripts\n> to automate downloading & updating of packages, and they may not\n> like to get \"beta\" installed for them.\n\nThen put them into a \"testing\" or \"pre-release\" directory...\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"32224","messageId":"7vmz4cyugr.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"200701211946.l0LJkTMV022057@laptop13.inf.utfsm.cl","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-21T20:51:16Z","receivedAt":"2007-01-21T20:51:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" writes:\n\n> What are possible values of that variable? What happens if it is set/unset?\n> I'd suppose that if it is set, you get the old format, but that isn't clear.\n\nAll are valid questions, but the release notes will be too long\nif it made into \"migration manual plus full documentation of new\nfeatures\". Its purpose is to list things you would want to pay\nattention to.\n\n> ...\n> I don't see an upgrade path here that doesn't involve keeping cruft \"new\n> feature is on\" variables around indefinitely...\n\nThe new feature will be on regardless of the configuration at\nsome point, perhaps in GIT 2.0. For now it isn't, and that is\nanother reason the release notes do not have to (and probably\nshould not for the sake of brevity) talk about gory details to\nturn the feature on. If we were to do the feature in\n\"incompatible by default\" way, the release notes should talk\nabout how to turn it off and keep the old way.\n\n>> - git-add tries to be more friendly to users by offering an\n>> interactive mode.\n>\n> Why not tell about \"git add -i\"?\n\nThanks, will update. s/mode\\.$/mode (\"git-add -i\")./\n\n>> - After detaching your HEAD, you can go back to an existing\n>> branch with usual \"git checkout $branch\". Also you can\n>> start a new branch using \"git checkout -b $newbranch\".\n>\n> Where is such a branch rooted?\n\nI did not think it needs to be mentioned as \"git checkout -b\n$newbranch\" has always been \"git checkout -b $newbranch HEAD\"\nand this is not changed with detached HEAD. Maybe I should add\n\"... to start a new branch at that commit\" at the end of the\nsentence. Thanks.\n\n>> - You can even pull from other repositories, make merges and\n>> commits while your HEAD is detached. Also you can use \"git\n>> reset\" to jump to arbitrary commit.\n>\n> Does this leave you on that branch, or still in limbo?\n\nPerhaps \"s/\\.$/, while still keeping your HEAD detached./\".\nWill update.\n\n>> lose the current stat you arrived in these ways, and \"git\n>> checkout\" refuses when the detached HEAD is not pointed by\n>> any existing ref (an existing branch, a remote tracking\n>> branch or a tag). This safety can be overriden with \"git\n>> checkout -f $branch\".\n>\n> What happens if there are changes in the tracked files?\n\nThe answer is \"just like normal checkout does\", but I think that\nlevel of detail does not belong to the release notes. The list\nof features is meant to be just to introduce what new things\nthere are, and people interested should learn the details from\nthe documentation.\n\n> A bit of detail on how to specify shallowness would be nice here...\n\nThe same comment as the above applies here.\n"},{"id":"32227","messageId":"Pine.LNX.4.63.0701212225350.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"17843.28673.205993.946369@lisa.zopyra.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-21T21:26:35Z","receivedAt":"2007-01-21T21:26:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Jan 2007, Bill Lear wrote:\n\n> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?\n\nDirect your browser to\n\nhttp://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f\n\nBTW please don't top post. It uses bandwidth unnecessarily (both in terms \nof megabytes and attention).\n\nCiao,\nDscho\n"},{"id":"32228","messageId":"ep0m67$so8$1@sea.gmane.org","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701212225350.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-21T21:33:40Z","receivedAt":"2007-01-21T21:33:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Sun, 21 Jan 2007, Bill Lear wrote:\n> \n>> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?\n> \n> Direct your browser to\n> \n> http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f\n\nBetter URL is\n\n http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32229","messageId":"Pine.LNX.4.63.0701212234520.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"7v3b6439uh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-21T21:55:52Z","receivedAt":"2007-01-21T21:55:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Jan 2007, Junio C Hamano wrote:\n\n> - 'git pack-refs' appeared in v1.4.4;\n\nYou should probably mention that it is not necessary to run git-pack-refs \nby hand: git-gc is what you want.\n\nBTW have I praised y'all for inventing git-gc? It is _awesome_. I think I \nwill turn into a DWIM geek yet; it is soooo much more convenient to issue \n\"git gc\" from time to time, than to think exactly about what I want to \nclean up right now.\n\n> - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were\n> seriously enhanced during v1.4.0 timeperiod.\n\nShould we introduce \"git config\" in time for the \"let's please end-users\" \nrelease (1.5.0)?\n\n> - git-clone always uses what is known as \"separate remote\"\n> layout for a newly created repository with a working tree;\n> i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are\n> used to track branches from the origin. \n\n... instead of $GIT_DIR/refs/heads/, making the difference between \nremotely tracked and local branches more obvious.\n\n> - git-branch and git-show-branch know remote tracking branches.\n\n... (use the command line switch \"-r\" to list only tracked branches.)\n\n> - git-push can now be used to delete a remote branch or a tag.\n> This requires the updated git on the remote side.\n\n... (use \"git push :refs/heads/\" to delete \"branch\".)\n\n> - git-push more agressively keeps the transferred objects\n> packed. Earlier we recommended to monitor amount of loose\n> objects and repack regularly, but you should repack when you\n> accumulated too many small packs this way as well. Updated\n> git-count-objects helps you with this.\n\nIt might make sense to enable something similar for git-fetch in time for \n1.5.0.\n\n> * Reflog\n> \n> - Reflog records the history of where the tip of each branch\n> was at each moment.\n\nIt might make sense to reformulate that:\n\n\tReflog records the history from the view point of the local \n\trepository. In other words, regardless of the real history,\n\tthe reflog shows the history as seen by one particular repository\n\t(this enables you to ask \"what was the current revision in _this_\n\trepository, yesterday at 1pm?\").\n\n> - There is a toplevel garbage collector script, 'git-gc', that\n> is an easy way to run 'git-repack -a -d', 'git-reflog gc',\n> and 'git-prune'.\n\nDid I mention that I really _love_ git-gc?\n\n> - The original implementation of git-merge-recursive which was\n> in Python has been removed; we have C implementation of it\n> now.\n\nI am no native speaker, but should that not be \"we have a C \nimplementation\" instead?\n\n> - The default suffix for git-format-patch output is now \".patch\",\n> not \".txt\". This can be changed with --suffix=.txt option,\n> or \"format.suffix = .txt\" in the configuration.\n\nI fully expect people to complain that a config like this\n\n\tformat.suffix = .txt\n\ndoes not work. better say ...\n\n\tor setting the config variable \"format.suffix\" to \".txt\".\n\n> - Better error messages for often used Porcelainish commands.\n\nAmen. I think this really helped a lot of people already.\n\n> - Cloning and fetching _from_ a shallow clone are not\n> supported (nor tested -- so they might work by accident but\n> they are not expected to).\n\nMaybe we should go the \"restrict first, and loosen later\" approach? I.e. \nforbid git-upload-pack to run if is_repository_shallow()?\n\n> - Pushing from nor into a shallow clone are not expected to\n> work.\n\nMaybe forbid git-push and git-receive-pack to run if \nis_repository_shallow()?\n\n(I _think_ git-push should be safe, but not git-receive-pack.)\n\nCiao,\nDscho\n"},{"id":"32231","messageId":"Pine.LNX.4.63.0701212300130.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"ep0m67$so8$1@sea.gmane.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-21T22:01:06Z","receivedAt":"2007-01-21T22:01:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Jan 2007, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Sun, 21 Jan 2007, Bill Lear wrote:\n> > \n> >> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?\n> > \n> > Direct your browser to\n> > \n> > http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f\n> \n> Better URL is\n> \n> http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2\n\nIt is a better URL. Somehow I fscked up when I tried it, so I had the \nimpression that does not work. But it does.\n\nSorry,\nDscho\n"},{"id":"32235","messageId":"ep0p55$6ko$1@sea.gmane.org","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701212300130.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-21T22:24:18Z","receivedAt":"2007-01-21T22:24:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> On Sun, 21 Jan 2007, Jakub Narebski wrote:\n>> Johannes Schindelin wrote:\n>>> On Sun, 21 Jan 2007, Bill Lear wrote:\n>>> \n>>>> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?\n>>> \n>>> Direct your browser to\n>>> \n>>> http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f\n>> \n>> Better URL is\n>> \n>> http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2\n> \n> It is a better URL. Somehow I fscked up when I tried it, so I had the \n> impression that does not work. But it does.\n\nMost probably you wrote '1.5.0-rc2' instead of 'v1.5.0-rc2'\n(with 'v' prefix).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32238","messageId":"ep0qc6$bph$1@sea.gmane.org","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701212234520.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-21T22:45:07Z","receivedAt":"2007-01-21T22:45:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Sun, 21 Jan 2007, Junio C Hamano wrote:\n\n>> * Reflog\n>> \n>> - Reflog records the history of where the tip of each branch\n>> was at each moment.\n> \n> It might make sense to reformulate that:\n> \n> Reflog records the history from the view point of the local \n> repository. In other words, regardless of the real history,\n> the reflog shows the history as seen by one particular repository\n> (this enables you to ask \"what was the current revision in _this_\n> repository, yesterday at 1pm?\").\n\nI think that _both_ sentences are right. Reflog records history of where the\ntip of each branch was at each moment, logging also what command was used\nto move tip of branch (was it commit, amending commit, rebase, reset, or\ncreating branch anew, git-am or pull).\n\nBut where tip of each branch was is purely local matter. What is global\nis DAG of commits, refs are always as seen by one particular repository.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32239","messageId":"Pine.LNX.4.63.0701212348070.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"ep0qc6$bph$1@sea.gmane.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-21T22:52:49Z","receivedAt":"2007-01-21T22:52:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Jan 2007, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Sun, 21 Jan 2007, Junio C Hamano wrote:\n> \n> >> * Reflog\n> >> \n> >> - Reflog records the history of where the tip of each branch\n> >> was at each moment.\n> > \n> > It might make sense to reformulate that:\n> > \n> > Reflog records the history from the view point of the local \n> > repository. In other words, regardless of the real history,\n> > the reflog shows the history as seen by one particular repository\n> > (this enables you to ask \"what was the current revision in _this_\n> > repository, yesterday at 1pm?\").\n> \n> I think that _both_ sentences are right. Reflog records history of where the\n> tip of each branch was at each moment, logging also what command was used\n> to move tip of branch (was it commit, amending commit, rebase, reset, or\n> creating branch anew, git-am or pull).\n> \n> But where tip of each branch was is purely local matter. What is global\n> is DAG of commits, refs are always as seen by one particular repository.\n\nWhat I meant was: people not familiar with git development will probably \nnot understand the shorter, concise statement. They will not know off-hand \nthat there is a difference between the history of development, and the \nhistory, as seen from the local repository's viewpoint.\n\nSo of course, both sentences are right.\n\nYour point -- that reflog also records the action -- is less important \nIMHO. It is just meta-data of the local view.\n\nTo your second point: the global history remains global, of course. But \nthis is what you _usually_ refer to, when talking about the development \nhistory, anyway. Therefore, to motivate reflogs, you should point out the \ndifferences between local and global history.\n\nAnd this means to at least _mention_ the word \"local\".\n\nCiao,\nDscho\n"},{"id":"32241","messageId":"200701220008.49158.jnareb@gmail.com","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701212348070.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-21T23:08:48Z","receivedAt":"2007-01-21T23:08:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Sun, 21 Jan 2007, Jakub Narebski wrote:\n> \n>> Johannes Schindelin wrote:\n>> \n>>> On Sun, 21 Jan 2007, Junio C Hamano wrote:\n>> \n>>>> * Reflog\n>>>> \n>>>> - Reflog records the history of where the tip of each branch\n>>>> was at each moment.\n>>> \n>>> It might make sense to reformulate that:\n>>> \n>>> Reflog records the history from the view point of the local \n>>> repository. In other words, regardless of the real history,\n>>> the reflog shows the history as seen by one particular repository\n>>> (this enables you to ask \"what was the current revision in _this_\n>>> repository, yesterday at 1pm?\").\n>> \n>> I think that _both_ sentences are right. Reflog records history of where the\n>> tip of each branch was at each moment, logging also what command was used\n>> to move tip of branch (was it commit, amending commit, rebase, reset, or\n>> creating branch anew, git-am or pull).\n>> \n>> But where tip of each branch was is purely local matter. What is global\n>> is DAG of commits, refs are always as seen by one particular repository.\n> \n> What I meant was: people not familiar with git development will probably \n> not understand the shorter, concise statement. They will not know off-hand \n> that there is a difference between the history of development, and the \n> history, as seen from the local repository's viewpoint.\n> \n> So of course, both sentences are right.\n> \n> Your point -- that reflog also records the action -- is less important \n> IMHO. It is just meta-data of the local view.\n> \n> To your second point: the global history remains global, of course. But \n> this is what you _usually_ refer to, when talking about the development \n> history, anyway. Therefore, to motivate reflogs, you should point out the \n> differences between local and global history.\n> \n> And this means to at least _mention_ the word \"local\".\n\nSo I'd say:\n\n - Reflog records local history of where the tip of each branch\n was at each moment.\n\nI think both \"local\" and \"tip of branch\" are important\nfor understanding reflog.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"32242","messageId":"Pine.LNX.4.63.0701220012580.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"200701220008.49158.jnareb@gmail.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-21T23:13:40Z","receivedAt":"2007-01-21T23:13:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Jan 2007, Jakub Narebski wrote:\n\n> So I'd say:\n> \n> - Reflog records local history of where the tip of each branch\n> was at each moment.\n> \n> I think both \"local\" and \"tip of branch\" are important\n> for understanding reflog.\n\n'kay. Probably the simple addition of \"local\" is enough. Like it.\n\nCiao,\nDscho\n"},{"id":"32245","messageId":"200701220036.10127.jnareb@gmail.com","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701220012580.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-21T23:36:09Z","receivedAt":"2007-01-21T23:36:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> On Mon, 22 Jan 2007, Jakub Narebski wrote:\n> \n>> So I'd say:\n>> \n>> - Reflog records local history of where the tip of each branch\n>> was at each moment.\n>> \n>> I think both \"local\" and \"tip of branch\" are important\n>> for understanding reflog.\n> \n> 'kay. Probably the simple addition of \"local\" is enough. Like it.\n\nOr perhaps this would be better:\n\n - Reflog records the history of where the tip of each branch\n was at each moment in given repository.\n\nJust nitpicking.\n-- \nJakub Narebski\nPoland\n"},{"id":"32254","messageId":"7vd557zxq6.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701212234520.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-22T00:55:29Z","receivedAt":"2007-01-22T00:55:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've read your message only once (may have to come back to think\nabout ramifications of some finer points), but I generally\nagree. I'd appreciate a patch to the 'todo' branch ;-).\n"},{"id":"32259","messageId":"7vk5zfyhoh.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"200701212001.l0LK1ofV022758@laptop13.inf.utfsm.cl","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-22T01:27:26Z","receivedAt":"2007-01-22T01:27:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" writes:\n\n> Junio C Hamano wrote:\n>> Willy Tarreau writes:\n>> > Anything you can do to make tester's life easier will always slightly\n>> > increase the number of testers.\n>> > ...\n>> > Pre-release tar.gz and rpms coupled with a freshmeat announcement should\n>> > get you a bunch of testers and newcomers. This will give the new doc a\n>> > real trial, and will help discover traps in which beginners often fall.\n>> \n>> One worry I had about releasing git-1.5.0-rc2-1.rpm and friends\n>> just like the \"official\" ones was that people might have scripts\n>> to automate downloading & updating of packages, and they may not\n>> like to get \"beta\" installed for them.\n>\n> Then put them into a \"testing\" or \"pre-release\" directory...\n\nOk, thanks for the suggestion.\n\nThe preview RPMs for i386 and x86_64 and an SRPM are available at:\n\n\t/pub/software/scm/git/testing/\n\nThe tarball for 1.5.0-rc2 is found at:\n\n\t/pub/software/scm/git/git-1.5.0.rc2.tar.gz\n\nalong with tarballs of preformatted htmldocs and manpages.\n"},{"id":"32279","messageId":"7vk5zfvaqi.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701212234520.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-22T06:25:41Z","receivedAt":"2007-01-22T06:25:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> - Cloning and fetching _from_ a shallow clone are not\n>> supported (nor tested -- so they might work by accident but\n>> they are not expected to).\n>\n> Maybe we should go the \"restrict first, and loosen later\" approach? I.e. \n> forbid git-upload-pack to run if is_repository_shallow()?\n>\n>> - Pushing from nor into a shallow clone are not expected to\n>> work.\n>\n> Maybe forbid git-push and git-receive-pack to run if \n> is_repository_shallow()?\n>\n> (I _think_ git-push should be safe, but not git-receive-pack.)\n\nI think that is sensible. Let's do this.\n\n-- >8 --\n[PATCH] shallow repository: disable unsupported operations for now.\n\nWe currently do not support fetching/cloning from a shallow repository\nnor pushing into one. Make sure these are not attempted so that we\ndo not have to worry about corrupting repositories needlessly.\n\nSigned-off-by: Junio C Hamano \n---\n receive-pack.c | 3 +++\n upload-pack.c | 3 ++-\n 2 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/receive-pack.c b/receive-pack.c\nindex c176d8f..6333f00 100644\n--- a/receive-pack.c\n+++ b/receive-pack.c\n@@ -421,6 +421,9 @@ int main(int argc, char **argv)\n \tif (!enter_repo(dir, 0))\n \t\tdie(\"'%s': unable to chdir or not a git archive\", dir);\n \n+\tif (is_repository_shallow())\n+\t\tdie(\"attempt to push into a shallow repository\");\n+\n \tsetup_ident();\n \t/* don't die if gecos is empty */\n \tignore_missing_committer_name();\ndiff --git a/upload-pack.c b/upload-pack.c\nindex 3a466c6..3648aae 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -672,7 +672,8 @@ int main(int argc, char **argv)\n \n \tif (!enter_repo(dir, strict))\n \t\tdie(\"'%s': unable to chdir or not a git archive\", dir);\n-\n+\tif (is_repository_shallow())\n+\t\tdie(\"attempt to fetch/clone from a shallow repository\");\n \tupload_pack();\n \treturn 0;\n }\n-- \n1.5.0.rc2\n"},{"id":"32314","messageId":"Pine.LNX.4.64.0701221220300.3011@xanadu.home","threadId":"6461","inReplyTo":"45B3C3B4.6000706@zytor.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-22T17:23:24Z","receivedAt":"2007-01-22T17:23:24Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 21 Jan 2007, H. Peter Anvin wrote:\n\n> In general, though, I would agree that the major number should change if there\n> is an incompatible change.\n\nMaybe when those incompatible features are enabled by default. Right \nnow they're not.\n\n\nNicolas\n"},{"id":"32316","messageId":"87lkjvhr2c.wl%cworth@cworth.org","threadId":"6461","inReplyTo":"7v3b6439uh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-22T18:08:59Z","receivedAt":"2007-01-22T18:08:59Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Sun, 21 Jan 2007 03:20:06 -0800, Junio C Hamano wrote:\n> Also, in the same spirit of giving the release an early\n> exposure, here is the current draft of 1.5.0 release notes.\n\nThanks, these are very good and really show how much great progress\nhas gone into git recently. Congratulations to everyone who has helped\nwith this!\n\nA few comments:\n\n> In general, you should not have to worry about incompatibility,\n> and there is no need to perform \"repository conversion\" if you\n> are updating to v1.5.0. However, some of the changes are\n> one-way street upgrades; once you use them your repository\n> can no longer be used with ancient git.\n\nThis \"one-way street upgrades\" sentence makes the upgrade to 1.5 sound\nscarier than it really is. It's only after two more paragraphs of\nfairly dense technical content that the reader is told that none of\nthis stuff is enabled by default yet.\n\nMaybe replace the second sentence with something like:\n\n\tAs of git v1.5.0 there are some optional changes to the\n\trepository that allow data to be stored and transferred more\n\tefficiently. These changes are not enabled by default as they\n\twill make the repository unusable with git versions before\n\tv1.4.2. Specifically the available options are:\n\nor something along those lines.\n\n> - git-update-index is much less visible.\n\nIt's not clear what this sentence means. Perhaps add something like:\n\n\t, (many mentions of update-index in git output and\n\tdocumentation have now been replaced by simpler commands such\n\tas \"git add\" or \"git rm\").\n\n> - git-clone always uses what is known as \"separate remote\"\n> layout for a newly created repository with a working tree;\n> i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are\n> used to track branches from the origin.\n\nThis change has some workflow impact that is not at all obvious from\nthe above description. For example, after cloning git.git, things that\nused to work like \"git checkout -b my-next next\" now no longer work,\n(needing to use \"origin/next\" instead). And these branches also won't\nappear in \"git branch\" output, (without the new -r option).\n\nI think the release notes should spend a little more attention on an\nissue like this. Maybe a separate section on changes to existing\ninterfaces, (as opposed to most of the other changes which are\nimprovements in the implementation of existing interfaces or just\nplain new interfaces such as \"git remote\", \"git gc\", etc.)\n\nIf there is a new section, the previous paragraphs describing the move\nof cloned origin information from .git/remotes/origin to .git/config\nmight belong there as well, (depending on whether you consider those\nfile contents a user-visible interface or not).\n\n> - git-branch and git-show-branch know remote tracking branches.\n\nShould mention \"-r\" here.\n\n> - git-push can now be used to delete a remote branch or a tag.\n> This requires the updated git on the remote side.\n\nWhat's the syntax for this? I know you don't want to turn the release\nnotes into a user manual, but it'd be nice to have brief mentions of\nthe new interfaces, (like the nice mention of \"git add -i\" for\nexample). Even with a quick skim through the git-push documentation,\nI'm not immediately seeing how to delete a remote branch or tag.\n\n> - There is a toplevel garbage collector script, 'git-gc', that\n> is an easy way to run 'git-repack -a -d', 'git-reflog gc',\n> and 'git-prune'.\n\nI think it's definitely worthwhile to note the fix of race conditions,\netc. here. It would be nice to have some short rule such as:\n\n\t\"git gc\" is free from any known race conditions with\n\tsimultaneous git processes modifying the repository. So it's\n\tperfectly safe to run \"git gc\" from a cron job.\n\nOr a similarly succinct rule that's actually true, (I think the recent\nthread suggested \"git gc\" would only be safe with an extra\noption---I'd much rather see it be safe by default and make the user\nask for extra unsafe pruning with an option).\n\n> - You can give non-branch to \"git checkout\" now.\n\nRather than \"non-branch\" I think it would be nice to say something\nthat mentioned tags. Maybe something like:\n\n\tYou can now use 'git checkout' to checkout tags or any other\n\trevision, rather than just named branches.\"\n\n> - Repositories with hundreds of tags have been paying large\n> overhead, both in storage and in runtime, due to the\n> traditional one-ref-per-file format. A new command,\n> git-pack-refs, can be used to \"pack\" them in more efficient\n> representation.\n\nIs git-gc doing this housekeeping? If not, should it be? If so, should\nit be mentioned here (and in the description of git-gc above)?\n\n> - There is a partial support for 'shallow' repositories that\n> keeps only recent history. A 'shallow clone' is created by\n> specifying how deep that truncated history should be.\n\nHere's another description that could definitely benefit from a very\nshort example command.\n\n-Carl\n"},{"id":"32317","messageId":"ep2vb2$p9s$1@sea.gmane.org","threadId":"6461","inReplyTo":"7v3b6439uh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-22T18:22:08Z","receivedAt":"2007-01-22T18:22:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> GIT v1.5.0 Release Notes (draft)\n> ================================\n\nWould they be somewhere besides todo branch of git.git repository, like the\nv1.5.0 tag comment (content), or the NEWS file?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32318","messageId":"7vodoqucg1.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"ep2vb2$p9s$1@sea.gmane.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-22T18:46:22Z","receivedAt":"2007-01-22T18:46:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> GIT v1.5.0 Release Notes (draft)\n>> ================================\n>\n> Would they be somewhere besides todo branch of git.git repository, like the\n> v1.5.0 tag comment (content), or the NEWS file?\n\nMost likely the former would happen when the real thing is made.\n"},{"id":"32320","messageId":"7vd556uahr.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"87lkjvhr2c.wl%cworth@cworth.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-22T19:28:32Z","receivedAt":"2007-01-22T19:28:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks for your comments; the attached probably needs\nproofreading.\n\nThe changes in response to the remainder of your comments are\nquite straightforward and I do not think needs proofreading, so\nI'll incorporate them and push the result out in 'todo'.\n\ndiff --git a/v1.5.0.txt b/v1.5.0.txt\nindex c0ff071..596bfd2 100644\n--- a/v1.5.0.txt\n+++ b/v1.5.0.txt\n@@ -107,11 +107,40 @@ Updates in v1.5.0 since v1.4.4 series\n already comfortable with your workflow with the layout.\n \n - git-clone always uses what is known as \"separate remote\"\n- layout for a newly created repository with a working tree;\n- i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are\n- used to track branches from the origin, instead of\n- $GIT_DIR/refs/heads/, making the difference between remotely\n- tracked and local branches more obvious.\n+ layout for a newly created repository with a working tree.\n+\n+ A repository with the separate remote layout starts with only\n+ one default branch, 'master', to be used for your own\n+ development. Unlike the traditional layout that copied all\n+ the upstream branches into your branch namespace (while\n+ renaming their 'master' to your 'origin'), they are not made\n+ into your branches. Instead, they are kept track of using\n+ 'refs/remotes/origin/$upstream_branch_name'.\n+\n+ This layout keeps your own branch namespace less cluttered,\n+ avoids name collision with your upstream, makes it possible\n+ to automatically track new branches created at the remote\n+ after you clone from it, and makes it easier to interact with\n+ more than one remote repositories. There might be some\n+ surprises:\n+\n+ * 'git branch' does not show the branches from your upstream.\n+ It only lists your own branches. Use '-r' option to view\n+ the tracking branches.\n+\n+ * If you are forking off of a branch obtained from the\n+ upstream, you would have done something like 'git branch\n+ my-next next', because traditional layout dropped the\n+ tracking branch 'next' into your own branch namespace.\n+ With the separate remote layout, you say 'git branch next\n+ origin/next', which allows you to use the matching name\n+ 'next' for your own branch. It also allows you to track a\n+ remote other than 'origin' (i.e. where you initially cloned\n+ from) and fork off of a branch from there the same way\n+ (e.g. \"git branch mingw j6t/master\").\n+\n+ Repositories initialized with the traditional layout\n+ continues to work (and will continue to work).\n \n - New branches that appear on the origin side after a clone is\n made are also tracked automatically. This is done with an\n"},{"id":"32357","messageId":"87bqkqimiv.wl%cworth@cworth.org","threadId":"6461","inReplyTo":"7vd556uahr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-23T01:01:44Z","receivedAt":"2007-01-23T01:01:44Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 22 Jan 2007 11:28:32 -0800, Junio C Hamano wrote:\n> Thanks for your comments;\n\nYou're welcome.\n\n> the attached probably needs proofreading.\n\nIn general, I like it. The git-branch documentation already talks\nabout \"remote-tracking branches\" so I've rewritten a couple of\nsentence below to use that same terminology. Also there are a couple\nof grammar errors related to pluralization, (likely the fault of\nEnglish being quite a bit less consistent than other languages with\nsubject/verb number agreement, etc.).\n\n> + A repository with the separate remote layout starts with only\n> + one default branch, 'master', to be used for your own\n> + development. Unlike the traditional layout that copied all\n> + the upstream branches into your branch namespace (while\n> + renaming their 'master' to your 'origin'), they are not made\n> + into your branches. Instead, they are kept track of using\n> + 'refs/remotes/origin/$upstream_branch_name'.\n\n renaming remote 'master' to local 'origin'), the new approach\n puts upstream branches into local \"remote-tracking branches\"\n with their own namespace. These can be referenced with names\n such as \"origin/$upstream_branch_name\" and are stored in\n .git/refs/remotes rather than .git/refs/heads where normal\n branches are stored.\n\n> + This layout keeps your own branch namespace less cluttered,\n> + avoids name collision with your upstream, makes it possible\n> + to automatically track new branches created at the remote\n> + after you clone from it, and makes it easier to interact with\n> + more than one remote repositories. There might be some\n\nShould be \"more than one remote repository.\". Also I'd add, \", (see\nthe new 'git remote' command)\" before the end of that sentence.\n\n> + * 'git branch' does not show the branches from your upstream.\n\nAgain to use the same terminology, \"does not show the remote-tracking\nbranches.\".\n\n> + Repositories initialized with the traditional layout\n> + continues to work (and will continue to work).\n\nThe 's' on \"continues\" is incorrect. Perhaps:\n\n\tcontinue to work (and will work in the future as well).\n\nor just drop the parenthetical phrase.\n\n-Carl\n"},{"id":"32366","messageId":"7v64ayp7ca.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701212234520.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"[PATCH 1/2] Refactor the pack header reading function out of receive-pack.c","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-23T06:47:49Z","receivedAt":"2007-01-23T06:47:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I'll be reusing it on the fetch-pack side as well.\n\nSigned-off-by: Junio C Hamano \n---\n\n Johannes Schindelin writes:\n\n >> - git-push more agressively keeps the transferred objects\n >> packed. Earlier we recommended to monitor amount of loose\n >> objects and repack regularly, but you should repack when you\n >> accumulated too many small packs this way as well. Updated\n >> git-count-objects helps you with this.\n >\n > It might make sense to enable something similar for git-fetch in time for \n > 1.5.0.\n\n I have two patches that could become the beginning of this, not\n much tested. This is the first of the two.\n\n pack.h | 5 +++++\n receive-pack.c | 26 ++++++++++++++------------\n sha1_file.c | 21 +++++++++++++++++++++\n 3 files changed, 40 insertions(+), 12 deletions(-)\n\ndiff --git a/pack.h b/pack.h\nindex 821706f..deb427e 100644\n--- a/pack.h\n+++ b/pack.h\n@@ -44,4 +44,9 @@ struct pack_header {\n #define PACK_IDX_SIGNATURE 0xff744f63\t/* \"\\377tOc\" */\n \n extern int verify_pack(struct packed_git *, int);\n+\n+#define PH_ERROR_EOF\t\t(-1)\n+#define PH_ERROR_PACK_SIGNATURE\t(-2)\n+#define PH_ERROR_PROTOCOL\t(-3)\n+extern int read_pack_header(int fd, struct pack_header *);\n #endif\ndiff --git a/receive-pack.c b/receive-pack.c\nindex 6333f00..b3a4552 100644\n--- a/receive-pack.c\n+++ b/receive-pack.c\n@@ -250,20 +250,22 @@ static void read_head_info(void)\n \n static const char *parse_pack_header(struct pack_header *hdr)\n {\n-\tchar *c = (char*)hdr;\n-\tssize_t remaining = sizeof(struct pack_header);\n-\tdo {\n-\t\tssize_t r = xread(0, c, remaining);\n-\t\tif (r <= 0)\n-\t\t\treturn \"eof before pack header was fully read\";\n-\t\tremaining -= r;\n-\t\tc += r;\n-\t} while (remaining > 0);\n-\tif (hdr->hdr_signature != htonl(PACK_SIGNATURE))\n+\tswitch (read_pack_header(0, hdr)) {\n+\tcase PH_ERROR_EOF:\n+\t\treturn \"eof before pack header was fully read\";\n+\n+\tcase PH_ERROR_PACK_SIGNATURE:\n \t\treturn \"protocol error (pack signature mismatch detected)\";\n-\tif (!pack_version_ok(hdr->hdr_version))\n+\n+\tcase PH_ERROR_PROTOCOL:\n \t\treturn \"protocol error (pack version unsupported)\";\n-\treturn NULL;\n+\n+\tdefault:\n+\t\treturn \"unknown error in parse_pack_header\";\n+\n+\tcase 0:\n+\t\treturn NULL;\n+\t}\n }\n \n static const char *pack_lockfile;\ndiff --git a/sha1_file.c b/sha1_file.c\nindex 43ff402..498665e 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -2048,3 +2048,24 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write\n \t}\n \treturn 0;\n }\n+\n+int read_pack_header(int fd, struct pack_header *header)\n+{\n+\tchar *c = (char*)header;\n+\tssize_t remaining = sizeof(struct pack_header);\n+\tdo {\n+\t\tssize_t r = xread(fd, c, remaining);\n+\t\tif (r <= 0)\n+\t\t\t/* \"eof before pack header was fully read\" */\n+\t\t\treturn PH_ERROR_EOF;\n+\t\tremaining -= r;\n+\t\tc += r;\n+\t} while (remaining > 0);\n+\tif (header->hdr_signature != htonl(PACK_SIGNATURE))\n+\t\t/* \"protocol error (pack signature mismatch detected)\" */\n+\t\treturn PH_ERROR_PACK_SIGNATURE;\n+\tif (!pack_version_ok(header->hdr_version))\n+\t\t/* \"protocol error (pack version unsupported)\" */\n+\t\treturn PH_ERROR_PROTOCOL;\n+\treturn 0;\n+}\n-- \n1.5.0.rc2.gc9a89\n"},{"id":"32365","messageId":"7vzm8ansrt.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701212234520.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"[PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-23T06:47:50Z","receivedAt":"2007-01-23T06:47:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"With --keep-auto option, fetch-pack decides to keep the pack\nwithout exploding it just like receive-pack does.\n\nWe may want to later make this the default.\n\nSigned-off-by: Junio C Hamano \n---\n\n And this is the second half. It looks larger than it really\n is, because it involves some code movements; it removes two\n separate functions that called get_pack() and moves what they\n did to get_pack() after setup_sideband() happens.\n\n Although I did test it with --keep-auto with large and small\n packs once each. I haven't tested this at all with the\n git-fetch script.\n\n fetch-pack.c | 91 +++++++++++++++++++++++++++++++++++++--------------------\n 1 files changed, 59 insertions(+), 32 deletions(-)\n\ndiff --git a/fetch-pack.c b/fetch-pack.c\nindex 726140a..4ee041c 100644\n--- a/fetch-pack.c\n+++ b/fetch-pack.c\n@@ -4,9 +4,11 @@\n #include \"commit.h\"\n #include \"tag.h\"\n #include \"exec_cmd.h\"\n+#include \"pack.h\"\n #include \"sideband.h\"\n \n static int keep_pack;\n+static int keep_auto;\n static int quiet;\n static int verbose;\n static int fetch_all;\n@@ -486,13 +488,58 @@ static pid_t setup_sideband(int fd[2], int xd[2])\n \treturn side_pid;\n }\n \n-static int get_pack(int xd[2], const char **argv)\n+static int get_pack(int xd[2])\n {\n \tint status;\n \tpid_t pid, side_pid;\n \tint fd[2];\n+\tconst char *argv[20];\n+\tchar keep_arg[256];\n+\tchar hdr_arg[256];\n+\tconst char **av;\n+\tint do_keep = keep_pack;\n \n \tside_pid = setup_sideband(fd, xd);\n+\n+\tav = argv;\n+\t*hdr_arg = 0;\n+\tif (keep_auto) {\n+\t\tstruct pack_header header;\n+\n+\t\tif (read_pack_header(fd[0], &header))\n+\t\t\tdie(\"protocol error: bad pack header\");\n+\t\tsnprintf(hdr_arg, sizeof(hdr_arg), \"--pack_header=%u,%u\",\n+\t\t\t ntohl(header.hdr_version), ntohl(header.hdr_entries));\n+\t\tif (ntohl(header.hdr_entries) < keep_auto)\n+\t\t\tdo_keep = 0;\n+\t\telse\n+\t\t\tdo_keep = 1;\n+\t}\n+\n+\tif (do_keep) {\n+\t\t*av++ = \"index-pack\";\n+\t\t*av++ = \"--stdin\";\n+\t\tif (!quiet)\n+\t\t\t*av++ = \"-v\";\n+\t\tif (use_thin_pack)\n+\t\t\t*av++ = \"--fix-thin\";\n+\t\tif (keep_pack > 1 || keep_auto) {\n+\t\t\tint s = sprintf(keep_arg,\n+\t\t\t\t\t\"--keep=fetch-pack %d on \", getpid());\n+\t\t\tif (gethostname(keep_arg + s, sizeof(keep_arg) - s))\n+\t\t\t\tstrcpy(keep_arg + s, \"localhost\");\n+\t\t\t*av++ = keep_arg;\n+\t\t}\n+\t}\n+\telse {\n+\t\t*av++ = \"unpack-objects\";\n+\t\tif (quiet)\n+\t\t\t*av++ = \"-q\";\n+\t}\n+\tif (*hdr_arg)\n+\t\t*av++ = hdr_arg;\n+\t*av++ = NULL;\n+\n \tpid = fork();\n \tif (pid < 0)\n \t\tdie(\"fetch-pack: unable to fork off %s\", argv[0]);\n@@ -522,39 +569,10 @@ static int get_pack(int xd[2], const char **argv)\n \tdie(\"%s died of unnatural causes %d\", argv[0], status);\n }\n \n-static int explode_rx_pack(int xd[2])\n-{\n-\tconst char *argv[3] = { \"unpack-objects\", quiet ? \"-q\" : NULL, NULL };\n-\treturn get_pack(xd, argv);\n-}\n-\n-static int keep_rx_pack(int xd[2])\n-{\n-\tconst char *argv[6];\n-\tchar keep_arg[256];\n-\tint n = 0;\n-\n-\targv[n++] = \"index-pack\";\n-\targv[n++] = \"--stdin\";\n-\tif (!quiet)\n-\t\targv[n++] = \"-v\";\n-\tif (use_thin_pack)\n-\t\targv[n++] = \"--fix-thin\";\n-\tif (keep_pack > 1) {\n-\t\tint s = sprintf(keep_arg, \"--keep=fetch-pack %i on \", getpid());\n-\t\tif (gethostname(keep_arg + s, sizeof(keep_arg) - s))\n-\t\t\tstrcpy(keep_arg + s, \"localhost\");\n-\t\targv[n++] = keep_arg;\n-\t}\n-\targv[n] = NULL;\n-\treturn get_pack(xd, argv);\n-}\n-\n static int fetch_pack(int fd[2], int nr_match, char **match)\n {\n \tstruct ref *ref;\n \tunsigned char sha1[20];\n-\tint status;\n \n \tget_remote_heads(fd[0], &ref, 0, NULL, 0);\n \tif (is_repository_shallow() && !server_supports(\"shallow\"))\n@@ -589,8 +607,7 @@ static int fetch_pack(int fd[2], int nr_match, char **match)\n \t\t\t */\n \t\t\tfprintf(stderr, \"warning: no common commits\\n\");\n \n-\tstatus = (keep_pack) ? keep_rx_pack(fd) : explode_rx_pack(fd);\n-\tif (status)\n+\tif (get_pack(fd))\n \t\tdie(\"git-fetch-pack: fetch failed.\");\n \n all_done:\n@@ -655,6 +672,16 @@ int main(int argc, char **argv)\n \t\t\t\tkeep_pack++;\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(\"--keep-auto\", arg)) {\n+\t\t\t\tkeep_auto = 100;\n+\t\t\t\tcontinue;\n+\t\t\t}\n+\t\t\tif (!strncmp(\"--keep-auto=\", arg, 12)) {\n+\t\t\t\tkeep_auto = strtoul(arg + 12, NULL, 0);\n+\t\t\t\tif (keep_auto < 20)\n+\t\t\t\t\tkeep_auto = 20;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(\"--thin\", arg)) {\n \t\t\t\tuse_thin_pack = 1;\n \t\t\t\tcontinue;\n-- \n1.5.0.rc2.gc9a89\n"},{"id":"32376","messageId":"Pine.LNX.4.63.0701231129501.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"7vzm8ansrt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T10:32:55Z","receivedAt":"2007-01-23T10:32:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Jan 2007, Junio C Hamano wrote:\n\n> With --keep-auto option, fetch-pack decides to keep the pack without \n> exploding it just like receive-pack does.\n\nI like both patches. (Did not have time to test yet, but from looking at \nthe patches, it seems indeed to be mostly code moves.)\n\n> We may want to later make this the default.\n\nYou have my vote for sooner rather than later.\n\nCiao,\nDscho\n\nP.S.: These patches make me dream of yet another diff format enhancement: \ncode moves! Of course, for this to be really usable, you'd also have to \nautomatically determine indent changes... You may say I'm a dreamer. But \nI'm not the only one...\n"},{"id":"32377","messageId":"ep4phb$fef$1@sea.gmane.org","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701231129501.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-23T10:55:26Z","receivedAt":"2007-01-23T10:55:26Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> P.S.: These patches make me dream of yet another diff format enhancement: \n> code moves! Of course, for this to be really usable, you'd also have to \n> automatically determine indent changes... You may say I'm a dreamer. But \n> I'm not the only one...\n\nI wonder if it could be done with e.g.\n\n--- a/fromfile\n+++ b/somefile\n\n\n--- a/somefile\n+++ b/somefile\n\n\nThe problem is that context differs usually for code movement.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32380","messageId":"Pine.LNX.4.63.0701231205110.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"ep4phb$fef$1@sea.gmane.org","subject":"code movements in diffs, was Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T11:07:45Z","receivedAt":"2007-01-23T11:07:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n> \n> > P.S.: These patches make me dream of yet another diff format enhancement: \n> > code moves! Of course, for this to be really usable, you'd also have to \n> > automatically determine indent changes... You may say I'm a dreamer. But \n> > I'm not the only one...\n> \n> I wonder if it could be done with e.g.\n> \n> --- a/fromfile\n> +++ b/somefile\n> \n> \n> --- a/somefile\n> +++ b/somefile\n> \n> \n> The problem is that context differs usually for code movement.\n\nThere is a more fundamental problem here: both \"diff\" and \"patch\" walk the \nfile pair in a direction. The whole \"code movement\" stuff would break this \nparadigm. What you found is just _one_ consequence.\n\nBut as I said: a man can still dream, can't he?\n\nCiao,\nDscho\n"},{"id":"32424","messageId":"Pine.LNX.4.64.0701231101040.3011@xanadu.home","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701231129501.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-23T16:01:53Z","receivedAt":"2007-01-23T16:01:53Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 23 Jan 2007, Johannes Schindelin wrote:\n\n> On Mon, 22 Jan 2007, Junio C Hamano wrote:\n> \n> > We may want to later make this the default.\n> \n> You have my vote for sooner rather than later.\n\nSeconded.\n\n\nNicolas\n"},{"id":"32425","messageId":"Pine.LNX.4.64.0701230809440.32200@woody.linux-foundation.org","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701231129501.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-23T16:15:47Z","receivedAt":"2007-01-23T16:15:47Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 23 Jan 2007, Johannes Schindelin wrote:\n> \n> P.S.: These patches make me dream of yet another diff format enhancement: \n> code moves!\n\nIt's basically impossible.\n\nWhy? You need the context. \n\nIn a _context_less_ diff, it's fairly trivial to indicate code movement: \nyou just say \"move bytes x-y into z\". However, if you want anything \napproaching readability and safety, you want context, and that \nautomatically means that you need to have the stuff around the context, \nwhich in turn means that you can't sanely do that.\n\nSure, you could do a diff that has the *context* repeated around the code \nthat moves (and not actually quoting all the movement itself, except for \nthe first and last three lines or something), but that would be really \nunreadable. A lot more unreadable than what we have now, with delete+add \nchunks.\n\n> Of course, for this to be really usable, you'd also have to \n> automatically determine indent changes...\n\nIndeed. Much code movement isn't just pure data movement, it's \nre-indentation too. Making the thing even less tractable.\n\nIn other words - you can do it (and we _do_ do it) when you don't do diffs \nat all, but deltas. Our deltas actually do contain block movement. But \ndiffs? Forget about it.\n\n> You may say I'm a dreamer. But I'm not the only one...\n\nI am the walrus.\n\n\t\tLinus\n"},{"id":"32428","messageId":"87sle17lnm.fsf@morpheus.local","threadId":"6461","inReplyTo":"Pine.LNX.4.64.0701230809440.32200@woody.linux-foundation.org","subject":"Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-01-23T16:28:13Z","receivedAt":"2007-01-23T16:28:13Z","isPatch":true,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 23 Jan 2007, Johannes Schindelin wrote:\n>> \n>> P.S.: These patches make me dream of yet another diff format enhancement: \n>> code moves!\n>\n> It's basically impossible.\n>\n> Why? You need the context. \n\nYes, I think that a diff format for code moves wouldn't be useful.\nWhat could potentially be useful is a graphical diff browser that can\ne.g. show two versions side-by-side and show code moves in that. I\nhave a vague memory that the ClearCase merge tool did that.\n\nBut as long as the code moves are within a single file, that merge\ntool could derive that move from an ordinary diff.\n\n-- \nDavid Kågedal\n"},{"id":"32431","messageId":"Pine.LNX.4.63.0701231738460.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"87sle17lnm.fsf@morpheus.local","subject":"Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T16:43:40Z","receivedAt":"2007-01-23T16:43:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[Re-Cc'ing Linus]\n\nOn Tue, 23 Jan 2007, David Kågedal wrote:\n\n> Linus Torvalds writes:\n> \n> > On Tue, 23 Jan 2007, Johannes Schindelin wrote:\n> >> \n> >> P.S.: These patches make me dream of yet another diff format enhancement: \n> >> code moves!\n> >\n> > It's basically impossible.\n> >\n> > Why? You need the context. \n> \n> Yes, I think that a diff format for code moves wouldn't be useful.\n> What could potentially be useful is a graphical diff browser that can\n> e.g. show two versions side-by-side and show code moves in that. I\n> have a vague memory that the ClearCase merge tool did that.\n\nI don't need no steenking graphical tools. I want to read me mailing list, \nthat's it.\n\n> But as long as the code moves are within a single file, that merge tool \n> could derive that move from an ordinary diff.\n\nActually, you could even derive a code movement between files from the set \nof diffs. Though not code copies. But then, we don't do code copies.\n\nSeriously again, your comment got me thinking: it could actually make \nsense to include the information of code moves and code copies (for easier \nreview) in the \"@@ .. @@\" lines (or before them, if git apply does not \nchoke on inserting garbage lines before them).\n\nBut maybe it is not that good after all: if you review code, you should \ninspect it (even if it was only moved), since it might have all kinds of \nside effects, or you might have missed some other aspect before.\n\nCiao,\nDscho\n"},{"id":"32435","messageId":"ep5g7f$bok$1@sea.gmane.org","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701231738460.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-23T17:22:43Z","receivedAt":"2007-01-23T17:22:43Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> Seriously again, your comment got me thinking: it could actually make \n> sense to include the information of code moves and code copies (for easier \n> review) in the \"@@ .. @@\" lines (or before them, if git apply does not \n> choke on inserting garbage lines before them).\n> \n> But maybe it is not that good after all: if you review code, you should \n> inspect it (even if it was only moved), since it might have all kinds of \n> side effects, or you might have missed some other aspect before.\n\nIt would be nice to have extended git header dealing with code copies\n(or stuff it in chunk header or above), because sometimes both sides\nof code movement (removal from one file, adding in next file) can be\nseparated by a few pagefulls of chunks.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32437","messageId":"17846.20498.635623.173653@lisa.zopyra.com","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701211207500.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-23T18:12:34Z","receivedAt":"2007-01-23T18:12:34Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Sunday, January 21, 2007 at 12:08:25 (+0100) Johannes Schindelin writes:\n>Hi,\n>\n>On Sun, 21 Jan 2007, Jakub Narebski wrote:\n>\n>> By the way, was the pager configured to saner values, so \"git diff\" on a \n>> repository with no changes does not output empty page?\n>\n>As Junio mentioned: it already does. Maybe you have set the environment \n>variable \"LESS\", and forgot to include \"-F\"?\n\nI can't seem to get this to work, no matter what I do, using the\nlatest 1.5.0-rc2 code. I have the environment variables LESS, PAGER,\nPAGER_FLAGS, and I can't seem to get 'git diff' to not plough through\nmy screen each time it is run, no matter the combinations... Could\nsomeone post the magic?\n\n\nBill\n"},{"id":"32439","messageId":"Pine.LNX.4.63.0701232012120.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"17846.20498.635623.173653@lisa.zopyra.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T19:12:36Z","receivedAt":"2007-01-23T19:12:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Bill Lear wrote:\n\n> I can't seem to get this to work, no matter what I do, using the latest \n> 1.5.0-rc2 code. I have the environment variables LESS, PAGER, \n> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my \n> screen each time it is run, no matter the combinations... Could someone \n> post the magic?\n\nTry this:\n\n\tPAGER=less LESS=-FRS git diff\n\nHth,\nDscho\n"},{"id":"32446","messageId":"17846.27694.845530.663964@lisa.zopyra.com","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701232012120.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-23T20:12:30Z","receivedAt":"2007-01-23T20:12:30Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Tuesday, January 23, 2007 at 20:12:36 (+0100) Johannes Schindelin writes:\n>Hi,\n>\n>On Tue, 23 Jan 2007, Bill Lear wrote:\n>\n>> I can't seem to get this to work, no matter what I do, using the latest \n>> 1.5.0-rc2 code. I have the environment variables LESS, PAGER, \n>> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my \n>> screen each time it is run, no matter the combinations... Could someone \n>> post the magic?\n>\n>Try this:\n>\n>\tPAGER=less LESS=-FRS git diff\n\nReplied to Johannes off-line and thought this was working --- sorry\nfor the false positive. It is in one regard: it completely suppresses\noutput if there is less than a full screen of output.\n\nIf I do this:\n\n% export PAGER=less\n% unset LESS\n% git diff\n\nI get 30 lines of output in my current repository, as I should.\n\nIf I then do this:\n\n% LESS=-FRS git diff\n\nI get nothing --- I do see a brief blink of output, but it's as if\nless swallows it whole and I see nothing but the next prompt.\n\nHmmm ... I do seem to be using a rather old version of less:\n\n% less --version\nless 382\nCopyright (C) 2002 Mark Nudelman\n\nCould this be the culprit? Will try and see... Nope, downloaded,\nbuilt, and installed less-394 and I still see the same problem. I also\nsee this problem when I do 'man git-gc', for example --- the manpage\njust disappears.\n\nIf I set LESS to '-F' it fails. If set to '-RS', output is seen but\nthen I see the screen blanked when there is no output from git diff.\n\nThis is on Centos 4.3. I have not yet tried this on my Fedora Core 6\nlaptop, at home...\n\n\n\nBill\n"},{"id":"32447","messageId":"20070123202231.GA2765@cepheus","threadId":"6461","inReplyTo":"17846.27694.845530.663964@lisa.zopyra.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-01-23T20:22:32Z","receivedAt":"2007-01-23T20:22:32Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello Bill,\n\n> \n> % export PAGER=less\n> % unset LESS\n> % git diff\n> \n> I get 30 lines of output in my current repository, as I should.\n> \n> If I then do this:\n> \n> % LESS=-FRS git diff\nWhat about:\n\n\tLESS=-FRSX git diff\n\n?\n\nHTH\nUwe\n\n-- \nUwe Kleine-König\n\nhttp://www.google.com/search?q=sin%28pi%2F2%29\n"},{"id":"32448","messageId":"Pine.LNX.4.63.0701232119360.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"17846.27694.845530.663964@lisa.zopyra.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T20:22:39Z","receivedAt":"2007-01-23T20:22:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Bill Lear wrote:\n\n> % less --version\n> less 382\n\nIt works here, with 381 _and_ 376+iso254.\n\n> If I set LESS to '-F' it fails. If set to '-RS', output is seen but \n> then I see the screen blanked when there is no output from git diff.\n\nThis looks more like a broken terminal interaction to me.\n\nCiao,\nDscho\n"},{"id":"32449","messageId":"17846.28847.436225.732284@lisa.zopyra.com","threadId":"6461","inReplyTo":"20070123202231.GA2765@cepheus","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-23T20:31:43Z","receivedAt":"2007-01-23T20:31:43Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Tuesday, January 23, 2007 at 21:22:32 (+0100) Uwe Kleine-König writes:\n>> % export PAGER=less\n>> % unset LESS\n>> % git diff\n>> \n>> I get 30 lines of output in my current repository, as I should.\n>> \n>> If I then do this:\n>> \n>> % LESS=-FRS git diff\n>What about:\n>\n>\tLESS=-FRSX git diff\n\nWell, I see output when there is output to show, yes, but it still\nblanks the screen --- or, I should say, scrolls all the way to the\nbottom --- when there is no difference to show.\n\nI do note that if LESS is not set, git sets it (in pager.c) to just\nwhat you have above (FRSX).\n\n\nBill\n"},{"id":"32450","messageId":"Pine.LNX.4.64.0701231157430.32200@woody.linux-foundation.org","threadId":"6461","inReplyTo":"17846.20498.635623.173653@lisa.zopyra.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-23T20:32:18Z","receivedAt":"2007-01-23T20:32:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n[ Added \"less\" author Mark Nudelman to Cc: ]\n\nOn Tue, 23 Jan 2007, Bill Lear wrote:\n> \n> I can't seem to get this to work, no matter what I do, using the\n> latest 1.5.0-rc2 code. I have the environment variables LESS, PAGER,\n> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through\n> my screen each time it is run, no matter the combinations... Could\n> someone post the magic?\n\nI think \"less\" is actually seriously buggy with -F.\n\nThere are two bugs:\n\n - it will always screw up the screen and move to the end. It does this \n even if you use -FX which should disable any init sequences, so it's \n not about that problem.\n\n - if you resize the terminal while less is waiting for input, less\n will exit entirely without even showing the output. This is very\n noticeable if you do something like \"git diff\" on a big and cold-cache \n tree and git takes a few seconds to think, and then you resize the \n window while it's preparing. Boom. No output AT ALL.\n\nBoth bugs are easily seen with this simple command line\n\n\tclear ; (sleep 5 ; echo Hello) | less -F\n\nwhere you would EXPECT that the \"Hello\" would show up at the first line of \nthe screen (since we cleared the screen and moved to the top left corner), \nbut in fact it doesn't.\n\nAnd try resizing the terminal to make it bigger during the five-second \npause, and now you'll see less not show the \"Hello\" at _all_. It's just \ngone (this is true even if the output was _more_ than a screen: try with\n\n\t(sleep 10 ; yes ) | less -F\n\nand resize the screen, and it will exit silently after 10 seconds - never \nshowing any output at all! Even though the output is obviously bigger than \na screen..\n\nTested with Kterm, gnome-terminal and xterm. They all behave the same for \nme.\n\nI don't know exactly what the bug is, but I find the \"eof\" handling very\nconfusing in the less sources. It makes me suspect that there is something \nthat gets confused by the partial read, sets EOF (since we're on the last \nline), and then thinks that it should quit, since EOF is set.\n\nI dunno. Mark?\n\n\t\tLinus\n"},{"id":"32454","messageId":"slrnercuc4.55u.siprbaum@xp.machine.xx","threadId":"6461","inReplyTo":"17846.27694.845530.663964@lisa.zopyra.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Peter Baumann","fromEmail":"siprbaum@stud.informatik.uni-erlangen.de","sentAt":"2007-01-23T21:09:24Z","receivedAt":"2007-01-23T21:09:24Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"Bill Lear schrieb:\n> On Tuesday, January 23, 2007 at 20:12:36 (+0100) Johannes Schindelin writes:\n>>Hi,\n>>\n>>On Tue, 23 Jan 2007, Bill Lear wrote:\n>>\n>>> I can't seem to get this to work, no matter what I do, using the latest \n>>> 1.5.0-rc2 code. I have the environment variables LESS, PAGER, \n>>> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my \n>>> screen each time it is run, no matter the combinations... Could someone \n>>> post the magic?\n>>\n>>Try this:\n>>\n>>\tPAGER=less LESS=-FRS git diff\n>\n> Replied to Johannes off-line and thought this was working --- sorry\n> for the false positive. It is in one regard: it completely suppresses\n> output if there is less than a full screen of output.\n>\n> If I do this:\n>\n> % export PAGER=less\n> % unset LESS\n> % git diff\n>\n> I get 30 lines of output in my current repository, as I should.\n>\n> If I then do this:\n>\n> % LESS=-FRS git diff\n>\n> I get nothing --- I do see a brief blink of output, but it's as if\n> less swallows it whole and I see nothing but the next prompt.\n>\n\nThis is propably caused by activating \"Enable Alternate Screen Switching\"\nin xterm. If you have this feature enabled, you get a clean screen (no\nfragments of the displayed file are shown after quitting less). Try to\ndisable it and see if it works.\n\n-Peter\n"},{"id":"32458","messageId":"17846.33824.555296.660115@lisa.zopyra.com","threadId":"6461","inReplyTo":"slrnercuc4.55u.siprbaum@xp.machine.xx","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-23T21:54:40Z","receivedAt":"2007-01-23T21:54:40Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Tuesday, January 23, 2007 at 22:09:24 (+0100) Peter Baumann writes:\n>Bill Lear schrieb:\n>>...\n>> If I do this:\n>>\n>> % export PAGER=less\n>> % unset LESS\n>> % git diff\n>>\n>> I get 30 lines of output in my current repository, as I should.\n>>\n>> If I then do this:\n>>\n>> % LESS=-FRS git diff\n>>\n>> I get nothing --- I do see a brief blink of output, but it's as if\n>> less swallows it whole and I see nothing but the next prompt.\n>>\n>\n>This is propably caused by activating \"Enable Alternate Screen Switching\"\n>in xterm. If you have this feature enabled, you get a clean screen (no\n>fragments of the displayed file are shown after quitting less). Try to\n>disable it and see if it works.\n\nTried as instructed: I get output when I should get output. However,\nwhen I should get no output, it clears/scrolls all the way down to the\nbottom of the screen (LESS=-FRS git diff).\n\n\nBill\n"},{"id":"32499","messageId":"20070124100628.GA7872@informatik.uni-freiburg.de","threadId":"6461","inReplyTo":"17846.28847.436225.732284@lisa.zopyra.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-01-24T10:06:28Z","receivedAt":"2007-01-24T10:06:28Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Bill Lear wrote:\n> On Tuesday, January 23, 2007 at 21:22:32 (+0100) Uwe Kleine-König writes:\n> >> % export PAGER=less\n> >> % unset LESS\n> >> % git diff\n> >> \n> >> I get 30 lines of output in my current repository, as I should.\n> >> \n> >> If I then do this:\n> >> \n> >> % LESS=-FRS git diff\n> >What about:\n> >\n> >\tLESS=-FRSX git diff\n> \n> Well, I see output when there is output to show, yes, but it still\n> blanks the screen --- or, I should say, scrolls all the way to the\n> bottom --- when there is no difference to show.\nAh, OK, now I got it. Sorry, I understood you wrong. Seems like\nsomething that needs fixing in less. At least I cannot find an option\nfor that. But I'm not sure that all people would consider that being a\nbug.\n\nBest regards\nUwe\n\n-- \nUwe Kleine-König\n\nhttp://www.google.com/search?q=72+PS+point+in+inch\n"},{"id":"32544","messageId":"45B79D68.6040200@greenwoodsoftware.com","threadId":"6461","inReplyTo":"Pine.LNX.4.64.0701231157430.32200@woody.linux-foundation.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Mark Nudelman","fromEmail":"markn@greenwoodsoftware.com","sentAt":"2007-01-24T17:54:48Z","receivedAt":"2007-01-24T17:54:48Z","isPatch":false,"sender":{"key":"markn@greenwoodsoftware.com","avatar":null},"body":"On 1/23/2007 12:32 PM, Linus Torvalds wrote:\n> I think \"less\" is actually seriously buggy with -F.\n> \n> There are two bugs:\n> \n> - it will always screw up the screen and move to the end. It does this \n> even if you use -FX which should disable any init sequences, so it's \n> not about that problem.\n> \n> - if you resize the terminal while less is waiting for input, less\n> will exit entirely without even showing the output. This is very\n> noticeable if you do something like \"git diff\" on a big and cold-cache \n> tree and git takes a few seconds to think, and then you resize the \n> window while it's preparing. Boom. No output AT ALL.\n> \n> Both bugs are easily seen with this simple command line\n> \n> \tclear ; (sleep 5 ; echo Hello) | less -F\n> \n> where you would EXPECT that the \"Hello\" would show up at the first line of \n> the screen (since we cleared the screen and moved to the top left corner), \n> but in fact it doesn't.\n> \n> And try resizing the terminal to make it bigger during the five-second \n> pause, and now you'll see less not show the \"Hello\" at _all_. It's just \n> gone (this is true even if the output was _more_ than a screen: try with\n> \n> \t(sleep 10 ; yes ) | less -F\n> \n> and resize the screen, and it will exit silently after 10 seconds - never \n> showing any output at all! Even though the output is obviously bigger than \n> a screen..\n> \n> Tested with Kterm, gnome-terminal and xterm. They all behave the same for \n> me.\n> \n> I don't know exactly what the bug is, but I find the \"eof\" handling very\n> confusing in the less sources. It makes me suspect that there is something \n> that gets confused by the partial read, sets EOF (since we're on the last \n> line), and then thinks that it should quit, since EOF is set.\n> \n> I dunno. Mark?\n> \n> \t\tLinus\n\n\nHi Linus,\n\nThe first issue that you mention (that we move to the bottom of the \nscreen before printing the first line) is behavior that has always \nexisted in less. It's not the init sequence that's doing it; less \ndeliberately moves to lowerleft before printing any output that is \nintended to go at the bottom of the screen, including both file data and \nthe prompt. This was a design decision from the first version of less, \nand I've never been brave enough to try to find all the places that \nwould be affected by changing this. For example, less tries to keep \ntrack of exactly what's displayed on the screen at all times, and it's \nharder to do this if we don't know whether some output scrolled the \nscreen or not. It may or may not be a big job to make all the changes \nthat would be required. I will move this up the priority list and take \na look at it for the next release of less.\n\nBTW, this issue is documented as enhancement request #112 at \nhttp://www.greenwoodsoftware.com/less/bugs.html.\n\nYour second issue is definitely a bug. Less's handling of -F and eof in \ngeneral is indeed rather baroque and confusing, and probably needs a \ncomplete revision. Some of the complexity comes from being portable to \nmany (not necessarily Unix-like) systems. But in this case, I think the \nearly exit is happening because less makes the decision about whether to \nquit due to -F based on the state of the input when the first prompt \noccurs. When less receives SIGWIND, it repaints the screen and \n*reprompts*. So if it gets this signal before the first screen is \ncompletely filled, it tries to prompt, somehow gets confused and thinks \nthat the partially filled screen is evidence of a short file, and exits. \n I will add this to the bug list and try to fix it in the next release.\n\n--Mark\n"},{"id":"32546","messageId":"Pine.LNX.4.64.0701241012030.3606@woody.linux-foundation.org","threadId":"6461","inReplyTo":"45B79D68.6040200@greenwoodsoftware.com","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-24T18:18:52Z","receivedAt":"2007-01-24T18:18:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 24 Jan 2007, Mark Nudelman wrote:\n>\n> The first issue that you mention (that we move to the bottom of the screen\n> before printing the first line) is behavior that has always existed in less.\n>\n> BTW, this issue is documented as enhancement request #112 at\n> http://www.greenwoodsoftware.com/less/bugs.html.\n\nI don't dispute that the \"move to the bottom of the screen\" is probably a \ngood feature in general, but it is _not_ a good feature when -F is in \neffect (similar to the init/exit sequence being a horrible thing to do \nwhen -F is in effect).\n\nSo the problem is that it basically makes -F largely useless.. The whole \n_point_ of anybody using -F is that it turns off the \"pager\" feature for \nsmall output that fits on a page, wouldn't you say?\n\n(The reason the init/exit sequence doesn't mix with -F is that many \nterminal descriptions basically have a \"switch to secondary screen\" for \ninit, and \"switch back\" for exit, which means that together with -F, small \noutput simply won't be shown at all - or perhaps it just flickers too \nquickly for the user to see it).\n\nSo this really is only a -F issue.\n\nNow, for the init/exit sequence, at least we have -X to turn that off (and \ngit does indeed default to using \"FRSX\" if the user doesn't have any LESS \nenvironment variable set), so perhaps the \"move to end of screen\" could \nalso get another flag? That way it would be something that users can \ncontrol - but see above on why I pretty much guarantee that anybody who \nuses -F would want to use the new flag too.\n\n> Your second issue is definitely a bug. Less's handling of -F and eof in\n> general is indeed rather baroque and confusing, and probably needs a complete\n> revision. Some of the complexity comes from being portable to many (not\n> necessarily Unix-like) systems.\n\nYeah, I tried to look at the sources, and ran awya screaming ;)\n\n\t\tLinus\n"},{"id":"32547","messageId":"Pine.LNX.4.64.0701241108370.3606@woody.linux-foundation.org","threadId":"6461","inReplyTo":"Pine.LNX.4.64.0701231157430.32200@woody.linux-foundation.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-24T19:21:10Z","receivedAt":"2007-01-24T19:21:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 23 Jan 2007, Linus Torvalds wrote:\n> \n> I think \"less\" is actually seriously buggy with -F.\n> \n> There are two bugs:\n> \n> - it will always screw up the screen and move to the end. It does this \n> even if you use -FX which should disable any init sequences, so it's \n> not about that problem.\n> \n> - if you resize the terminal while less is waiting for input, less\n> will exit entirely without even showing the output. This is very\n> noticeable if you do something like \"git diff\" on a big and cold-cache \n> tree and git takes a few seconds to think, and then you resize the \n> window while it's preparing. Boom. No output AT ALL.\n\nHeh. This extremely hacky patch works around the second bug.\n\nIt does so by simply adding a \"select()\" on the input before even starting \n\"less\", which will mean that by the time less starts, it always has \nsomething to read, and that in turn hides the bug with resizing the \nterminal window while less is waiting for input.\n\nI'm sure there's still a window for the bug to trigger, but I can no \nlonger trivially reproduce the problem any more.\n\n(The way to reproduce the problem is to do some pager operation that takes \na while in git, and resizing the window while git is thinking about the \noutput. I use\n\n\tgit diff --stat v2.6.12..\n\nin the kernel tree to do something where it takes a while for git to start \noutputting information)\n\nWithout this patch, I can easily just resize the window while git is \nthinking, and the end result is that \"less\" will exit early and indeed \nleave the tty in a broken state with no echo etc. With this patch, less \ndoesn't get confused.\n\nNOTE! To see this problem, you must use the LESS environment that git \nprovides by default (LESS=FRSX) and not have your own environment set that \noverrides the git ones (or if you do, it must have -F set).\n\nIs it ugly? Yes. Does it work? Yes. Do we want to apply it? You decide.\n\n\t\tLinus\n\n---\ndiff --git a/pager.c b/pager.c\nindex 4587fbb..5f280ab 100644\n--- a/pager.c\n+++ b/pager.c\n@@ -1,5 +1,7 @@\n #include \"cache.h\"\n \n+#include \n+\n /*\n * This is split up from the rest of git so that we might do\n * something different on Windows, for example.\n@@ -7,6 +9,16 @@\n \n static void run_pager(const char *pager)\n {\n+\t/*\n+\t * Work around bug in \"less\" by not starting it until we\n+\t * have real input\n+\t */\n+\tfd_set in;\n+\n+\tFD_ZERO(&in);\n+\tFD_SET(0, &in);\n+\tselect(1, &in, NULL, &in, NULL);\n+\n \texeclp(pager, pager, NULL);\n \texecl(\"/bin/sh\", \"sh\", \"-c\", pager, NULL);\n }\n"},{"id":"32572","messageId":"7vlkjsdn60.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"Pine.LNX.4.64.0701241108370.3606@woody.linux-foundation.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-24T23:23:35Z","receivedAt":"2007-01-24T23:23:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> NOTE! To see this problem, you must use the LESS environment that git \n> provides by default (LESS=FRSX) and not have your own environment set that \n> overrides the git ones (or if you do, it must have -F set).\n>\n> Is it ugly? Yes. Does it work? Yes. Do we want to apply it? You decide.\n\nI would not call it ugly.\n\nI once consiered to fork another process in between the pager\nand the caller here and make it buffer \"the first screenful\"\nbefore actually spawning the pager, or write out the short\noutput itself without spawning, to fix the \"no output but the\ncursor goes to the end\" problem. THAT's ugly.\n\nBut I do not think your patch is ugly, and it would help normal\npeople who work in a windowed environment (I did not see the\nneed for it myself since I usually never resize the terminal --\neven working inside X my terminals are usually fixed size and\nare always running \"screen\").\n"},{"id":"32580","messageId":"7v7ivbc3hj.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"Pine.LNX.4.64.0701231101040.3011@xanadu.home","subject":"[PATCH] fetch-pack: remove --keep-auto and make it the default.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-25T01:14:00Z","receivedAt":"2007-01-25T01:14:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This makes git-fetch over git native protocol to automatically\ndecide to keep the downloaded pack if the fetch results in more\nthan 100 objects, just like receive-pack invoked by git-push\ndoes. This logic is disabled when --keep is explicitly given\nfrom the command line, so that a very small clone still keeps\nthe downloaded pack as before.\n\nThe 100 threshold can be adjusted with fetch.unpacklimit\nconfiguration. We might want to introduce transfer.unpacklimit\nto consolidate the two unpacklimit variables, which will be a\ntopic for the next patch.\n\nSigned-off-by: Junio C Hamano \n---\n Nicolas Pitre writes:\n\n > On Tue, 23 Jan 2007, Johannes Schindelin wrote:\n >\n >> On Mon, 22 Jan 2007, Junio C Hamano wrote:\n >> \n >> > We may want to later make this the default.\n >> \n >> You have my vote for sooner rather than later.\n >\n > Seconded.\n >\n > Nicolas\n\n Ok, how about this, on top of the previous ones?\n\n Documentation/config.txt | 10 ++++++++++\n fetch-pack.c | 31 +++++++++++++++++--------------\n t/t5500-fetch-pack.sh | 3 ++-\n 3 files changed, 29 insertions(+), 15 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex d8244b1..383ff29 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -295,6 +295,16 @@ diff.renames::\n \twill enable basic rename detection. If set to \"copies\" or\n \t\"copy\", it will detect copies, as well.\n \n+fetch.unpackLimit::\n+\tIf the number of objects fetched over the git native\n+\ttransfer is below this\n+\tlimit, then the objects will be unpacked into loose object\n+\tfiles. However if the number of received objects equals or\n+\texceeds this limit then the received pack will be stored as\n+\ta pack, after adding any missing delta bases. Storing the\n+\tpack from a push can make the push operation complete faster,\n+\tespecially on slow filesystems.\n+\n format.headers::\n \tAdditional email headers to include in a patch to be submitted\n \tby mail. See gitlink:git-format-patch[1].\ndiff --git a/fetch-pack.c b/fetch-pack.c\nindex dd67e48..fc0534c 100644\n--- a/fetch-pack.c\n+++ b/fetch-pack.c\n@@ -8,7 +8,7 @@\n #include \"sideband.h\"\n \n static int keep_pack;\n-static int keep_auto;\n+static int unpack_limit = 100;\n static int quiet;\n static int verbose;\n static int fetch_all;\n@@ -503,14 +503,14 @@ static int get_pack(int xd[2])\n \n \tav = argv;\n \t*hdr_arg = 0;\n-\tif (keep_auto) {\n+\tif (unpack_limit) {\n \t\tstruct pack_header header;\n \n \t\tif (read_pack_header(fd[0], &header))\n \t\t\tdie(\"protocol error: bad pack header\");\n \t\tsnprintf(hdr_arg, sizeof(hdr_arg), \"--pack_header=%u,%u\",\n \t\t\t ntohl(header.hdr_version), ntohl(header.hdr_entries));\n-\t\tif (ntohl(header.hdr_entries) < keep_auto)\n+\t\tif (ntohl(header.hdr_entries) < unpack_limit)\n \t\t\tdo_keep = 0;\n \t\telse\n \t\t\tdo_keep = 1;\n@@ -523,7 +523,7 @@ static int get_pack(int xd[2])\n \t\t\t*av++ = \"-v\";\n \t\tif (use_thin_pack)\n \t\t\t*av++ = \"--fix-thin\";\n-\t\tif (keep_pack > 1 || keep_auto) {\n+\t\tif (keep_pack > 1 || unpack_limit) {\n \t\t\tint s = sprintf(keep_arg,\n \t\t\t\t\t\"--keep=fetch-pack %d on \", getpid());\n \t\t\tif (gethostname(keep_arg + s, sizeof(keep_arg) - s))\n@@ -642,6 +642,16 @@ static int remove_duplicates(int nr_heads, char **heads)\n \treturn dst;\n }\n \n+static int fetch_pack_config(const char *var, const char *value)\n+{\n+\tif (strcmp(var, \"fetch.unpacklimit\") == 0) {\n+\t\tunpack_limit = git_config_int(var, value);\n+\t\treturn 0;\n+\t}\n+\n+\treturn git_default_config(var, value);\n+}\n+\n static struct lock_file lock;\n \n int main(int argc, char **argv)\n@@ -653,6 +663,8 @@ int main(int argc, char **argv)\n \tstruct stat st;\n \n \tsetup_git_directory();\n+\tsetup_ident();\n+\tgit_config(fetch_pack_config);\n \n \tnr_heads = 0;\n \theads = NULL;\n@@ -674,16 +686,7 @@ int main(int argc, char **argv)\n \t\t\t}\n \t\t\tif (!strcmp(\"--keep\", arg) || !strcmp(\"-k\", arg)) {\n \t\t\t\tkeep_pack++;\n-\t\t\t\tcontinue;\n-\t\t\t}\n-\t\t\tif (!strcmp(\"--keep-auto\", arg)) {\n-\t\t\t\tkeep_auto = 100;\n-\t\t\t\tcontinue;\n-\t\t\t}\n-\t\t\tif (!strncmp(\"--keep-auto=\", arg, 12)) {\n-\t\t\t\tkeep_auto = strtoul(arg + 12, NULL, 0);\n-\t\t\t\tif (keep_auto < 20)\n-\t\t\t\t\tkeep_auto = 20;\n+\t\t\t\tunpack_limit = 0;\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t\tif (!strcmp(\"--thin\", arg)) {\ndiff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh\nindex ef78df6..7fd651b 100755\n--- a/t/t5500-fetch-pack.sh\n+++ b/t/t5500-fetch-pack.sh\n@@ -97,7 +97,8 @@ pull_to_client () {\n (\n \tmkdir client &&\n \tcd client &&\n-\tgit-init 2>> log2.txt\n+\tgit-init 2>> log2.txt &&\n+\tgit repo-config fetch.unpacklimit 0\n )\n \n add A1\n"},{"id":"32581","messageId":"7v1wljc3hb.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"Pine.LNX.4.64.0701231101040.3011@xanadu.home","subject":"[PATCH] Consolidate {receive,fetch}.unpackLimit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-25T01:14:08Z","receivedAt":"2007-01-25T01:14:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This allows transfer.unpackLimit to specify what these two\nconfiguration variables want to set.\n\nWe would probably want to deprecate the two separate variables,\nas I do not see much point in specifying them independently.\n\nSigned-off-by: Junio C Hamano \n---\n Documentation/config.txt | 5 +++++\n fetch-pack.c | 14 +++++++++++++-\n receive-pack.c | 24 ++++++++++++++++--------\n t/t5500-fetch-pack.sh | 2 +-\n 4 files changed, 35 insertions(+), 10 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 383ff29..8086d75 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -488,3 +488,8 @@ receive.denyNonFastForwards::\n \teven if that push is forced. This configuration variable is\n \tset when initializing a shared repository.\n \n+transfer.unpackLimit::\n+\tWhen `fetch.unpackLimit` or `receive.unpackLimit` are\n+\tnot set, the value of this variable is used instead.\n+\n+\ndiff --git a/fetch-pack.c b/fetch-pack.c\nindex fc0534c..83a1d7b 100644\n--- a/fetch-pack.c\n+++ b/fetch-pack.c\n@@ -8,6 +8,8 @@\n #include \"sideband.h\"\n \n static int keep_pack;\n+static int transfer_unpack_limit = -1;\n+static int fetch_unpack_limit = -1;\n static int unpack_limit = 100;\n static int quiet;\n static int verbose;\n@@ -645,7 +647,12 @@ static int remove_duplicates(int nr_heads, char **heads)\n static int fetch_pack_config(const char *var, const char *value)\n {\n \tif (strcmp(var, \"fetch.unpacklimit\") == 0) {\n-\t\tunpack_limit = git_config_int(var, value);\n+\t\tfetch_unpack_limit = git_config_int(var, value);\n+\t\treturn 0;\n+\t}\n+\n+\tif (strcmp(var, \"transfer.unpacklimit\") == 0) {\n+\t\ttransfer_unpack_limit = git_config_int(var, value);\n \t\treturn 0;\n \t}\n \n@@ -666,6 +673,11 @@ int main(int argc, char **argv)\n \tsetup_ident();\n \tgit_config(fetch_pack_config);\n \n+\tif (0 <= transfer_unpack_limit)\n+\t\tunpack_limit = transfer_unpack_limit;\n+\telse if (0 <= fetch_unpack_limit)\n+\t\tunpack_limit = fetch_unpack_limit;\n+\n \tnr_heads = 0;\n \theads = NULL;\n \tfor (i = 1; i < argc; i++) {\ndiff --git a/receive-pack.c b/receive-pack.c\nindex b3a4552..8b59b32 100644\n--- a/receive-pack.c\n+++ b/receive-pack.c\n@@ -10,6 +10,8 @@\n static const char receive_pack_usage[] = \"git-receive-pack \";\n \n static int deny_non_fast_forwards = 0;\n+static int receive_unpack_limit = -1;\n+static int transfer_unpack_limit = -1;\n static int unpack_limit = 100;\n static int report_status;\n \n@@ -18,21 +20,22 @@ static int capabilities_sent;\n \n static int receive_pack_config(const char *var, const char *value)\n {\n-\tgit_default_config(var, value);\n-\n-\tif (strcmp(var, \"receive.denynonfastforwards\") == 0)\n-\t{\n+\tif (strcmp(var, \"receive.denynonfastforwards\") == 0) {\n \t\tdeny_non_fast_forwards = git_config_bool(var, value);\n \t\treturn 0;\n \t}\n \n-\tif (strcmp(var, \"receive.unpacklimit\") == 0)\n-\t{\n-\t\tunpack_limit = git_config_int(var, value);\n+\tif (strcmp(var, \"receive.unpacklimit\") == 0) {\n+\t\treceive_unpack_limit = git_config_int(var, value);\n \t\treturn 0;\n \t}\n \n-\treturn 0;\n+\tif (strcmp(var, \"transfer.unpacklimit\") == 0) {\n+\t\ttransfer_unpack_limit = git_config_int(var, value);\n+\t\treturn 0;\n+\t}\n+\n+\treturn git_default_config(var, value);\n }\n \n static int show_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)\n@@ -431,6 +434,11 @@ int main(int argc, char **argv)\n \tignore_missing_committer_name();\n \tgit_config(receive_pack_config);\n \n+\tif (0 <= transfer_unpack_limit)\n+\t\tunpack_limit = transfer_unpack_limit;\n+\telse if (0 <= receive_unpack_limit)\n+\t\tunpack_limit = receive_unpack_limit;\n+\n \twrite_head_info();\n \n \t/* EOF */\ndiff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh\nindex 7fd651b..058cce0 100755\n--- a/t/t5500-fetch-pack.sh\n+++ b/t/t5500-fetch-pack.sh\n@@ -98,7 +98,7 @@ pull_to_client () {\n \tmkdir client &&\n \tcd client &&\n \tgit-init 2>> log2.txt &&\n-\tgit repo-config fetch.unpacklimit 0\n+\tgit repo-config transfer.unpacklimit 0\n )\n \n add A1\n-- \n1.5.0.rc2.gae1d\n"},{"id":"32584","messageId":"Pine.LNX.4.64.0701242231340.3011@xanadu.home","threadId":"6461","inReplyTo":"7v1wljc3hb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Consolidate {receive,fetch}.unpackLimit","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-25T03:32:49Z","receivedAt":"2007-01-25T03:32:49Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 24 Jan 2007, Junio C Hamano wrote:\n\n> This allows transfer.unpackLimit to specify what these two\n> configuration variables want to set.\n> \n> We would probably want to deprecate the two separate variables,\n> as I do not see much point in specifying them independently.\n\nWell... since they're already there and not hurting anything I would let \nthem live. Never know how they might be useful.\n\n\nNicolas\n"},{"id":"32589","messageId":"20070125051419.GB20345@spearce.org","threadId":"6461","inReplyTo":"7v1wljc3hb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Consolidate {receive,fetch}.unpackLimit","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-25T05:14:19Z","receivedAt":"2007-01-25T05:14:19Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> This allows transfer.unpackLimit to specify what these two\n> configuration variables want to set.\n> \n> We would probably want to deprecate the two separate variables,\n> as I do not see much point in specifying them independently.\n\nIndeed. I was going to fix this too, but reuse receive.unpackLimit.\nFrom my point of view both fetch and receive-pack are recieving\nobjects into this repository; and in either case I want the same\nbehavior with regards to loose object/pack management.\n\n-- \nShawn.\n"},{"id":"32592","messageId":"Pine.LNX.4.63.0701250922260.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"7v7ivbc3hj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-25T08:23:48Z","receivedAt":"2007-01-25T08:23:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 24 Jan 2007, Junio C Hamano wrote:\n\n> Ok, how about this, on top of the previous ones?\n\nThanks!\n\n> @@ -653,6 +663,8 @@ int main(int argc, char **argv)\n> \tstruct stat st;\n> \n> \tsetup_git_directory();\n> +\tsetup_ident();\n> +\tgit_config(fetch_pack_config);\n\nWhy do you need setup_ident()?\n\nCiao,\nDscho\n"},{"id":"32641","messageId":"7vejpiaj2f.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"Pine.LNX.4.63.0701250922260.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-25T21:32:40Z","receivedAt":"2007-01-25T21:32:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 24 Jan 2007, Junio C Hamano wrote:\n>\n>> Ok, how about this, on top of the previous ones?\n>\n> Thanks!\n>\n>> @@ -653,6 +663,8 @@ int main(int argc, char **argv)\n>> \tstruct stat st;\n>> \n>> \tsetup_git_directory();\n>> +\tsetup_ident();\n>> +\tgit_config(fetch_pack_config);\n>\n> Why do you need setup_ident()?\n\nBecause presumably you would be updating the reflog that records\nwho did the fetch?\n\nBut then we should do the same ignore_missing_committer_name()\nwe have in receive-pack to allow anonymous fetchers to fetch\nfrom outside world, I guess.\n"},{"id":"32664","messageId":"Pine.LNX.4.63.0701260045580.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6461","inReplyTo":"7vejpiaj2f.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-25T23:46:26Z","receivedAt":"2007-01-25T23:46:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Jan 2007, Junio C Hamano wrote:\n\n> > Why do you need setup_ident()?\n> \n> Because presumably you would be updating the reflog that records\n> who did the fetch?\n\nAh yes, that makes sense!\n\nThank you,\nDscho\n"},{"id":"32673","messageId":"7vhcue4heq.fsf@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"7vejpiaj2f.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-26T03:05:01Z","receivedAt":"2007-01-26T03:05:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Johannes Schindelin writes:\n>\n>> On Wed, 24 Jan 2007, Junio C Hamano wrote:\n>>\n>>> Ok, how about this, on top of the previous ones?\n>>\n>> Thanks!\n>>\n>>> @@ -653,6 +663,8 @@ int main(int argc, char **argv)\n>>> \tstruct stat st;\n>>> \n>>> \tsetup_git_directory();\n>>> +\tsetup_ident();\n>>> +\tgit_config(fetch_pack_config);\n>>\n>> Why do you need setup_ident()?\n>\n> Because presumably you would be updating the reflog that records\n> who did the fetch?\n>\n> But then we should do the same ignore_missing_committer_name()\n> we have in receive-pack to allow anonymous fetchers to fetch\n> from outside world, I guess.\n\nThis turns out to be more serious than I expected.\n\nThe code that uses committer_info() in reflog can barf and die.\nAnd I do not think calling ignore_missing_committer_name()\nupfront like recent receive-pack did in the aplication is a\nreasonable workaround.\n\nSo I am thinking about doing something like the attached patch.\n\nWhat the patch does.\n\n - git_committer_info() takes one parameter. It used to be \"if\n this is true, then die() if the name is not available due to\n bad GECOS, otherwise issue a warning once but leave the name\n empty\". The reason was because we wanted to prevent bad\n commits from being made by git-commit-tree (and its\n callers). The value 0 is only used by \"git var -l\". \n\n Now it takes -1, 0 or 1. When set to -1, it does not\n complain but uses the pw->pw_name when name is not\n available. Existing 0 and 1 values mean the same thing as\n they used to mean before. 0 means issue warnings and leave\n it empty, 1 means barf and die.\n\n - ignore_missing_committer_name() and its existing caller\n (receive-pack, to set the reflog) have been removed.\n\n - git-format-patch, to come up with the phoney message ID when\n asked to thread, now passes -1 to git_committer_info(). This\n codepath uses only the e-mail part, ignoring the name. It\n used to barf and die. The other call in the same program\n when asked to add signed-off-by line based on committer\n identity still passes 1 to make sure it barfs instead of\n adding a bogus s-o-b line.\n\n - log_ref_write in refs.c, to come up with the name to record\n who initiated the ref update in the reflog, passes -1. It\n used to barf and die.\n\nThe last change means that git-update-ref, git-branch, and\ncommit walker backends can now be used in a repository with\nreflog by somebody who does not have the user identity required\nto make a commit. They all used to barf and die.\n\nI've run tests and all of them seem to pass, and also tried \"git\nclone\" as a user whose GECOS is empty -- git clone works again\nnow (it was broken when reflog was enabled by default).\n\nBut this definitely needs extra sets of eyeballs.\n\n---\ndiff --git a/builtin-log.c b/builtin-log.c\nindex 503cd1e..56acc13 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -352,7 +352,7 @@ static void get_patch_ids(struct rev_info *rev, struct diff_options *options, co\n \n static void gen_message_id(char *dest, unsigned int length, char *base)\n {\n-\tconst char *committer = git_committer_info(1);\n+\tconst char *committer = git_committer_info(-1);\n \tconst char *email_start = strrchr(committer, '<');\n \tconst char *email_end = strrchr(committer, '>');\n \tif(!email_start || !email_end || email_start > email_end - 1)\ndiff --git a/cache.h b/cache.h\nindex 473197d..9486132 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -320,7 +320,6 @@ void datestamp(char *buf, int bufsize);\n unsigned long approxidate(const char *);\n \n extern int setup_ident(void);\n-extern void ignore_missing_committer_name(void);\n extern const char *git_author_info(int);\n extern const char *git_committer_info(int);\n \ndiff --git a/fetch-pack.c b/fetch-pack.c\nindex 4df7450..83a1d7b 100644\n--- a/fetch-pack.c\n+++ b/fetch-pack.c\n@@ -671,8 +671,6 @@ int main(int argc, char **argv)\n \n \tsetup_git_directory();\n \tsetup_ident();\n-\t/* don't die if gecos is empty */\n-\tignore_missing_committer_name();\n \tgit_config(fetch_pack_config);\n \n \tif (0 <= transfer_unpack_limit)\ndiff --git a/ident.c b/ident.c\nindex 6ad8fed..f967790 100644\n--- a/ident.c\n+++ b/ident.c\n@@ -180,12 +180,21 @@ static const char *get_ident(const char *name, const char *email,\n \t\temail = git_default_email;\n \n \tif (!*name) {\n-\t\tif (name == git_default_name && env_hint) {\n+\t\tstruct passwd *pw;\n+\n+\t\tif (0 <= error_on_no_name &&\n+\t\t name == git_default_name && env_hint) {\n \t\t\tfprintf(stderr, env_hint, au_env, co_env);\n \t\t\tenv_hint = NULL; /* warn only once, for \"git-var -l\" */\n \t\t}\n-\t\tif (error_on_no_name)\n+\t\tif (0 < error_on_no_name)\n \t\t\tdie(\"empty ident %s <%s> not allowed\", name, email);\n+\t\tpw = getpwuid(getuid());\n+\t\tif (!pw)\n+\t\t\tdie(\"You don't exist. Go away!\");\n+\t\tstrlcpy(git_default_name, pw->pw_name,\n+\t\t\tsizeof(git_default_name));\n+\t\tname = git_default_name;\n \t}\n \n \tstrcpy(date, git_default_date);\n@@ -218,18 +227,3 @@ const char *git_committer_info(int error_on_no_name)\n \t\t\t getenv(\"GIT_COMMITTER_DATE\"),\n \t\t\t error_on_no_name);\n }\n-\n-void ignore_missing_committer_name()\n-{\n-\t/* If we did not get a name from the user's gecos entry then\n-\t * git_default_name is empty; so instead load the username\n-\t * into it as a 'good enough for now' approximation of who\n-\t * this user is.\n-\t */\n-\tif (!*git_default_name) {\n-\t\tstruct passwd *pw = getpwuid(getuid());\n-\t\tif (!pw)\n-\t\t\tdie(\"You don't exist. Go away!\");\n-\t\tstrlcpy(git_default_name, pw->pw_name, sizeof(git_default_name));\n-\t}\n-}\ndiff --git a/receive-pack.c b/receive-pack.c\nindex 8b59b32..7d26326 100644\n--- a/receive-pack.c\n+++ b/receive-pack.c\n@@ -430,8 +430,6 @@ int main(int argc, char **argv)\n \t\tdie(\"attempt to push into a shallow repository\");\n \n \tsetup_ident();\n-\t/* don't die if gecos is empty */\n-\tignore_missing_committer_name();\n \tgit_config(receive_pack_config);\n \n \tif (0 <= transfer_unpack_limit)\ndiff --git a/refs.c b/refs.c\nindex 8117328..4323e9a 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -958,7 +958,7 @@ static int log_ref_write(struct ref_lock *lock,\n \t\t\t\t lock->log_file, strerror(errno));\n \t}\n \n-\tcommitter = git_committer_info(1);\n+\tcommitter = git_committer_info(-1);\n \tif (msg) {\n \t\tmaxlen = strlen(committer) + strlen(msg) + 2*40 + 5;\n \t\tlogrec = xmalloc(maxlen);\n"},{"id":"32675","messageId":"7v1wli4g8h.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6461","inReplyTo":"7vhcue4heq.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Allow non-developer to clone, checkout and fetch easier.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-26T03:30:22Z","receivedAt":"2007-01-26T03:30:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The code that uses committer_info() in reflog can barf and die\nwhenever it is asked to update a ref. And I do not think\ncalling ignore_missing_committer_name() upfront like recent\nreceive-pack did in the aplication is a reasonable workaround.\n\nWhat the patch does.\n\n - git_committer_info() takes one parameter. It used to be \"if\n this is true, then die() if the name is not available due to\n bad GECOS, otherwise issue a warning once but leave the name\n empty\". The reason was because we wanted to prevent bad\n commits from being made by git-commit-tree (and its\n callers). The value 0 is only used by \"git var -l\".\n\n Now it takes -1, 0 or 1. When set to -1, it does not\n complain but uses the pw->pw_name when name is not\n available. Existing 0 and 1 values mean the same thing as\n they used to mean before. 0 means issue warnings and leave\n it empty, 1 means barf and die.\n\n - ignore_missing_committer_name() and its existing caller\n (receive-pack, to set the reflog) have been removed.\n\n - git-format-patch, to come up with the phoney message ID when\n asked to thread, now passes -1 to git_committer_info(). This\n codepath uses only the e-mail part, ignoring the name. It\n used to barf and die. The other call in the same program\n when asked to add signed-off-by line based on committer\n identity still passes 1 to make sure it barfs instead of\n adding a bogus s-o-b line.\n\n - log_ref_write in refs.c, to come up with the name to record\n who initiated the ref update in the reflog, passes -1. It\n used to barf and die.\n\nThe last change means that git-update-ref, git-branch, and\ncommit walker backends can now be used in a repository with\nreflog by somebody who does not have the user identity required\nto make a commit. They all used to barf and die.\n\nI've run tests and all of them seem to pass, and also tried \"git\nclone\" as a user whose GECOS is empty -- git clone works again\nnow (it was broken when reflog was enabled by default).\n\nBut this definitely needs extra sets of eyeballs.\n\nSigned-off-by: Junio C Hamano \n---\n\n * Here is an updated patch -- the previous one was on top of\n what was never committed, and was useless.\n\n builtin-log.c | 2 +-\n cache.h | 1 -\n ident.c | 28 +++++++++++-----------------\n receive-pack.c | 2 --\n refs.c | 2 +-\n 5 files changed, 13 insertions(+), 22 deletions(-)\n\ndiff --git a/builtin-log.c b/builtin-log.c\nindex 503cd1e..56acc13 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -352,7 +352,7 @@ static void get_patch_ids(struct rev_info *rev, struct diff_options *options, co\n \n static void gen_message_id(char *dest, unsigned int length, char *base)\n {\n-\tconst char *committer = git_committer_info(1);\n+\tconst char *committer = git_committer_info(-1);\n \tconst char *email_start = strrchr(committer, '<');\n \tconst char *email_end = strrchr(committer, '>');\n \tif(!email_start || !email_end || email_start > email_end - 1)\ndiff --git a/cache.h b/cache.h\nindex 473197d..9486132 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -320,7 +320,6 @@ void datestamp(char *buf, int bufsize);\n unsigned long approxidate(const char *);\n \n extern int setup_ident(void);\n-extern void ignore_missing_committer_name(void);\n extern const char *git_author_info(int);\n extern const char *git_committer_info(int);\n \ndiff --git a/ident.c b/ident.c\nindex 6ad8fed..f967790 100644\n--- a/ident.c\n+++ b/ident.c\n@@ -180,12 +180,21 @@ static const char *get_ident(const char *name, const char *email,\n \t\temail = git_default_email;\n \n \tif (!*name) {\n-\t\tif (name == git_default_name && env_hint) {\n+\t\tstruct passwd *pw;\n+\n+\t\tif (0 <= error_on_no_name &&\n+\t\t name == git_default_name && env_hint) {\n \t\t\tfprintf(stderr, env_hint, au_env, co_env);\n \t\t\tenv_hint = NULL; /* warn only once, for \"git-var -l\" */\n \t\t}\n-\t\tif (error_on_no_name)\n+\t\tif (0 < error_on_no_name)\n \t\t\tdie(\"empty ident %s <%s> not allowed\", name, email);\n+\t\tpw = getpwuid(getuid());\n+\t\tif (!pw)\n+\t\t\tdie(\"You don't exist. Go away!\");\n+\t\tstrlcpy(git_default_name, pw->pw_name,\n+\t\t\tsizeof(git_default_name));\n+\t\tname = git_default_name;\n \t}\n \n \tstrcpy(date, git_default_date);\n@@ -218,18 +227,3 @@ const char *git_committer_info(int error_on_no_name)\n \t\t\t getenv(\"GIT_COMMITTER_DATE\"),\n \t\t\t error_on_no_name);\n }\n-\n-void ignore_missing_committer_name()\n-{\n-\t/* If we did not get a name from the user's gecos entry then\n-\t * git_default_name is empty; so instead load the username\n-\t * into it as a 'good enough for now' approximation of who\n-\t * this user is.\n-\t */\n-\tif (!*git_default_name) {\n-\t\tstruct passwd *pw = getpwuid(getuid());\n-\t\tif (!pw)\n-\t\t\tdie(\"You don't exist. Go away!\");\n-\t\tstrlcpy(git_default_name, pw->pw_name, sizeof(git_default_name));\n-\t}\n-}\ndiff --git a/receive-pack.c b/receive-pack.c\nindex 8b59b32..7d26326 100644\n--- a/receive-pack.c\n+++ b/receive-pack.c\n@@ -430,8 +430,6 @@ int main(int argc, char **argv)\n \t\tdie(\"attempt to push into a shallow repository\");\n \n \tsetup_ident();\n-\t/* don't die if gecos is empty */\n-\tignore_missing_committer_name();\n \tgit_config(receive_pack_config);\n \n \tif (0 <= transfer_unpack_limit)\ndiff --git a/refs.c b/refs.c\nindex 8117328..4323e9a 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -958,7 +958,7 @@ static int log_ref_write(struct ref_lock *lock,\n \t\t\t\t lock->log_file, strerror(errno));\n \t}\n \n-\tcommitter = git_committer_info(1);\n+\tcommitter = git_committer_info(-1);\n \tif (msg) {\n \t\tmaxlen = strlen(committer) + strlen(msg) + 2*40 + 5;\n \t\tlogrec = xmalloc(maxlen);\n-- \n1.5.0.rc2.g1b55\n"},{"id":"32692","messageId":"45B9BDBB.E9C65371@eudaptics.com","threadId":"6461","inReplyTo":"7vejpiaj2f.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-01-26T08:37:15Z","receivedAt":"2007-01-26T08:37:15Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano wrote:\n> \n> Johannes Schindelin writes:\n> \n> > On Wed, 24 Jan 2007, Junio C Hamano wrote:\n> >\n> >> Ok, how about this, on top of the previous ones?\n> >\n> > Thanks!\n> >\n> >> @@ -653,6 +663,8 @@ int main(int argc, char **argv)\n> >> struct stat st;\n> >>\n> >> setup_git_directory();\n> >> + setup_ident();\n> >> + git_config(fetch_pack_config);\n> >\n> > Why do you need setup_ident()?\n> \n> Because presumably you would be updating the reflog that records\n> who did the fetch?\n> \n> But then we should do the same ignore_missing_committer_name()\n> we have in receive-pack to allow anonymous fetchers to fetch\n> from outside world, I guess.\n\nInstead of using ignore_missing_committer_name(), use\nget_committer_info(0) in refs.c. cherry-pick 4feaf032d3 from my tree at\ngit://repo.or.cz/git/mingw.git if you want.\n\nAlthough this approach leaves the name+email in the reflog entry empty\ninstead of writing \"unkown\"...\n\n-- Hannes\n"},{"id":"32738","messageId":"81b0412b0701260620v31feedecwfe0565ee846253a9@mail.gmail.com","threadId":"6461","inReplyTo":"7v1wli4g8h.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Allow non-developer to clone, checkout and fetch easier.","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-26T14:20:30Z","receivedAt":"2007-01-26T14:20:30Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/26/07, Junio C Hamano wrote:\n> The code that uses committer_info() in reflog can barf and die\n> whenever it is asked to update a ref. And I do not think\n> calling ignore_missing_committer_name() upfront like recent\n> receive-pack did in the aplication is a reasonable workaround.\n>\n> What the patch does.\n>\n> - git_committer_info() takes one parameter. It used to be \"if\n> this is true, then die() if the name is not available due to\n> bad GECOS, otherwise issue a warning once but leave the name\n> empty\". The reason was because we wanted to prevent bad\n> commits from being made by git-commit-tree (and its\n> callers). The value 0 is only used by \"git var -l\".\n>\n> Now it takes -1, 0 or 1. When set to -1, it does not\n> complain but uses the pw->pw_name when name is not\n> available. Existing 0 and 1 values mean the same thing as\n> they used to mean before. 0 means issue warnings and leave\n> it empty, 1 means barf and die.\n\n enum {\n CMITR_INFO_PW_NAME = -1,\n CMITR_INFO_EMPTY = 0,\n CMITR_INFO_DIE = 1,\n };\n\n- const char *committer = git_committer_info(CMITR_INFO_DIE);\n+ const char *committer = git_committer_info(CMITR_INFO_PW_NAME);\n\nThe code becoming increasingly harder to read, doesn't it...\n"},{"id":"38094","messageId":"4608605B.7050105@greenwoodsoftware.com","threadId":"6461","inReplyTo":"Pine.LNX.4.64.0701231157430.32200@woody.linux-foundation.org","subject":"Re: [Announce] GIT v1.5.0-rc2","fromName":"Mark Nudelman","fromEmail":"markn@greenwoodsoftware.com","sentAt":"2007-03-27T00:07:55Z","receivedAt":"2007-03-27T00:07:55Z","isPatch":false,"sender":{"key":"markn@greenwoodsoftware.com","avatar":null},"body":"Hi all,\nI'm not sure if you are still interested in this, but I have posted a \nbeta release of less (less-401) which I believe fixes both of these \nproblems. See http://www.greenwoodsoftware.com/less. If you try it, \nlet me know how it works for you.\n\n--Mark\n\n\nOn 1/23/2007 12:32 PM, Linus Torvalds wrote:\n> [ Added \"less\" author Mark Nudelman to Cc: ]\n> \n> On Tue, 23 Jan 2007, Bill Lear wrote:\n>> I can't seem to get this to work, no matter what I do, using the\n>> latest 1.5.0-rc2 code. I have the environment variables LESS, PAGER,\n>> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through\n>> my screen each time it is run, no matter the combinations... Could\n>> someone post the magic?\n> \n> I think \"less\" is actually seriously buggy with -F.\n> \n> There are two bugs:\n> \n> - it will always screw up the screen and move to the end. It does this \n> even if you use -FX which should disable any init sequences, so it's \n> not about that problem.\n> \n> - if you resize the terminal while less is waiting for input, less\n> will exit entirely without even showing the output. This is very\n> noticeable if you do something like \"git diff\" on a big and cold-cache \n> tree and git takes a few seconds to think, and then you resize the \n> window while it's preparing. Boom. No output AT ALL.\n> \n> Both bugs are easily seen with this simple command line\n> \n> \tclear ; (sleep 5 ; echo Hello) | less -F\n> \n> where you would EXPECT that the \"Hello\" would show up at the first line of \n> the screen (since we cleared the screen and moved to the top left corner), \n> but in fact it doesn't.\n> \n> And try resizing the terminal to make it bigger during the five-second \n> pause, and now you'll see less not show the \"Hello\" at _all_. It's just \n> gone (this is true even if the output was _more_ than a screen: try with\n> \n> \t(sleep 10 ; yes ) | less -F\n> \n> and resize the screen, and it will exit silently after 10 seconds - never \n> showing any output at all! Even though the output is obviously bigger than \n> a screen..\n> \n> Tested with Kterm, gnome-terminal and xterm. They all behave the same for \n> me.\n> \n> I don't know exactly what the bug is, but I find the \"eof\" handling very\n> confusing in the less sources. It makes me suspect that there is something \n> that gets confused by the partial read, sets EOF (since we're on the last \n> line), and then thinks that it should quit, since EOF is set.\n> \n> I dunno. Mark?\n> \n> \t\tLinus\n> \n"}]}