{"thread":{"id":"9741","subject":"[ANNOUNCE] GIT 1.5.3","startedAt":"2007-09-02T06:31:17Z","lastAt":"2007-09-03T13:17:29Z","messageCount":35,"participants":["Junio C Hamano","H. Peter Anvin","David Kastrup","Arkadiusz Miskiewicz","Alex Riesen","Johannes Schindelin","Nicolas Vilz","Sean","David Kågedal","Steven Grimm","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"52166","messageId":"7vodglr32i.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":null,"subject":"[ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-02T06:31:17Z","receivedAt":"2007-09-02T06:31:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The latest feature release GIT 1.5.3 is available at the usual\nplaces:\n\n http://www.kernel.org/pub/software/scm/git/\n\n git-1.5.3.tar.{gz,bz2}\t\t\t(tarball)\n git-htmldocs-1.5.3.tar.{gz,bz2}\t\t(preformatted docs)\n git-manpages-1.5.3.tar.{gz,bz2}\t\t(preformatted docs)\n RPMS/$arch/git-*-1.5.3-1.$arch.rpm\t(RPM)\n\nGIT v1.5.3 Release Notes\n========================\n\nUpdates since v1.5.2\n--------------------\n\n* The commit walkers other than http are officially deprecated,\n but still supported for now.\n\n* The submodule support has Porcelain layer.\n\n Note that the current submodule support is minimal and this is\n deliberately so. A design decision we made is that operations\n at the supermodule level do not recurse into submodules by\n default. The expectation is that later we would add a\n mechanism to tell git which submodules the user is interested\n in, and this information might be used to determine the\n recursive behaviour of certain commands (e.g. \"git checkout\"\n and \"git diff\"), but currently we haven't agreed on what that\n mechanism should look like. Therefore, if you use submodules,\n you would probably need \"git submodule update\" on the\n submodules you care about after running a \"git checkout\" at\n the supermodule level.\n\n* There are a handful pack-objects changes to help you cope better\n with repositories with pathologically large blobs in them.\n\n* For people who need to import from Perforce, a front-end for\n fast-import is in contrib/fast-import/.\n\n* Comes with git-gui 0.8.2.\n\n* Comes with updated gitk.\n\n* New commands and options.\n\n - \"git log --date=\" can use more formats: iso8601, rfc2822.\n\n - The hunk header output from \"git diff\" family can be customized\n with the attributes mechanism. See gitattributes(5) for details.\n\n - \"git stash\" allows you to quickly save away your work in\n progress and replay it later on an updated state.\n\n - \"git rebase\" learned an \"interactive\" mode that let you\n pick and reorder which commits to rebuild.\n\n - \"git fsck\" can save its findings in $GIT_DIR/lost-found, without a\n separate invocation of \"git lost-found\" command. The blobs stored by\n lost-found are stored in plain format to allow you to grep in them.\n\n - $GIT_WORK_TREE environment variable can be used together with\n $GIT_DIR to work in a subdirectory of a working tree that is\n not located at \"$GIT_DIR/..\".\n\n - Giving \"--file=\" option to \"git config\" is the same as\n running the command with GIT_CONFIG= environment.\n\n - \"git log\" learned a new option \"--follow\", to follow\n renaming history of a single file.\n\n - \"git filter-branch\" lets you rewrite the revision history of\n specified branches. You can specify a number of filters to\n modify the commits, files and trees.\n\n - \"git cvsserver\" learned new options (--base-path, --export-all,\n --strict-paths) inspired by \"git daemon\".\n\n - \"git daemon --base-path-relaxed\" can help migrating a repository URL\n that did not use to use --base-path to use --base-path.\n\n - \"git commit\" can use \"-t templatefile\" option and commit.template\n configuration variable to prime the commit message given to you in the\n editor.\n\n - \"git submodule\" command helps you manage the projects from\n the superproject that contain them.\n\n - In addition to core.compression configuration option,\n core.loosecompression and pack.compression options can\n independently tweak zlib compression levels used for loose\n and packed objects.\n\n - \"git ls-tree -l\" shows size of blobs pointed at by the\n tree entries, similar to \"/bin/ls -l\".\n\n - \"git rev-list\" learned --regexp-ignore-case and\n --extended-regexp options to tweak its matching logic used\n for --grep fitering.\n\n - \"git describe --contains\" is a handier way to call more\n obscure command \"git name-rev --tags\".\n\n - \"git gc --aggressive\" tells the command to spend more cycles\n to optimize the repository harder.\n\n - \"git repack\" learned a \"window-memory\" limit which\n dynamically reduces the window size to stay within the\n specified memory usage.\n\n - \"git repack\" can be told to split resulting packs to avoid\n exceeding limit specified with \"--max-pack-size\".\n\n - \"git fsck\" gained --verbose option. This is really really\n verbose but it might help you identify exact commit that is\n corrupt in your repository.\n\n - \"git format-patch\" learned --numbered-files option. This\n may be useful for MH users.\n\n - \"git format-patch\" learned format.subjectprefix configuration\n variable, which serves the same purpose as \"--subject-prefix\"\n option.\n\n - \"git tag -n -l\" shows tag annotations while listing tags.\n\n - \"git cvsimport\" can optionally use the separate-remote layout.\n\n - \"git blame\" can be told to see through commits that change\n whitespaces and indentation levels with \"-w\" option.\n\n - \"git send-email\" can be told not to thread the messages when\n sending out more than one patches.\n\n - \"git send-email\" can also be told how to find whom to cc the\n message to for each message via --cc-cmd.\n\n - \"git config\" learned NUL terminated output format via -z to\n help scripts.\n\n - \"git add\" learned \"--refresh ...\" option to selectively refresh\n the cached stat information.\n\n - \"git init -q\" makes the command quieter.\n\n - \"git -p command\" now has a cousin of opposite sex, \"git --no-pager\n command\".\n\n* Updated behavior of existing commands.\n\n - \"gitweb\" can offer multiple snapshot formats.\n\n ***NOTE*** Unfortunately, this changes the format of the\n $feature{snapshot}{default} entry in the per-site\n configuration file 'gitweb_config.perl'. It used to be a\n three-element tuple that describe a single format; with the\n new configuration item format, you only have to say the name\n of the format ('tgz', 'tbz2' or 'zip'). Please update the\n your configuration file accordingly.\n\n - \"git clone\" uses -l (hardlink files under .git) by default when\n cloning locally.\n\n - URL used for \"git clone\" and friends can specify nonstandard SSH port\n by using sh://host:port/path/to/repo syntax.\n\n - \"git bundle create\" can now create a bundle without negative refs,\n i.e. \"everything since the beginning up to certain points\".\n\n - \"git diff\" (but not the plumbing level \"git diff-tree\") now\n recursively descends into trees by default.\n\n - \"git diff\" does not show differences that come only from\n stat-dirtiness in the form of \"diff --git\" header anymore.\n It runs \"update-index --refresh\" silently as needed.\n\n - \"git tag -l\" used to match tags by globbing its parameter as if it\n has wildcard '*' on both ends, which made \"git tag -l gui\" to match\n tag 'gitgui-0.7.0'; this was very annoying. You now have to add\n asterisk on the sides you want to wildcard yourself.\n\n - The editor to use with many interactive commands can be\n overridden with GIT_EDITOR environment variable, or if it\n does not exist, with core.editor configuration variable. As\n before, if you have neither, environment variables VISUAL\n and EDITOR are consulted in this order, and then finally we\n fall back on \"vi\".\n\n - \"git rm --cached\" does not complain when removing a newly\n added file from the index anymore.\n\n - Options to \"git log\" to affect how --grep/--author options look for\n given strings now have shorter abbreviations. -i is for ignore case,\n and -E is for extended regexp.\n\n - \"git log\" learned --log-size to show the number of bytes in\n the log message part of the output to help qgit.\n\n - \"git log --name-status\" does not require you to give \"-r\" anymore.\n As a general rule, Porcelain commands should recurse when showing\n diff.\n\n - \"git format-patch --root A\" can be used to format everything\n since the beginning up to A. This was supported with\n \"git format-patch --root A A\" for a long time, but was not\n properly documented.\n\n - \"git svn dcommit\" retains local merge information.\n\n - \"git svnimport\" allows an empty string to be specified as the\n trunk/ directory. This is necessary to suck data from a SVN\n repository that doe not have trunk/ branches/ and tags/ organization\n at all.\n\n - \"git config\" to set values also honors type flags like --bool\n and --int.\n\n - core.quotepath configuration can be used to make textual git\n output to emit most of the characters in the path literally.\n\n - \"git mergetool\" chooses its backend more wisely, taking\n notice of its environment such as use of X, Gnome/KDE, etc.\n\n - \"gitweb\" shows merge commits a lot nicer than before. The\n default view uses more compact --cc format, while the UI\n allows to choose normal diff with any parent.\n\n - snapshot files \"gitweb\" creates from a repository at\n $path/$project/.git are more useful. We use $project part\n in the filename, which we used to discard.\n\n - \"git cvsimport\" creates lightweight tags; there is no\n interesting information we can record in an annotated tag,\n and the handcrafted ones the old code created was not\n properly formed anyway.\n\n - \"git push\" pretends that you immediately fetched back from\n the remote by updating corresponding remote tracking\n branches if you have any.\n\n - The diffstat given after a merge (or a pull) honors the\n color.diff configuration.\n\n - \"git commit --amend\" is now compatible with various message source\n options such as -m/-C/-c/-F.\n\n - \"git apply --whitespace=strip\" removes blank lines added at\n the end of the file.\n\n - \"git fetch\" over git native protocols with \"-v\" option shows\n connection status, and the IP address of the other end, to\n help diagnosing problems.\n\n - We used to have core.legacyheaders configuration, when\n set to false, allowed git to write loose objects in a format\n that mimicks the format used by objects stored in packs. It\n turns out that this was not so useful. Although we will\n continue to read objects written in that format, we do not\n honor that configuration anymore and create loose objects in\n the legacy/traditional format.\n\n - \"--find-copies-harder\" option to diff family can now be\n spelled as \"-C -C\" for brevity.\n\n - \"git mailsplit\" (hence \"git am\") can read from Maildir\n formatted mailboxes.\n\n - \"git cvsserver\" does not barf upon seeing \"cvs login\"\n request.\n\n - \"pack-objects\" honors \"delta\" attribute set in\n .gitattributes. It does not attempt to deltify blobs that\n come from paths with delta attribute set to false.\n\n - \"new-workdir\" script (in contrib) can now be used with a\n bare repository.\n\n - \"git mergetool\" learned to use gvimdiff.\n\n - \"gitview\" (in contrib) has a better blame interface.\n\n - \"git log\" and friends did not handle a commit log message\n that is larger than 16kB; they do now.\n\n - \"--pretty=oneline\" output format for \"git log\" and friends\n deals with \"malformed\" commit log messages that have more\n than one lines in the first paragraph better. We used to\n show the first line, cutting the title at mid-sentence; we\n concatenate them into a single line and treat the result as\n \"oneline\".\n\n - \"git p4import\" has been demoted to contrib status. For\n a superior option, checkout the \"git p4\" front end to\n \"git fast-import\" (also in contrib). The man page and p4\n rpm have been removed as well.\n\n - \"git mailinfo\" (hence \"am\") now tries to see if the message\n is in utf-8 first, instead of assuming iso-8859-1, if\n incoming e-mail does not say what encoding it is in.\n\n* Builds\n\n - old-style function definitions (most notably, a function\n without parameter defined with \"func()\", not \"func(void)\")\n have been eradicated.\n\n - \"git tag\" and \"git verify-tag\" have been rewritten in C.\n\n* Performance Tweaks\n\n - \"git pack-objects\" avoids re-deltification cost by caching\n small enough delta results it creates while looking for the\n best delta candidates.\n\n - \"git pack-objects\" learned a new heuristcs to prefer delta\n that is shallower in depth over the smallest delta\n possible. This improves both overall packfile access\n performance and packfile density.\n\n - diff-delta code that is used for packing has been improved\n to work better on big files.\n\n - when there are more than one pack files in the repository,\n the runtime used to try finding an object always from the\n newest packfile; it now tries the same packfile as we found\n the object requested the last time, which exploits the\n locality of references.\n\n - verifying pack contents done by \"git fsck --full\" got boost\n by carefully choosing the order to verify objects in them.\n\n - \"git read-tree -m\" to read into an already populated index\n has been optimized vastly. The effect of this can be seen\n when switching branches that have differences in only a\n handful paths.\n\n - \"git add paths...\" and \"git commit paths...\" has also been\n heavily optimized.\n\nFixes since v1.5.2\n------------------\n\nAll of the fixes in v1.5.2 maintenance series are included in\nthis release, unless otherwise noted.\n\n* Bugfixes\n\n - \"gitweb\" had trouble handling non UTF-8 text with older\n Encode.pm Perl module.\n\n - \"git svn\" misparsed the data from the commits in the repository when\n the user had \"color.diff = true\" in the configuration. This has been\n fixed.\n\n - There was a case where \"git svn dcommit\" clobbered changes made on the\n SVN side while committing multiple changes.\n\n - \"git-write-tree\" had a bad interaction with racy-git avoidance and\n gitattributes mechanisms.\n\n - \"git --bare command\" overrode existing GIT_DIR setting and always\n made it treat the current working directory as GIT_DIR.\n\n - \"git ls-files --error-unmatch\" does not complain if you give the\n same path pattern twice by mistake.\n\n - \"git init\" autodetected core.filemode but not core.symlinks, which\n made a new directory created automatically by \"git clone\" cumbersome\n to use on filesystems that require these configurations to be set.\n\n - \"git log\" family of commands behaved differently when run as \"git\n log\" (no pathspec) and as \"git log --\" (again, no pathspec). This\n inconsistency was introduced somewhere in v1.3.0 series but now has\n been corrected.\n\n - \"git rebase -m\" incorrectly displayed commits that were skipped.\n\n----------------------------------------------------------------\n\nShortlog since v1.5.2.5 is too long, so I'll list just the names\nof contributors here and thank everybody.\n\nAdam Roben: 5\nAlberto Bertogli: 1\nAlecs King: 1\nAlexandre Julliard: 9\nAlexandre Vassalotti: 1\nAlex Riesen: 27\nAndrew Ruder: 2\nAndy Whitcroft: 3\nAneesh Kumar K.V: 2\nArjen Laarhoven: 2\nBenjamin Sergeant: 1\nBradford C. Smith: 2\nBrian Downing: 13\nBrian Gernhardt: 5\nBrian Hetro: 5\nCarlos Rica: 13\nChristian Stimming: 1\nCJ van den Berg: 1\nDana L. How: 8\nDaniel Barkalow: 8\nDan McGee: 1\nDave O'Neill: 1\nDave Watson: 1\nDavid Kågedal: 1\nDavid Kastrup: 16\nDavid Soria Parra: 1\nDavid Symonds: 1\nElvis Pranskevichus: 1\nEmil Medve: 2\nEric Wong: 11\nFernando J. Pereda: 1\nFrancis Moreau: 1\nFrank Lichtenheld: 12\nGeert Bosch: 1\nGerrit Pape: 5\nGiuseppe Bilotta: 2\nGreg KH: 1\nHan-Wen Nienhuys: 30\nIsmail Dönmez: 1\nJakub Narebski: 27\nJames Bowes: 3\nJari Aalto: 1\nJ. Bruce Fields: 9\nJeff King: 14\nJeffrey C. Ollie: 2\nJens Axboe: 1\nJim Meyering: 6\nJoe Perches: 1\nJohan Herland: 1\nJohannes Schindelin: 77\nJohannes Sixt: 14\nJonas Fonseca: 3\nJon Loeliger: 1\nJosh Triplett: 2\nJulian Phillips: 3\nJunio C Hamano: 160\nJyotirmoy Bhattacharya: 1\nKevin Green: 1\nKristian Høgsberg: 1\nKumar Gala: 1\nLars Hjemli: 12\nLinus Torvalds: 21\nLuben Tuikov: 1\nLuiz Fernando N. Capitulino: 3\nLukas Sandström: 1\nMarco Costalba: 3\nMarcus Fritzsch: 1\nMarius Storm-Olsen: 8\nMark Levedahl: 13\nmartin f. krafft: 2\nMartin Koegler: 5\nMartin Waitz: 1\nMatthias Lederhofer: 21\nMatthieu Moy: 2\nMatthijs Melchior: 1\nMatt Kraai: 3\nMatt McCutchen: 4\nMichael Ellerman: 2\nMichael Hendricks: 2\nMichael Krelin: 1\nMichael S. Tsirkin: 1\nMike Hommey: 2\nMiklos Vajna: 2\nMiles Bader: 1\nNanako Shiraishi: 5\nNguyễn Thái Ngọc Duy: 1\nNicolas Pitre: 14\nPaul Mackerras: 37\nPeter Hagervall: 1\nPetr Baudis: 6\nPierre Habouzit: 3\nQuy Tonthat: 2\nRandal L. Schwartz: 2\nReece H. Dunn: 1\nRené Scharfe: 10\nRichard MUSIL: 1\nRobert Ewald: 1\nRobert Schiele: 2\nRobin Rosenberg: 5\nSam Vilain: 3\nScott Lamb: 2\nSean Estabrooks: 6\nSeth Falcon: 1\nShawn O. Pearce: 140\nSimon Hausmann: 231\nStefan Sperling: 1\nSteffen Prohaska: 3\nStephen Rothwell: 1\nSteve Hoelzer: 3\nSteven Grimm: 4\nSteven Walter: 1\nSven Verdoolaege: 7\nTheodore Ts'o: 4\nThomas Schwinge: 2\nTom Clarke: 1\nUwe Kleine-König: 5\nVäinö Järvelä: 1\n"},{"id":"52167","messageId":"7vk5r9r2xk.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"7vodglr32i.fsf@gitster.siamese.dyndns.org","subject":"A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-02T06:34:15Z","receivedAt":"2007-09-02T06:34:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Now a new feature release is out, it's a good time to welcome new\npeople to the list. This message talks about how git.git is managed,\nand how you can work with it.\n\n* IRC and Mailing list\n\nMany active members of development community hang around on #git\nIRC channel on Freenode. Its log is available at:\n\n http://colabti.de/irclogger/irclogger_log/git\n\nThe development however is primarily done on this mailing list\nyou are reading right now. If you have patches, please send\nthem to the list, following Documentation/SubmittingPatches.\n\nI usually try to read all patches posted to the list, and follow\nalmost all the discussions on the list, unless the topic is about an\nobscure corner that I do not personally use. But I am obviously not\nperfect. If you sent a patch that you did not hear from anybody for\nthree days, that is a very good indication that it was dropped on the\nfloor --- please do not hesitate to remind me.\n\nThe list archive is available at a few public sites as well:\n\n http://marc.theaimsgroup.com/?l=git\n http://news.gmane.org/gmane.comp.version-control.git\n\thttp://www.spinics.net/lists/git/\n\nand some people seem to prefer to read it over NNTP:\n\n nntp://news.gmane.org/gmane.comp.version-control.git\n\n* Repositories, branches and documentation.\n\nMy public git.git repository is at:\n\n git://git.kernel.org/pub/scm/git/git.git/\n\nImmediately after I publish to the primary repository at kernel.org, I\nalso push into an alternate here:\n\n git://repo.or.cz/alt-git.git/\n\nImpatient people might have better luck with the latter one.\n\nTheir gitweb interfaces are found at:\n\n\thttp://git.kernel.org/?p=git/git.git\n\thttp://repo.or.cz/w/alt-git.git\n\nThere are three branches in git.git repository that are not\nabout the source tree of git: \"todo\", \"html\" and \"man\". The\nfirst one was meant to contain TODO list for me, but I am not\ngood at maintaining such a list so it is not as often updated as\nit could/should be. It also contains some helper scripts I use\nto maintain git.\n\nThe \"html\" and \"man\" are autogenerated documentation from the\ntip of the \"master\" branch; the tip of \"html\" is extracted to be\nvisible at kernel.org at:\n\n http://www.kernel.org/pub/software/scm/git/docs/\n\nThe above URL is the top-level documentation page, and it has\nlinks to documentation of older releases.\n\nThe script to maintain these two documentation branches are\nfound in \"todo\" branch as dodoc.sh, if you are interested. It\nis a good demonstration of how to use an update hook to automate\na task.\n\nThere are four branches in git.git repository that track the\nsource tree of git: \"master\", \"maint\", \"next\", and \"pu\". I may\nadd more maintenance branches (e.g. \"maint-1.5.1\") if we have\nhuge backward incompatible feature updates in the future to keep\nan older release alive; I may not, but the distributed nature of\ngit means any volunteer can run a stable-tree like that himself.\n\nThe \"master\" branch is meant to contain what are very well\ntested and ready to be used in a production setting. There\ncould occasionally be minor breakages or brown paper bag bugs\nbut they are not expected to be anything major. Every now and\nthen, a \"feature release\" is cut from the tip of this branch and\nthey typically are named with three dotted decimal digits. The\nlast such release was v1.5.3 done on Sep 2nd this year. You\ncan expect that the tip of the \"master\" branch is always as\nstable as any of the released versions, if not more stable.\n\nWhenever a feature release is made, \"maint\" branch is forked off\nfrom \"master\" at that point. Obvious, safe and urgent fixes\nafter a feature release are applied to this branch and\nmaintenance releases are cut from it. The maintenance releases\nare named with four dotted decimal, named after the feature\nrelease they are updates to; the last such release was v1.5.2.5.\nNew features never go to this branch. This branch is also\nmerged into \"master\" to propagate the fixes forward.\n\nA trivial and safe enhancement goes directly on top of \"master\".\nA new development, either initiated by myself or more often by\nsomebody who found his or her own itch to scratch, does not\nusually happen on \"master\", however. Instead, a separate topic\nbranch is forked from the tip of \"master\", and it first is\ntested in isolation; I may make minimum fixups at this point.\nUsually there are a handful such topic branches that are running\nahead of \"master\" in git.git repository. I do not publish the\ntip of these branches in my public repository, however, partly\nto keep the number of branches that downstream developers need\nto worry about low, and primarily because I am lazy.\n\nI judge the quality of topic branches, taking advices from the\nmailing list discussions. Some of them start out as \"good idea\nbut obviously is broken in some areas (e.g. breaks the existing\ntestsuite)\" and then with some more work (either by the original\ncontributor or help from other people on the list) becomes \"more\nor less done and can now be tested by wider audience\". Luckily,\nmost of them start out in the latter, better shape.\n\nThe \"next\" branch is to merge and test topic branches in the\nlatter category. In general, the branch always contains the tip\nof \"master\". It might not be quite rock-solid production ready,\nbut is expected to work more or less without major breakage. I\nusually use \"next\" version of git for my own work, so it cannot\nbe _that_ broken to prevent me from pushing the changes out.\nThe \"next\" branch is where new and exciting things take place.\nNote that being in \"next\" does not mean the change will be in\nthe next feature release.\n\nThe above three branches, \"master\", \"maint\" and \"next\" are never\nrewound, so you should be able to safely track them (this\nautomatically means the topics that have been merged into \"next\"\nare not rebased, and you can find the tip of topic branches you\nare interested in from the output of \"git log next\").\n\nThe \"pu\" (proposed updates) branch bundles all the remainder of\ntopic branches. The \"pu\" branch, and topic branches that are\nonly in \"pu\", are subject to rebasing in general. By the above\ndefinition of how \"next\" works, you can tell that this branch\nwill contain quite experimental and obviously broken stuff.\n\nWhen a topic that was in \"pu\" proves to be in testable shape, it\ngraduates to \"next\". I do this with:\n\n git checkout next\n git merge that-topic-branch\n\nSometimes, an idea that looked promising turns out to be not so\ngood and the topic can be dropped from \"pu\" in such a case.\n\nA topic that is in \"next\" is expected to be tweaked and fixed to\nperfection before it is merged to \"master\" (that's why \"master\"\ncan be expected to stay very stable). Similarly to the above, I\ndo it with this:\n\n git checkout master\n git merge that-topic-branch\n git branch -d that-topic-branch\n\nHowever, being in \"next\" is not a guarantee to appear in the\nnext release (being in \"master\" is such a guarantee, unless it\nis later found seriously broken and reverted), or even in any\nfuture release. There even were cases that topics needed\nreverting a few commits in them before graduating to \"master\",\nor a topic that already was in \"next\" were entirely reverted\nfrom \"next\" because fatal flaws were found in them later.\n\nStarting from v1.5.0, \"master\" and \"maint\" have release notes\nfor the next release in Documentation/RelNotes-* files, so that\nI do not have to run around summarizing what happened just\nbefore the release.\n\n\n* Other people's trees, trusted lieutenants and credits.\n\nDocumentation/SubmittingPatches outlines who your changes should\nbe sent to. As described in contrib/README, I would delegate\nfixes and enhancements in contrib/ area to primary contributors\nof them.\n\nAlthough the following are included in git.git repository, they\nhave their own authoritative repository and maintainers:\n\n git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui\n project, which is found at:\n\n git://repo.or.cz/git-gui.git\n\n gitk -- this file is maintained by Paul Mackerras, at:\n\n git://git.kernel.org/pub/scm/gitk/gitk.git\n\nI would like to thank everybody who helped to raise git into the\ncurrent shape. Especially I would like to thank the git list\nregulars whose help I have relied on and expect to continue\nrelying on heavily:\n\n - Linus on general design issues.\n\n - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, and\n Rene Scharfe on general implementation issues.\n\n - Shawn and Nicolas Pitre on pack issues.\n\n - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.\n\n - Paul Mackerras on gitk.\n\n - Eric Wong on git-svn.\n\n - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.\n\n - J. Bruce Fields on documentaton issues.\n\n - Johannes Schindelin and Johannes Sixt for their effort to\n move things forward on the Windows front. Although my\n repository does not have much from the effort of MinGW team,\n I expect a merge into mainline will happen so that everybody\n can work from the same codebase.\n\n - People on non-Linux platforms for keeping their eyes on\n portability; especially, Randal Schwartz, Theodore Ts'o,\n Jason Riedy, Thomas Glanzmann, but countless others as well.\n\n* This document\n\nThe latest copy of this document is found in git.git repository,\non 'todo' branch, as MaintNotes.\n"},{"id":"52170","messageId":"46DA5F33.2020005@zytor.com","threadId":"9741","inReplyTo":"7vodglr32i.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-09-02T06:58:59Z","receivedAt":"2007-09-02T06:58:59Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> * For people who need to import from Perforce, a front-end for\n> fast-import is in contrib/fast-import/.\n> \n\nThere seems to be an issue with this and RPMS.\n\nIn particular, there is no longer a git-p4 RPMS, which prevents git from \ngetting upgraded at all by yum.\n\nAnyone who knows yum well enough to explain what needs to be done so \nthat yum knows this is obsolete?\n\n\t-hpa\n"},{"id":"52172","messageId":"85642tv91c.fsf@lola.goethe.zz","threadId":"9741","inReplyTo":"7vodglr32i.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-02T07:08:47Z","receivedAt":"2007-09-02T07:08:47Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> The latest feature release GIT 1.5.3 is available at the usual\n> places:\n>\n> http://www.kernel.org/pub/software/scm/git/\n>\n> git-1.5.3.tar.{gz,bz2}\t\t\t(tarball)\n> git-htmldocs-1.5.3.tar.{gz,bz2}\t\t(preformatted docs)\n> git-manpages-1.5.3.tar.{gz,bz2}\t\t(preformatted docs)\n> RPMS/$arch/git-*-1.5.3-1.$arch.rpm\t(RPM)\n>\n> GIT v1.5.3 Release Notes\n> ========================\n\nInitial info doc support might have been mentioned. While it is not\nreally something to write home about yet, the mention might draw\npeople willing to work on it, like providing indexing tags or muscling\nAsciiDoc into including manpages in an appendix (both of which would\nalso benefit the Docbook output). Well, something for the 1.5.4\nrelease announcement. Sorry for overlooking this before the actual\nannouncement.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"52175","messageId":"7vr6lhpkh4.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"46DA5F33.2020005@zytor.com","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-02T07:58:15Z","receivedAt":"2007-09-02T07:58:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> Junio C Hamano wrote:\n>>\n>> * For people who need to import from Perforce, a front-end for\n>> fast-import is in contrib/fast-import/.\n>\n> There seems to be an issue with this and RPMS.\n>\n> In particular, there is no longer a git-p4 RPMS, which prevents git\n> from getting upgraded at all by yum.\n>\n> Anyone who knows yum well enough to explain what needs to be done so\n> that yum knows this is obsolete?\n\nGeez. Is this only about upgrading, or is initial install also\naffected?\n"},{"id":"52176","messageId":"85odgltrtj.fsf@lola.goethe.zz","threadId":"9741","inReplyTo":"46DA5F33.2020005@zytor.com","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-02T08:06:00Z","receivedAt":"2007-09-02T08:06:00Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> Junio C Hamano wrote:\n>>\n>> * For people who need to import from Perforce, a front-end for\n>> fast-import is in contrib/fast-import/.\n>>\n>\n> There seems to be an issue with this and RPMS.\n>\n> In particular, there is no longer a git-p4 RPMS, which prevents git\n> from getting upgraded at all by yum.\n>\n> Anyone who knows yum well enough to explain what needs to be done so\n> that yum knows this is obsolete?\n\nProbably a matter of the correct spec file. In auctex.spec, we have\n\nSummary: \tEnhanced TeX modes for Emacsen\nName: \t\tauctex\nVersion: \t11.84\nRelease: \t1%{distri}\nLicense: \tGPL\nGroup: \t\t%{commongroup}\nURL: \t\thttp://www.gnu.org/software/auctex/\nSource0: ftp://ftp.gnu.org/pub/gnu/auctex/%{name}-%{version}.tar.gz\nBuildArchitectures: noarch\nBuildRoot: \t%{_tmppath}/%{name}-root\n\n%description\nAUCTeX is [...]\n\n%package emacs\nSummary: \tEnhanced TeX modes for GNU Emacs\nGroup: %{commongroup}\nRequires: \temacs >= 21\nObsoletes: ge_auc emacs-auctex auctex preview-latex-emacs\nConflicts: emacspeak < 18\nProvides: auctex\n\n\nSo auctex-emacs obsoletes the previous \"auctex\" package and some other\npackages. It also provides \"auctex\" since some other packages might\nrequire it.\n\nBasically, you need to provide everything that a third-party package\nmight have asked for, and you need to obsolete everything that you\nintend to replace.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"52179","messageId":"fbdt3q$lcf$1@sea.gmane.org","threadId":"9741","inReplyTo":"7vodglr32i.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Arkadiusz Miskiewicz","fromEmail":"arekm@pld-linux.org","sentAt":"2007-09-02T08:43:38Z","receivedAt":"2007-09-02T08:43:38Z","isPatch":false,"sender":{"key":"arekm@pld-linux.org","avatar":null},"body":"Junio C Hamano wrote:\n\n> The latest feature release GIT 1.5.3 is available at the usual\n> places:\n\nHm,\n\n/usr/bin/make -C t/ all\nmake[1]: Entering directory `/home/users/arekm/rpm/BUILD/git-1.5.3/t'\n*** t0000-basic.sh ***\n* ok 1: .git/objects should be empty after git init in an empty repo.\n* ok 2: .git/objects should have 3 subdirectories.\n* ok 3: git update-index without --add should fail adding.\n* ok 4: git update-index with --add should succeed.\n* ok 5: writing tree out with git write-tree\n* ok 6: validate object ID of a known tree.\n* ok 7: git update-index without --remove should fail removing.\n* ok 8: git update-index with --remove should be able to remove.\n* ok 9: git write-tree should be able to write an empty tree.\n* ok 10: validate object ID of a known tree.\n* ok 11: adding various types of objects with git update-index --add.\n* ok 12: showing stage with git ls-files --stage\n* ok 13: validate git ls-files output for a known tree.\n* ok 14: writing tree out with git write-tree.\n* ok 15: validate object ID for a known tree.\n* ok 16: showing tree with git ls-tree\n* ok 17: git ls-tree output for a known tree.\n* ok 18: showing tree with git ls-tree -r\n* ok 19: git ls-tree -r output for a known tree.\n* ok 20: showing tree with git ls-tree -r -t\n* ok 21: git ls-tree -r output for a known tree.\n* ok 22: writing partial tree out with git write-tree --prefix.\n* ok 23: validate object ID for a known tree.\n* ok 24: writing partial tree out with git write-tree --prefix.\n* ok 25: validate object ID for a known tree.\n* ok 26: put invalid objects into the index.\n* ok 27: writing this tree without --missing-ok.\n* ok 28: writing this tree with --missing-ok.\n* ok 29: git read-tree followed by write-tree should be idempotent.\n* ok 30: validate git diff-files output for a know cache/work tree state.\n* ok 31: git update-index --refresh should succeed.\n* ok 32: no diff after checkout and git update-index --refresh.\n* ok 33: git commit-tree records the correct tree in a commit.\n* ok 34: git commit-tree records the correct parent in a commit.\n* ok 35: git commit-tree omits duplicated parent in a commit.\n* ok 36: update-index D/F conflict\n* ok 37: absolute path works as expected\n* passed all 37 test(s)\n*** t0001-init.sh ***\n* FAIL 1: plain\n\n (\n unset GIT_DIR GIT_WORK_TREE &&\n mkdir plain &&\n cd plain &&\n git init\n ) &&\n check_config plain/.git false unset\n\n* ok 2: plain with GIT_WORK_TREE\n* FAIL 3: plain bare\n\n (\n unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&\n mkdir plain-bare-1 &&\n cd plain-bare-1 &&\n git --bare init\n ) &&\n check_config plain-bare-1 true unset\n\n* ok 4: plain bare with GIT_WORK_TREE\n* ok 5: GIT_DIR bare\n* ok 6: GIT_DIR non-bare\n* ok 7: GIT_DIR & GIT_WORK_TREE (1)\n* ok 8: GIT_DIR & GIT_WORK_TREE (2)\n* failed 2 among 8 test(s)\nmake[1]: *** [t0001-init.sh] Error 1\nmake[1]: Leaving directory `/home/users/arekm/rpm/BUILD/git-1.5.3/t'\n\nverified on 2 machines (so /dev/ is ok this time)\n\n-- \nArkadiusz Miśkiewicz PLD/Linux Team\narekm / maven.pl http://ftp.pld-linux.org/\n"},{"id":"52182","messageId":"46DA88EF.7080103@zytor.com","threadId":"9741","inReplyTo":"85odgltrtj.fsf@lola.goethe.zz","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-09-02T09:57:03Z","receivedAt":"2007-09-02T09:57:03Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"David Kastrup wrote:\n> \"H. Peter Anvin\" writes:\n> \n>> Junio C Hamano wrote:\n>>> * For people who need to import from Perforce, a front-end for\n>>> fast-import is in contrib/fast-import/.\n>>>\n>> There seems to be an issue with this and RPMS.\n>>\n>> In particular, there is no longer a git-p4 RPMS, which prevents git\n>> from getting upgraded at all by yum.\n>>\n>> Anyone who knows yum well enough to explain what needs to be done so\n>> that yum knows this is obsolete?\n> \n> Probably a matter of the correct spec file. In auctex.spec, we have\n> \n\n From the looks of it, there is still a git-p4, it just moved to contrib \nand uses fast-import, so removing its rpm package was probably broken in \nthe first place.\n\n\"make rpm\" is also broken for \"dirty\" builds, which is bad for testing.\n\n\t-hpa\n"},{"id":"52184","messageId":"20070902102800.GA11473@steel.home","threadId":"9741","inReplyTo":"fbdt3q$lcf$1@sea.gmane.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-09-02T10:28:00Z","receivedAt":"2007-09-02T10:28:00Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Arkadiusz Miskiewicz, Sun, Sep 02, 2007 10:43:38 +0200:\n> *** t0001-init.sh ***\n> * FAIL 1: plain\n> \n> (\n> unset GIT_DIR GIT_WORK_TREE &&\n> mkdir plain &&\n> cd plain &&\n> git init\n> ) &&\n> check_config plain/.git false unset\n> \n> * ok 2: plain with GIT_WORK_TREE\n> * FAIL 3: plain bare\n> \n> (\n> unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&\n> mkdir plain-bare-1 &&\n> cd plain-bare-1 &&\n> git --bare init\n> ) &&\n> check_config plain-bare-1 true unset\n> \n\nDo you have bash-2.05b as /bin/sh ?\n"},{"id":"52186","messageId":"Pine.LNX.4.64.0709021157120.28586@racer.site","threadId":"9741","inReplyTo":"fbdt3q$lcf$1@sea.gmane.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-02T10:59:04Z","receivedAt":"2007-09-02T10:59:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 2 Sep 2007, Arkadiusz Miskiewicz wrote:\n\n> Junio C Hamano wrote:\n> \n> > The latest feature release GIT 1.5.3 is available at the usual\n> > places:\n> \n> Hm,\n> \n> [...]\n>\n> *** t0001-init.sh ***\n> * FAIL 1: plain\n> \n> (\n> unset GIT_DIR GIT_WORK_TREE &&\n> mkdir plain &&\n> cd plain &&\n> git init\n> ) &&\n> check_config plain/.git false unset\n\nPlease try the verbose mode: cd t/ && sh t0001-init.sh -i -v. If that \ndoes not show you _what_ the problem is, try \"sh -x [...]\".\n\nIf you still cannot find what the problem is, please tell us what platform \nyou're running on, and show us the output of the \"-i -v\" invocation.\n\nCiao,\nDscho\n"},{"id":"52188","messageId":"20070902111937.GB11473@steel.home","threadId":"9741","inReplyTo":"Pine.LNX.4.64.0709021157120.28586@racer.site","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-09-02T11:19:37Z","receivedAt":"2007-09-02T11:19:37Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Sun, Sep 02, 2007 12:59:04 +0200:\n> Hi,\n> \n> On Sun, 2 Sep 2007, Arkadiusz Miskiewicz wrote:\n> \n> > Junio C Hamano wrote:\n> > \n> > > The latest feature release GIT 1.5.3 is available at the usual\n> > > places:\n> > \n> > Hm,\n> > \n> > [...]\n> >\n> > *** t0001-init.sh ***\n> > * FAIL 1: plain\n> > \n> > (\n> > unset GIT_DIR GIT_WORK_TREE &&\n> > mkdir plain &&\n> > cd plain &&\n> > git init\n> > ) &&\n> > check_config plain/.git false unset\n> \n> Please try the verbose mode: cd t/ && sh t0001-init.sh -i -v. If that \n> does not show you _what_ the problem is, try \"sh -x [...]\".\n\nif that is buggy bash-2.05b the problem will just disappear.\n\nI don't remember what it was when I first met this, but it seemed to be\nvery specific to this particular version of bash.\n"},{"id":"52193","messageId":"fbeanj$mfq$1@sea.gmane.org","threadId":"9741","inReplyTo":"Pine.LNX.4.64.0709021157120.28586@racer.site","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Arkadiusz Miskiewicz","fromEmail":"arekm@pld-linux.org","sentAt":"2007-09-02T12:36:02Z","receivedAt":"2007-09-02T12:36:02Z","isPatch":false,"sender":{"key":"arekm@pld-linux.org","avatar":null},"body":"Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Sun, 2 Sep 2007, Arkadiusz Miskiewicz wrote:\n> \n>> Junio C Hamano wrote:\n>> \n>> > The latest feature release GIT 1.5.3 is available at the usual\n>> > places:\n>> \n>> Hm,\n>> \n>> [...]\n>>\n>> *** t0001-init.sh ***\n>> * FAIL 1: plain\n>> \n>> (\n>> unset GIT_DIR GIT_WORK_TREE &&\n>> mkdir plain &&\n>> cd plain &&\n>> git init\n>> ) &&\n>> check_config plain/.git false unset\n> \n> Please try the verbose mode: cd t/ && sh t0001-init.sh -i -v. If that\n> does not show you _what_ the problem is, try \"sh -x [...]\".\n> \n> If you still cannot find what the problem is, please tell us what platform\n> you're running on, and show us the output of the \"-i -v\" invocation.\n\nFound out why this happens. My /bin/sh is pdksh (not bash).\n\nAAAA was never set and:\n\n/bin/sh (pdksh)\n[arekm@carme-pld ~]$ unset AAAA\n[arekm@carme-pld ~]$ echo $?\n1\n\n/bin/bash\n[arekm@carme-pld ~]$ unset AAAA\n[arekm@carme-pld ~]$ echo $?\n0\n\nIt's pdksh bug, susv3 says \"Unsetting a variable or function that was not\npreviously set shall not be considered an error and does not cause the\nshell to abort.\"\n\nGoing to fix pdksh then.\n\n> Ciao,\n> Dscho\n\n-- \nArkadiusz Miśkiewicz PLD/Linux Team\narekm / maven.pl http://ftp.pld-linux.org/\n"},{"id":"52209","messageId":"20070902151229.GB6501@amy.inscure.wireless.home.vilz.de","threadId":"9741","inReplyTo":"7vodglr32i.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Nicolas Vilz","fromEmail":"niv@iaglans.de","sentAt":"2007-09-02T15:12:29Z","receivedAt":"2007-09-02T15:12:29Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"On Sat, Sep 01, 2007 at 11:31:17PM -0700, Junio C Hamano wrote:\n> - URL used for \"git clone\" and friends can specify nonstandard SSH port\n> by using sh://host:port/path/to/repo syntax.\n\nSorry, but could this be a typo and should be \n\n by using ssh://host:port/path/to/repo syntax.\n ^^^ \n\n\nSincerly\nNicolas\n"},{"id":"52241","messageId":"20070902133803.1b46f599.seanlkml@sympatico.ca","threadId":"9741","inReplyTo":"46DA88EF.7080103@zytor.com","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-09-02T17:38:03Z","receivedAt":"2007-09-02T17:38:03Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 02 Sep 2007 10:57:03 +0100\n\"H. Peter Anvin\" wrote:\n\n> From the looks of it, there is still a git-p4, it just moved to contrib \n> and uses fast-import, so removing its rpm package was probably broken in \n> the first place.\n\nHi Peter,\n\nItems in contrib aren't officially supported, so it doesn't sound like\na good idea to offer installs for them. Of course, it might be a good\nidea to promote git-p4 up out of contrib and add it to the spec file.\n\nAs things stand now, do you get an error when trying to upgrade Git via\nyum? I'd have thought things would upgrade fine but leave the old git-p4\nrpm hanging around. Either way, the obsoletes line mentioned by David\nsounds like the right solution.\n\nAs an aside, when I sent the patch removing git-p4import from the spec\nfile I mentioned that I had no way to test it and asked for testers.\nGit needs a spec file maintainer so that issues like this can be caught\nbefore release. Without a maintainer, it should probably be demoted\nto contrib itself.\n\nSean\n"},{"id":"52266","messageId":"7v4picpvgq.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"20070902133803.1b46f599.seanlkml@sympatico.ca","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-02T22:13:09Z","receivedAt":"2007-09-02T22:13:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean writes:\n\n> On Sun, 02 Sep 2007 10:57:03 +0100\n> \"H. Peter Anvin\" wrote:\n>\n>> From the looks of it, there is still a git-p4, it just moved to contrib \n>> and uses fast-import, so removing its rpm package was probably broken in \n>> the first place.\n> ...\n> As an aside, when I sent the patch removing git-p4import from the spec\n> file I mentioned that I had no way to test it and asked for testers.\n> Git needs a spec file maintainer so that issues like this can be caught\n> before release. Without a maintainer, it should probably be demoted\n> to contrib itself.\n\nFor majority of general public, I thought the spec file _I_\nship, along with RPM files _I_ build, are contrib status\nalready. Don't distro people do their own RPM packages, instead\nof using what I placed on k.org?\n\nAssuming that we do not give the old git-p4import script\npackaged in \"git-p4 package\", would the following patch be all\nthat is needed, or do we need other things in the spec file?\n\n-- snipsnap clipcrap --\n\ndiff --git a/git.spec.in b/git.spec.in\nindex fe7b3d8..3d56e17 100644\n--- a/git.spec.in\n+++ b/git.spec.in\n@@ -13,6 +13,7 @@ Source: \thttp://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz\n BuildRequires:\tzlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}\n BuildRoot:\t%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)\n Requires:\tgit-core, git-svn, git-cvs, git-arch, git-email, gitk, git-gui, perl-Git\n+Obsoletes:\tgit-p4\n \n %description\n Git is a fast, scalable, distributed revision control system with an\n"},{"id":"52269","messageId":"87hcmcfzo9.fsf@morpheus.local","threadId":"9741","inReplyTo":"7vodglr32i.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-09-02T22:52:22Z","receivedAt":"2007-09-02T22:52:22Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Junio C Hamano writes:\n\n> GIT v1.5.3 Release Notes\n> ========================\n>\n> Updates since v1.5.2\n> --------------------\n>\n> * The commit walkers other than http are officially deprecated,\n> but still supported for now.\n\nAs I think I said before, this first bullet point makes no sense to\ngit users. Only hardcore git developers know what a \"commit walker\nis\", and what commit walkers exist (other than html, obviously). How\nwill they know if they are using one of the things you just\ndeprecated?\n\n-- \nDavid Kågedal\n"},{"id":"52270","messageId":"87d4x0fzky.fsf@morpheus.local","threadId":"9741","inReplyTo":"87hcmcfzo9.fsf@morpheus.local","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-09-02T22:54:21Z","receivedAt":"2007-09-02T22:54:21Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"David Kågedal writes:\n\n> Junio C Hamano writes:\n>\n>> GIT v1.5.3 Release Notes\n>> ========================\n>>\n>> Updates since v1.5.2\n>> --------------------\n>>\n>> * The commit walkers other than http are officially deprecated,\n>> but still supported for now.\n>\n> As I think I said before, this first bullet point makes no sense to\n> git users. Only hardcore git developers know what a \"commit walker\n> is\", and what commit walkers exist (other than html, obviously). How\n\nI'm not trying to make you even more confused. Make that \"http\",\nplease. :-)\n\n> will they know if they are using one of the things you just\n> deprecated?\n\n-- \nDavid Kågedal\n"},{"id":"52273","messageId":"20070902191644.29d46cd2.seanlkml@sympatico.ca","threadId":"9741","inReplyTo":"7v4picpvgq.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-09-02T23:16:44Z","receivedAt":"2007-09-02T23:16:44Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 02 Sep 2007 15:13:09 -0700\nJunio C Hamano wrote:\n\nHi Junio,\n\n> For majority of general public, I thought the spec file _I_\n> ship, along with RPM files _I_ build, are contrib status\n> already. Don't distro people do their own RPM packages, instead\n> of using what I placed on k.org?\n\nDidn't know you used RPM yourself, so I guess this is just\na case of something slipping through rather than the spec file\nneeding a maintainer. Having said that, it seems odd that you\nwould say the spec file included with git is \"contrib status\nalready\". How can something be contrib status unless it\nis in the contrib directory of Git?\n \n> Assuming that we do not give the old git-p4import script\n> packaged in \"git-p4 package\", would the following patch be all\n> that is needed, or do we need other things in the spec file?\n\nGiven the comment from David, I suspect your patch is all\nthat's needed; hopefully Peter can give it a quick test.\n\nSean\n"},{"id":"52274","messageId":"7vveasode8.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"87d4x0fzky.fsf@morpheus.local","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-02T23:28:47Z","receivedAt":"2007-09-02T23:28:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kågedal writes:\n\n> David Kågedal writes:\n>\n>> Junio C Hamano writes:\n>>\n>>> GIT v1.5.3 Release Notes\n>>> ========================\n>>>\n>>> Updates since v1.5.2\n>>> --------------------\n>>>\n>>> * The commit walkers other than http are officially deprecated,\n>>> but still supported for now.\n>>\n>> As I think I said before, this first bullet point makes no sense to\n>> git users. Only hardcore git developers know what a \"commit walker\n>> is\", and what commit walkers exist (other than html, obviously). How\n>\n> I'm not trying to make you even more confused. Make that \"http\",\n> please. :-)\n\nUnless you work extremely hard at it, you won't be using the\nlocal and/or ssh walkers. The entry is really meant for\nPorcelain writers (aka plumbing users).\n\nIt's a tricky balancing act. Not everybody is the end user who\nis only interested in using Porcelain. The release note for a\nnew release somehow needs to mention changes that would affect\nonly plumbing users as well.\n"},{"id":"52275","messageId":"46DB4903.6060100@midwinter.com","threadId":"9741","inReplyTo":"7vveasode8.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-09-02T23:36:35Z","receivedAt":"2007-09-02T23:36:35Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> It's a tricky balancing act. Not everybody is the end user who\n> is only interested in using Porcelain. The release note for a\n> new release somehow needs to mention changes that would affect\n> only plumbing users as well.\n> \n\nNo argument there, of course; it needs to be documented. But maybe not \nas the very first item at the top of the release notes, which people \nmight expect to be organized in a \"most user-visible first\" order. I \nusually expect to see general descriptions of new features and critical \nbugfixes at the top of a program's release notes, with the option to \nkeep reading if I want the low-level details.\n\nBarring that, or even in addition to that, would it make sense to have \nseparate \"porcelain\" and \"plumbing\" sections of the release notes? \nObviously some changes straddle the two, but there are a lot that are \npretty clear-cut one way or the other. Then end users can ignore the \nplumbing section and porcelain writers can jump straight to it.\n\n-Steve\n"},{"id":"52280","messageId":"7vr6lgobsl.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"46DB4903.6060100@midwinter.com","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-03T00:03:22Z","receivedAt":"2007-09-03T00:03:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> No argument there, of course; it needs to be documented. But maybe not\n> as the very first item at the top of the release notes, which people\n> might expect to be organized in a \"most user-visible first\" order. I\n> usually expect to see general descriptions of new features and\n> critical bugfixes at the top of a program's release notes, with the\n> option to keep reading if I want the low-level details.\n>\n> Barring that, or even in addition to that, would it make sense to have\n> separate \"porcelain\" and \"plumbing\" sections of the release notes?\n\nI think that makes sense, as \"most user-visible first\" order\nwill be different what kind of \"user\" you are.\n"},{"id":"52283","messageId":"7vejhgob2j.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"20070902191644.29d46cd2.seanlkml@sympatico.ca","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"junkio@pobox.com","sentAt":"2007-09-03T00:19:00Z","receivedAt":"2007-09-03T00:19:00Z","isPatch":false,"sender":{"key":"junkio@pobox.com","avatar":null},"body":"Sean writes:\n\n> On Sun, 02 Sep 2007 15:13:09 -0700\n> Junio C Hamano wrote:\n> ...\n>> For majority of general public, I thought the spec file _I_\n>> ship, along with RPM files _I_ build, are contrib status\n>> already. Don't distro people do their own RPM packages, instead\n>> of using what I placed on k.org?\n>\n> Didn't know you used RPM yourself, so I guess this is just\n> a case of something slipping through rather than the spec file\n> needing a maintainer.\n\nWell, I do not _use_ it, but the RPM I have on k.org and mention\nas part of the announcement are built by me by typing \"make\nrpm\". What I meant to say was that these RPM files may not be\n\"official\" at all from the point of view of distro users, and I\nsuspect that distro \"package maintainers\" for git would not be\ndoing just a plain vanilla \"make rpm\" using the spec file that\ncomes as part of git.git repository.\n"},{"id":"52305","messageId":"46DBBBEB.6010701@zytor.com","threadId":"9741","inReplyTo":"20070902133803.1b46f599.seanlkml@sympatico.ca","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-09-03T07:46:51Z","receivedAt":"2007-09-03T07:46:51Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Sean wrote:\n> On Sun, 02 Sep 2007 10:57:03 +0100\n> \"H. Peter Anvin\" wrote:\n> \n>> From the looks of it, there is still a git-p4, it just moved to contrib \n>> and uses fast-import, so removing its rpm package was probably broken in \n>> the first place.\n> \n> Hi Peter,\n> \n> Items in contrib aren't officially supported, so it doesn't sound like\n> a good idea to offer installs for them. Of course, it might be a good\n> idea to promote git-p4 up out of contrib and add it to the spec file.\n\nWell, the old one was out of contrib, too. Maybe it should never have \nbeen packaged up, but it was...\n\n> As things stand now, do you get an error when trying to upgrade Git via\n> yum? I'd have thought things would upgrade fine but leave the old git-p4\n> rpm hanging around. Either way, the obsoletes line mentioned by David\n> sounds like the right solution.\n\nYes, it gets an error, because all the git RPMs are tied together by \nexplicit version number and so can only be upgraded as a group.\n\n> As an aside, when I sent the patch removing git-p4import from the spec\n> file I mentioned that I had no way to test it and asked for testers.\n> Git needs a spec file maintainer so that issues like this can be caught\n> before release. Without a maintainer, it should probably be demoted\n> to contrib itself.\n\nWell, git on kernel.org (and many other places) critically depends on \nrpms being available.\n\n\t-hpa\n"},{"id":"52307","messageId":"46DBBD00.5090308@zytor.com","threadId":"9741","inReplyTo":"20070902191644.29d46cd2.seanlkml@sympatico.ca","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-09-03T07:51:28Z","receivedAt":"2007-09-03T07:51:28Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Sean wrote:\n> \n> Given the comment from David, I suspect your patch is all\n> that's needed; hopefully Peter can give it a quick test.\n> \n\nIt sounds like it; I don't know how to test it other than placing in the \nrepository and try to upgrade. It can't be any worse, so I don't see \nany harm in just doing it.\n\n\t-hpa\n"},{"id":"52311","messageId":"7vr6lgmao5.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"46DBBD00.5090308@zytor.com","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-03T08:10:34Z","receivedAt":"2007-09-03T08:10:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> Sean wrote:\n>>\n>> Given the comment from David, I suspect your patch is all\n>> that's needed; hopefully Peter can give it a quick test.\n>\n> It sounds like it; I don't know how to test it other than placing in\n> the repository and try to upgrade. It can't be any worse, so I don't\n> see any harm in just doing it.\n\nOk, should I then do that single change, cut 1.5.3.1 with it and\nping you?\n"},{"id":"52312","messageId":"46DBC1EE.3020009@zytor.com","threadId":"9741","inReplyTo":"7vr6lgmao5.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-09-03T08:12:30Z","receivedAt":"2007-09-03T08:12:30Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n>> Sean wrote:\n>>> Given the comment from David, I suspect your patch is all\n>>> that's needed; hopefully Peter can give it a quick test.\n>> It sounds like it; I don't know how to test it other than placing in\n>> the repository and try to upgrade. It can't be any worse, so I don't\n>> see any harm in just doing it.\n> \n> Ok, should I then do that single change, cut 1.5.3.1 with it and\n> ping you?\n\nSounds good to me.\n\n\t-hpa\n"},{"id":"52317","messageId":"7vfy1wm9ik.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"46DBC1EE.3020009@zytor.com","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-03T08:35:31Z","receivedAt":"2007-09-03T08:35:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n>> Ok, should I then do that single change, cut 1.5.3.1 with it and\n>> ping you?\n>\n> Sounds good to me.\n\nThanks, and sorry for the trouble. I am building one on k.org,\nand after placing the result in the RPMS/x86-64 and running the\nyummy script, I'll ping you again. If it installs fine for you,\nI'll boot my wife's machine to do i386 as well, but it is\ngetting a bit late now, so it might have to be tomorrow.\n\n-- >8 -- snipsnap -- >8 -- clipcrap -- >8 --\nFrom: Junio C Hamano \nDate: Sun, 2 Sep 2007 15:16:44 -0700\nSubject: [PATCH] GIT 1.5.3.1: obsolete git-p4 in RPM spec file.\n\nHPA noticed that yum does not like the newer git RPM set; it turns out\nthat we do not ship git-p4 anymore but existing installations do not\nrealize the package is gone if we do not tell anything about it.\n\nDavid Kastrup suggests using Obsoletes in the spec file of the new\nRPM to replace the old package, so here is a try.\n\nSigned-off-by: Junio C Hamano \n---\n git.spec.in | 1 +\n Documentation/RelNotes-1.5.3.1.txt | 10 ++++++++++\n Documentation/git.txt | 5 ++++-\n GIT-VERSION-GEN | 2 +-\n RelNotes | 2 +-\n 5 files changed, 17 insertions(+), 3 deletions(-)\n create mode 100644 Documentation/RelNotes-1.5.3.1.txt\n\ndiff --git a/git.spec.in b/git.spec.in\nindex fe7b3d8..bdb293d 100644\n--- a/git.spec.in\n+++ b/git.spec.in\n@@ -25,6 +25,7 @@ This is a dummy package which brings in all subpackages.\n Summary:\tCore git tools\n Group:\t\tDevelopment/Tools\n Requires:\tzlib >= 1.2, rsync, curl, less, openssh-clients, expat\n+Obsoletes:\tgit-p4\n %description core\n Git is a fast, scalable, distributed revision control system with an\n unusually rich command set that provides both high-level operations\ndiff --git a/Documentation/RelNotes-1.5.3.1.txt b/Documentation/RelNotes-1.5.3.1.txt\nnew file mode 100644\nindex 0000000..7ff546c\n--- /dev/null\n+++ b/Documentation/RelNotes-1.5.3.1.txt\n@@ -0,0 +1,10 @@\n+GIT v1.5.3.1 Release Notes\n+==========================\n+\n+Fixes since v1.5.3\n+------------------\n+\n+This is solely to fix the generated RPM's dependencies. We used\n+to have git-p4 package but we do not anymore. As suggested on\n+the mailing list, this release makes git-core \"Obsolete\" git-p4,\n+so that yum update would not complain.\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex ceca892..6f7db29 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -43,7 +43,10 @@ unreleased) version of git, that is available from 'master'\n branch of the `git.git` repository.\n Documentation for older releases are available here:\n \n-* link:v1.5.2.5/git.html[documentation for release 1.5.2.5]\n+* link:v1.5.3/git.html[documentation for release 1.5.3]\n+\n+* release notes for\n+ link:RelNotes-1.5.3.1.txt[1.5.3.1].\n \n * release notes for\n link:RelNotes-1.5.2.5.txt[1.5.2.5],\ndiff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN\nindex 3c0032c..3835fb3 100755\n--- a/GIT-VERSION-GEN\n+++ b/GIT-VERSION-GEN\n@@ -1,7 +1,7 @@\n #!/bin/sh\n \n GVF=GIT-VERSION-FILE\n-DEF_VER=v1.5.3.GIT\n+DEF_VER=v1.5.3.1.GIT\n \n LF='\n '\ndiff --git a/RelNotes b/RelNotes\nindex 0de5e66..ea8f800 120000\n--- a/RelNotes\n+++ b/RelNotes\n@@ -1 +1 @@\n-Documentation/RelNotes-1.5.3.txt\n\\ No newline at end of file\n+Documentation/RelNotes-1.5.3.1.txt\n\\ No newline at end of file\n-- \n1.5.3\n"},{"id":"52323","messageId":"46DBCA31.5010607@zytor.com","threadId":"9741","inReplyTo":"7vfy1wm9ik.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-09-03T08:47:45Z","receivedAt":"2007-09-03T08:47:45Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n>>> Ok, should I then do that single change, cut 1.5.3.1 with it and\n>>> ping you?\n>> Sounds good to me.\n> \n> Thanks, and sorry for the trouble. I am building one on k.org,\n> and after placing the result in the RPMS/x86-64 and running the\n> yummy script, I'll ping you again. If it installs fine for you,\n> I'll boot my wife's machine to do i386 as well, but it is\n> getting a bit late now, so it might have to be tomorrow.\n> \n\ngit.kernel.org is actually an i386 machine (the only one we have left), too.\n\n\t-hpa\n"},{"id":"52325","messageId":"7vzm04ku3i.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"46DBCA31.5010607@zytor.com","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-03T08:53:53Z","receivedAt":"2007-09-03T08:53:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> Junio C Hamano wrote:\n>> \"H. Peter Anvin\" writes:\n>>\n>>>> Ok, should I then do that single change, cut 1.5.3.1 with it and\n>>>> ping you?\n>>> Sounds good to me.\n>>\n>> Thanks, and sorry for the trouble. I am building one on k.org,\n>> and after placing the result in the RPMS/x86-64 and running the\n>> yummy script, I'll ping you again. If it installs fine for you,\n>> I'll boot my wife's machine to do i386 as well, but it is\n>> getting a bit late now, so it might have to be tomorrow.\n>>\n>\n> git.kernel.org is actually an i386 machine (the only one we have left), too.\n\nI see /usr/bin/git on the other machine is already 1.5.3.1 so I\ntake the experiment went well. I am building the i386 set now.\n"},{"id":"52329","messageId":"7vlkboktce.fsf@gitster.siamese.dyndns.org","threadId":"9741","inReplyTo":"46DBCA31.5010607@zytor.com","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-03T09:10:09Z","receivedAt":"2007-09-03T09:10:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> Junio C Hamano wrote:\n>> \"H. Peter Anvin\" writes:\n>>\n>>>> Ok, should I then do that single change, cut 1.5.3.1 with it and\n>>>> ping you?\n>>> Sounds good to me.\n>>\n>> Thanks, and sorry for the trouble. I am building one on k.org,\n>> and after placing the result in the RPMS/x86-64 and running the\n>> yummy script, I'll ping you again. If it installs fine for you,\n>> I'll boot my wife's machine to do i386 as well, but it is\n>> getting a bit late now, so it might have to be tomorrow.\n>\n> git.kernel.org is actually an i386 machine (the only one we have left), too.\n\nOk, I did the same for i386, up to \"yummy\" part. Could you take\ncare of the rest of the installation procedure, please?\n"},{"id":"52330","messageId":"46DBD02A.60603@zytor.com","threadId":"9741","inReplyTo":"7vlkboktce.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-09-03T09:13:14Z","receivedAt":"2007-09-03T09:13:14Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n>> Junio C Hamano wrote:\n>>> \"H. Peter Anvin\" writes:\n>>>\n>>>>> Ok, should I then do that single change, cut 1.5.3.1 with it and\n>>>>> ping you?\n>>>> Sounds good to me.\n>>> Thanks, and sorry for the trouble. I am building one on k.org,\n>>> and after placing the result in the RPMS/x86-64 and running the\n>>> yummy script, I'll ping you again. If it installs fine for you,\n>>> I'll boot my wife's machine to do i386 as well, but it is\n>>> getting a bit late now, so it might have to be tomorrow.\n>> git.kernel.org is actually an i386 machine (the only one we have left), too.\n> \n> Ok, I did the same for i386, up to \"yummy\" part. Could you take\n> care of the rest of the installation procedure, please?\n> \n\nDone, all good.\n\n\t-hpa\n"},{"id":"52341","messageId":"46DBF0BB.3070605@op5.se","threadId":"9741","inReplyTo":"7v4picpvgq.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-09-03T11:32:11Z","receivedAt":"2007-09-03T11:32:11Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> Assuming that we do not give the old git-p4import script\n> packaged in \"git-p4 package\", would the following patch be all\n> that is needed, or do we need other things in the spec file?\n> \n> -- snipsnap clipcrap --\n> +Obsoletes:\tgit-p4\n\nThat depends. If packages outside of git requires the git-p4 package to function\nthen this will not suffice and a line saying\n\n\tProvides: git-p4\n\nwould have to be added instead. If some other already installed package Require:'s\n/usr/bin/git-p4import, then that other package is broken and we're toast.\n\nI have a hard time seeing what other package would depend on the git-p4import\nscript so this was more along the lines of \"how rpm dependencies work, kinda\"\nthan a real issue.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"52352","messageId":"868x7nj482.fsf@lola.quinscape.zz","threadId":"9741","inReplyTo":"46DBF0BB.3070605@op5.se","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-03T12:58:05Z","receivedAt":"2007-09-03T12:58:05Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Andreas Ericsson writes:\n\n> Junio C Hamano wrote:\n>>\n>> Assuming that we do not give the old git-p4import script\n>> packaged in \"git-p4 package\", would the following patch be all\n>> that is needed, or do we need other things in the spec file?\n>>\n>> -- snipsnap clipcrap --\n>> +Obsoletes:\tgit-p4\n>\n> That depends. If packages outside of git requires the git-p4 package\n> to function then this will not suffice and a line saying\n>\n> \tProvides: git-p4\n>\n> would have to be added instead.\n\nNot instead, but in addition IIRC (it obsoletes the package and\nprovides the feature). But that would be nonsensical if the outside\npackage indeed requires git-p4 and we don't have it in our current\nRPM: the purpose of dependencies is to not have things break silently,\nand lying about what we provide would be wrong.\n\n-- \nDavid Kastrup\n"},{"id":"52353","messageId":"46DC05F8.7000709@op5.se","threadId":"9741","inReplyTo":"868x7nj482.fsf@lola.quinscape.zz","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-09-03T13:02:48Z","receivedAt":"2007-09-03T13:02:48Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"David Kastrup wrote:\n> Andreas Ericsson writes:\n> \n>> Junio C Hamano wrote:\n>>> Assuming that we do not give the old git-p4import script\n>>> packaged in \"git-p4 package\", would the following patch be all\n>>> that is needed, or do we need other things in the spec file?\n>>>\n>>> -- snipsnap clipcrap --\n>>> +Obsoletes:\tgit-p4\n>> That depends. If packages outside of git requires the git-p4 package\n>> to function then this will not suffice and a line saying\n>>\n>> \tProvides: git-p4\n>>\n>> would have to be added instead.\n> \n> Not instead, but in addition IIRC (it obsoletes the package and\n> provides the feature). But that would be nonsensical if the outside\n> package indeed requires git-p4 and we don't have it in our current\n> RPM: the purpose of dependencies is to not have things break silently,\n> and lying about what we provide would be wrong.\n> \n\nNo, it really is instead. A package obsoleting one of the features it\nprovides itself would be insane.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"52354","messageId":"86wsv7hora.fsf@lola.quinscape.zz","threadId":"9741","inReplyTo":"46DC05F8.7000709@op5.se","subject":"Re: [ANNOUNCE] GIT 1.5.3","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-03T13:17:29Z","receivedAt":"2007-09-03T13:17:29Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Andreas Ericsson writes:\n\n> David Kastrup wrote:\n>> Andreas Ericsson writes:\n>>\n>>> Junio C Hamano wrote:\n>>>> Assuming that we do not give the old git-p4import script\n>>>> packaged in \"git-p4 package\", would the following patch be all\n>>>> that is needed, or do we need other things in the spec file?\n>>>>\n>>>> -- snipsnap clipcrap --\n>>>> +Obsoletes:\tgit-p4\n>>> That depends. If packages outside of git requires the git-p4 package\n>>> to function then this will not suffice and a line saying\n>>>\n>>> \tProvides: git-p4\n>>>\n>>> would have to be added instead.\n>>\n>> Not instead, but in addition IIRC (it obsoletes the package and\n>> provides the feature). But that would be nonsensical if the outside\n>> package indeed requires git-p4 and we don't have it in our current\n>> RPM: the purpose of dependencies is to not have things break silently,\n>> and lying about what we provide would be wrong.\n>\n> No, it really is instead. A package obsoleting one of the features\n> it provides itself would be insane.\n\nNot according to my understanding: \"Obsoletes:\" concerns _packages_,\nwhile \"Provides:\" concerns features. So it is perfectly feasible to\nobsolete a previously separate package and provide its functionality.\n\nAnd indeed, our \"emacs-auctex\" package _both_ obsoletes _and_ provides\n\"auctex\". And it is not like we did not learn this the hard way...\n\n-- \nDavid Kastrup\n"}]}