{"thread":{"id":"2424","subject":"[ANNOUNCE] GIT 0.99.9g","startedAt":"2005-11-10T08:14:29Z","lastAt":"2005-11-14T21:15:31Z","messageCount":29,"participants":["Junio C Hamano","Jeff Garzik","Yaacov Akiba Slama","H. Peter Anvin","Petr Baudis","Daniel Barkalow","Andreas Ericsson","Jim Radford","Linus Torvalds","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11459","messageId":"7vmzkc2a3e.fsf@assigned-by-dhcp.cox.net","threadId":"2424","inReplyTo":null,"subject":"[ANNOUNCE] GIT 0.99.9g","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-10T08:14:29Z","receivedAt":"2005-11-10T08:14:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"GIT 0.99.9g is found at usual places. There are a couple of\nimportant changes, as the slow march towards 1.0 continues.\n\n - The RPM package has been split into a few packages by Jim\n Radford. Unfortunately I am not equipped sufficiently to\n test the resulting RPMs, so please feed me updates and\n corrections as needed. I think archimport part needs to be\n split out just like its svn/cvs cousins, and perhaps\n documentation into another separate package.\n\n - Fredrik Kuivinen's merge-recursive strategy is now the\n default merge strategy for two-head merge that happens after\n git-pull. I do not expect this to cause major disruptions,\n but if this breaks things there is a workaround to override\n this [*1*].\n\nAlthough I did not hear anybody jumping up-and-down to merge\nsvnimport updates from Yaacov Akiba Slama, I did not hear it\nbroke things either, so it graduated to the master branch and\nincluded in this release. It obviously improved things for\nYaacov, and I am hoping this would not cause disruptions for\npeople's existing setup.\n\nAlso included are unexciting bits of fixes here and there.\n\nOn the \"proposed updates\" front, things finally seem to be\ncalming down.\n\n - One important newcomer is git-pack-redundant. It is still in\n \"pu\" not because I doubt what it does is useful, but simply\n because I have not had a chance to study how it does its\n thing. I expect to fully merge it into \"master\" before 1.0\n happens.\n\n - Among my own toys in the \"pu\" branch:\n\n - Determination of merge base for Octopus merge was quite\n pessimistic, and a proposed fix is in there; since I will\n be regularly and frequently doing Octopus merges, I'll soon\n know if this change breaks things; otherwise it will\n graduate to \"master\" shortly.\n\n - merge-base computation done by show-branch was a bit loose\n compared to the real merge-base, as pointed out by Linus on\n the list, although it does not seem to matter too much in\n practice. Also I plan to look into merge-base to see if I\n can fix the horizon effect cheaply but that work has not\n started yet (it is triggered by fairly pathological case).\n\n - I got tired of not being able to get the committer date\n (except the raw format which is unreadable) out of git-log,\n and added --pretty=fuller format. This should not break\n people's existing setup, so I expect it to move to \"master\"\n soon, maybe with a name change if somebody can suggest a\n better name for it.\n\n - Change merge-one-file to handle the case where two sides\n add the same path differently. Instead of punting, try to\n do two-file merge from both sides. This _might_ turn out\n to be useful, but I do not know yet, so it won't graduate\n to \"master\" unless somebody convinces me (and the\n community) that it is useful in some use-case scenario.\n\n - Add git-lost+found. Currently the implementation stores\n found refs under .git/lost+found/{commit,other}\n directories, but writing out their object names to the\n standard output and let the users decide what to do with\n them was suggested on the list by Daniel, which makes sense\n as well. There are pros and cons so until we know if it is\n useful and if so in what form, it will not come out of \"pu\"\n branch.\n\n - I do not consider either git-shallow-pack and git-changes\n \"master\" material. The former is a hack to create\n deliberately broken repository. The latter is supporting a\n wrong workflow, as Linus described the other day. You can\n temporarily fetch what you want to compare into local\n repository and run git-log or git-whatchanged normally.\n\nOh, and we will not be moving things out of /usr/bin/ during 1.0\ntimeframe.\n\n\n[Footnote]\n\n*1* If for whatever reason you would prefer to keep using the\n'resolve' strategy as before when you run 'git-pull', you can\neither do 'git-pull -s resolve ...' on the\ncommand line, or add the following in your .git/config file:\n\n [pull]\n twohead = resolve\n\nOn the other hand, if you like to try resolve and then\nrecursive, you can have this instead (the order does matter, the\nfirst one is tried first):\n\n [pull]\n twohead = resolve\n twohead = recursive\n"},{"id":"11462","messageId":"43730E39.6030601@pobox.com","threadId":"2424","inReplyTo":"7vmzkc2a3e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-11-10T09:09:13Z","receivedAt":"2005-11-10T09:09:13Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Junio C Hamano wrote:\n> - One important newcomer is git-pack-redundant. It is still in\n> \"pu\" not because I doubt what it does is useful, but simply\n> because I have not had a chance to study how it does its\n> thing. I expect to fully merge it into \"master\" before 1.0\n> happens.\n\nIMHO git-prune-packed should prune redundant pack files...\n\n\n\n> Oh, and we will not be moving things out of /usr/bin/ during 1.0\n> timeframe.\n\n:( bummer. I do like the elegance of having /usr/bin/git executing \nstuff out of /usr/libexec/git.\n\n/usr/libexec/git also makes it IMO cleaner when integrating git plugins \nfrom third parties (rpm -Uvh git-newfeature), because you don't have to \nworry about the /usr/bin namespace.\n\n\tJeff\n"},{"id":"11466","messageId":"437318CD.2050401@slamail.org","threadId":"2424","inReplyTo":"7vmzkc2a3e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Yaacov Akiba Slama","fromEmail":"ya@slamail.org","sentAt":"2005-11-10T09:54:21Z","receivedAt":"2005-11-10T09:54:21Z","isPatch":false,"sender":{"key":"ya@slamail.org","avatar":null},"body":"Junio C Hamano wrote:\n\n>Although I did not hear anybody jumping up-and-down to merge\n>svnimport updates from Yaacov Akiba Slama, I did not hear it\n>broke things either, so it graduated to the master branch and\n>included in this release. It obviously improved things for\n>Yaacov, and I am hoping this would not cause disruptions for\n>people's existing setup.\n> \n>\nThanks for the merge.\nIMHO, the commit labelled \n\"Bundle file copies from multiple branches into a merge\" \n(109fc2b97b73090a4a0a6550cdf9b2446fd12389) needs more attention/discussion.\n\nIn svn, there is no concept of branches or tag, but because the copy is \ncheap, directories are used to simulate branches and tags.\nThe repository will be like :\n\n/trunk/path/to/file\n/branches/branch_1/path/to/file\n/branches/branch_n/path/to/file\n/tags/tag_1/path/to/file\n/tags/tag_m/path/to/file\n\nNow, someone can copy directory or files from the trunk or any \nbranch/tag into any other directory. For instance one can commit the \nfollowing tree as a new revision :\n\n/trunk/path/to/file\n/trunk/new/path/to/file (this is a copy of /branches/branch_1/path/to/file)\n/branches/branch_1/path/to/file\n/branches/branch_n/path/to/file\n/tags/tag_1/path/to/file\n/tags/tag_m/path/to/file\n\n\nNow the commit 109fc2b97b73090a4a0a6550cdf9b2446fd12389 creates a new \ncommit with two parents:\n1) HEAD\n2) the git branch called \"branch_1\"\n\n From what I read about the definition of commit in git's documentation, \nthat seems to be ok, but can this marking of \"branch_1\" as a parent of \nthis commit be dangerous for merges done later in pure git ?\n\n--yas\n"},{"id":"11482","messageId":"43737EC7.6090109@zytor.com","threadId":"2424","inReplyTo":"7vmzkc2a3e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-11-10T17:09:27Z","receivedAt":"2005-11-10T17:09:27Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> - Add git-lost+found. Currently the implementation stores\n> found refs under .git/lost+found/{commit,other}\n> directories, but writing out their object names to the\n> standard output and let the users decide what to do with\n> them was suggested on the list by Daniel, which makes sense\n> as well. There are pros and cons so until we know if it is\n> useful and if so in what form, it will not come out of \"pu\"\n> branch.\n> \n\nMay I *STRONGLY* urge you to name that something different. \n\"lost+found\" is a name with special properties in Unix; for example, \nmany backup solutions will ignore a directory with that name.\n\n\t-hpa\n"},{"id":"11483","messageId":"43737F9E.60703@zytor.com","threadId":"2424","inReplyTo":"43730E39.6030601@pobox.com","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-11-10T17:13:02Z","receivedAt":"2005-11-10T17:13:02Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Jeff Garzik wrote:\n> \n>> Oh, and we will not be moving things out of /usr/bin/ during 1.0\n>> timeframe.\n> \n> \n> :( bummer. I do like the elegance of having /usr/bin/git executing \n> stuff out of /usr/libexec/git.\n> \n> /usr/libexec/git also makes it IMO cleaner when integrating git plugins \n> from third parties (rpm -Uvh git-newfeature), because you don't have to \n> worry about the /usr/bin namespace.\n> \n\nIt's nice in concept, but I think there are a lot of reasons why this is \na bad idea:\n\n- \"man\" doesn't handle it. It would be another thing if \"man\" could be \ntaught to understand commands like \"man cvs checkout\" or \"man git fetch\".\n\n- There is no general way to teach shells etc about it, for tab \ncompletion etc.\n\n- Makes it harder (but not impossible) to run git from a build directory \nwithout installing it first.\n\nIn comparison, the issue of clutter in /usr/bin is actually a pretty \nsmall issue, especially with htree. Most vendors have gone back to \nputting everything into /usr/bin since all variants that involve \nsplitting it up seem to be more of a loss than a gain.\n\n\t-hpa\n"},{"id":"11485","messageId":"7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net","threadId":"2424","inReplyTo":"43737EC7.6090109@zytor.com","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-10T17:44:43Z","receivedAt":"2005-11-10T17:44:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> May I *STRONGLY* urge you to name that something different. \n> \"lost+found\" is a name with special properties in Unix; for example, \n> many backup solutions will ignore a directory with that name.\n\nYeah, the original proposal (in TODO list) explicitly stated why\nI chose lost-found instead of lost+found back then, and somebody\non the list (could have been Pasky but I may be mistaken) said\nnot to worry. In any case, if we go the route Daniel suggests,\nwe would not be storing anything on the filesystem ourselves so\nthis would be a non-issue.\n"},{"id":"11488","messageId":"20051110180311.GR30496@pasky.or.cz","threadId":"2424","inReplyTo":"7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T18:03:11Z","receivedAt":"2005-11-10T18:03:11Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 06:44:43PM CET, I got a letter\nwhere Junio C Hamano said that...\n> \"H. Peter Anvin\" writes:\n> \n> > May I *STRONGLY* urge you to name that something different. \n> > \"lost+found\" is a name with special properties in Unix; for example, \n> > many backup solutions will ignore a directory with that name.\n> \n> Yeah, the original proposal (in TODO list) explicitly stated why\n> I chose lost-found instead of lost+found back then, and somebody\n> on the list (could have been Pasky but I may be mistaken) said\n> not to worry.\n\nIt was the Large Angry SCM. I share your concern.\n\n> In any case, if we go the route Daniel suggests, we would not be\n> storing anything on the filesystem ourselves so this would be a\n> non-issue.\n\nI like Daniel's route as well, for the separate command. But it would be\nnice to also have a way to tell git-fsck-cache to save the lost+found\nrefs as it goes, much like the filesystem fsck. So if it reports some\nunreachable refs, you will not need to tell it to do the same job\n_another_ time to find out the refs and pass them to gitk. Then again,\nif we do this, the utility of a separate command will be questionable.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11491","messageId":"Pine.LNX.4.64.0511101317500.25300@iabervon.org","threadId":"2424","inReplyTo":"20051110180311.GR30496@pasky.or.cz","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-10T18:31:16Z","receivedAt":"2005-11-10T18:31:16Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 10 Nov 2005, Petr Baudis wrote:\n\n> Dear diary, on Thu, Nov 10, 2005 at 06:44:43PM CET, I got a letter\n> where Junio C Hamano said that...\n> > \"H. Peter Anvin\" writes:\n> > \n> > > May I *STRONGLY* urge you to name that something different. \n> > > \"lost+found\" is a name with special properties in Unix; for example, \n> > > many backup solutions will ignore a directory with that name.\n> > \n> > Yeah, the original proposal (in TODO list) explicitly stated why\n> > I chose lost-found instead of lost+found back then, and somebody\n> > on the list (could have been Pasky but I may be mistaken) said\n> > not to worry.\n> \n> It was the Large Angry SCM. I share your concern.\n> \n> > In any case, if we go the route Daniel suggests, we would not be\n> > storing anything on the filesystem ourselves so this would be a\n> > non-issue.\n> \n> I like Daniel's route as well, for the separate command. But it would be\n> nice to also have a way to tell git-fsck-cache to save the lost+found\n> refs as it goes, much like the filesystem fsck. So if it reports some\n> unreachable refs, you will not need to tell it to do the same job\n> _another_ time to find out the refs and pass them to gitk. Then again,\n> if we do this, the utility of a separate command will be questionable.\n\nMaybe git-fsck-objects should have an option to make it note dangling \nobjects of certain types, and then count these as reachable? (That is, you \nwant the head of an unreachable chain listed for recovery, but not other \nthings reachable from it; you also may want the list of blobs and trees \nnot reachable either from a ref or from something listed for recovery, but \nnot omitting a blob reachable only from an unreachable tree)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"11492","messageId":"437392AD.20906@op5.se","threadId":"2424","inReplyTo":"43737F9E.60703@zytor.com","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-10T18:34:21Z","receivedAt":"2005-11-10T18:34:21Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"H. Peter Anvin wrote:\n> Jeff Garzik wrote:\n> \n>>\n>>> Oh, and we will not be moving things out of /usr/bin/ during 1.0\n>>> timeframe.\n>>\n>>\n>>\n>> :( bummer. I do like the elegance of having /usr/bin/git executing \n>> stuff out of /usr/libexec/git.\n>>\n>> /usr/libexec/git also makes it IMO cleaner when integrating git \n>> plugins from third parties (rpm -Uvh git-newfeature), because you \n>> don't have to worry about the /usr/bin namespace.\n>>\n> \n> It's nice in concept, but I think there are a lot of reasons why this is \n> a bad idea:\n> \n> - \"man\" doesn't handle it. It would be another thing if \"man\" could be \n> taught to understand commands like \"man cvs checkout\" or \"man git fetch\".\n> \n\nThis is moot. man-pages can still be named git-fetch.\n\n> - There is no general way to teach shells etc about it, for tab \n> completion etc.\n> \n\nAdd the lib directory to the path (for git-) or have it \nauto-evaluate the result of a git command-listing.\n\n> - Makes it harder (but not impossible) to run git from a build directory \n> without installing it first.\n> \n\nProvided adding --lib=. is considered difficult, yes. Btw, this problem \nstill applies as some of the programs run other programs that are \nexpected to be in the path.\n\nI've just posted a patch (used my submit-patch script, which was stupid \nsince I should have posted it here) that doesn't have any of these problems.\n\n> In comparison, the issue of clutter in /usr/bin is actually a pretty \n> small issue, especially with htree. Most vendors have gone back to \n> putting everything into /usr/bin since all variants that involve \n> splitting it up seem to be more of a loss than a gain.\n> \n\nFair enough. With the patch I've just sent (C implementation of the \n'git' program) this option is certainly available.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"11493","messageId":"20051110185423.GA7212@blackbean.org","threadId":"2424","inReplyTo":"7vmzkc2a3e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Jim Radford","fromEmail":"radford@blackbean.org","sentAt":"2005-11-10T18:54:23Z","receivedAt":"2005-11-10T18:54:23Z","isPatch":false,"sender":{"key":"radford@blackbean.org","avatar":null},"body":"On Thu, Nov 10, 2005 at 12:14:29AM -0800, Junio C Hamano wrote:\n> I think archimport part needs to be split out just like its\n> svn/cvs cousins,\n\nI don't agree. The chance of running git-archimport and not having\narch installed is significantly less likely than the chance of not\nnoticing that the git-archimport program exists because it was moved\ninto a separate package that you didn't know you needed to install in\nthe first place.\n\nThe main reason I see for splitting cvs and email import out is the\nnon-standard dependencies, cvsps and perl(Email::Valid). While for\nsvn import it's to keep from requiring subversion-perl of everone who\ninstalls git-core. This dependency is added automatically, so you\ncannot easily just ignore it like you can in the arch/tla case.\n\n> and perhaps documentation into another separate package.\n\nThere is no need for a separate documentation RPM, since the\ndocumentation is marked as such and rpm has a standard way to avoid\ninstalling them (--excludedocs).\n\n-Jim\n"},{"id":"11494","messageId":"7vk6fgz5nc.fsf@assigned-by-dhcp.cox.net","threadId":"2424","inReplyTo":"Pine.LNX.4.64.0511101317500.25300@iabervon.org","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-10T19:04:07Z","receivedAt":"2005-11-10T19:04:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> ... (That is, you \n> want the head of an unreachable chain listed for recovery, but not other \n> things reachable from it; you also may want the list of blobs and trees \n> not reachable either from a ref or from something listed for recovery, but \n> not omitting a blob reachable only from an unreachable tree)\n\nI thought that was what those 'dangling blah' was about...\nThat is, if you make commit A and then on top of that commit B,\nand lose both, you will see dnagling for B but not A (which is\nreachable from B).\n"},{"id":"11496","messageId":"Pine.LNX.4.64.0511101405300.25300@iabervon.org","threadId":"2424","inReplyTo":"7vk6fgz5nc.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-10T19:09:53Z","receivedAt":"2005-11-10T19:09:53Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 10 Nov 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > ... (That is, you \n> > want the head of an unreachable chain listed for recovery, but not other \n> > things reachable from it; you also may want the list of blobs and trees \n> > not reachable either from a ref or from something listed for recovery, but \n> > not omitting a blob reachable only from an unreachable tree)\n> \n> I thought that was what those 'dangling blah' was about...\n> That is, if you make commit A and then on top of that commit B,\n> and lose both, you will see dnagling for B but not A (which is\n> reachable from B).\n\nRight; what I was pointing out is that you want the dangling commits, but \nthe unreachable blobs and trees, and want reachability to count things \nlisted as dangling, which is a somewhat novel combination of desires, I \nthink.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"11501","messageId":"Pine.LNX.4.64.0511101128510.4627@g5.osdl.org","threadId":"2424","inReplyTo":"7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-10T19:32:58Z","receivedAt":"2005-11-10T19:32:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 10 Nov 2005, Junio C Hamano wrote:\n> \n> Yeah, the original proposal (in TODO list) explicitly stated why\n> I chose lost-found instead of lost+found back then, and somebody\n> on the list (could have been Pasky but I may be mistaken) said\n> not to worry. In any case, if we go the route Daniel suggests,\n> we would not be storing anything on the filesystem ourselves so\n> this would be a non-issue.\n\nI don't know how many people do this, but with the current kernel sources, \n\"git-fsck-cache --full\" takes about a minute on a reasonable fast machine \nwith everything in cache (ie no real disk activity to speak of)\n\nI personally think that's fine, since I repack my trees every once in a \nwhile, and almost never run a \"--full\" check, I only do incrementals \n(which are basically free). And I suspect that I run fsck a lot more than \nanybody else does.\n\nBut the point is, that if you actually run fsck every time you want to \nvisualize your pending commits, you're going to feel the pain. \n\nI think having some kind of lost+found so that you don't have to re-run \nfsck just because you decided to look at them some other way (use \"git \nlog\" instead of \"gitk\" or whatever) makes a lot of sense. But yes, it \nshouldn't really be called \"lost+found\" due to some rather serious \nconfusion that can cause.\n\n\t\tLinus\n"},{"id":"11504","messageId":"Pine.LNX.4.64.0511101142370.4627@g5.osdl.org","threadId":"2424","inReplyTo":"Pine.LNX.4.64.0511101128510.4627@g5.osdl.org","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-10T19:43:24Z","receivedAt":"2005-11-10T19:43:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 10 Nov 2005, Linus Torvalds wrote:\n>\n> But the point is, that if you actually run fsck every time you want to \n> visualize your pending commits, you're going to feel the pain. \n ^^^^^^^\n\nThat should be \"dangling\", of course. \n\n\t\tLinus\n"},{"id":"11506","messageId":"7voe4sxooz.fsf@assigned-by-dhcp.cox.net","threadId":"2424","inReplyTo":"437318CD.2050401@slamail.org","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-10T19:55:40Z","receivedAt":"2005-11-10T19:55:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yaacov Akiba Slama writes:\n\n> /trunk/path/to/file\n> /trunk/new/path/to/file (this is a copy of /branches/branch_1/path/to/file)\n> /branches/branch_1/path/to/file\n> /branches/branch_n/path/to/file\n> /tags/tag_1/path/to/file\n> /tags/tag_m/path/to/file\n>\n> Now the commit 109fc2b97b73090a4a0a6550cdf9b2446fd12389 creates a new \n> commit with two parents:\n> 1) HEAD\n> 2) the git branch called \"branch_1\"\n>\n> From what I read about the definition of commit in git's documentation, \n> that seems to be ok, but can this marking of \"branch_1\" as a parent of \n> this commit be dangerous for merges done later in pure git ?\n\nI think it is reasonable to record both as parents, to make the\ndevelopment history in branch_1 accessible from the trunk branch\nafter they are merged, and I do not think it is dangerous at\nall. It is just a regular merge which, when viewed from trunk\nside of the history, creates a directory called 'new' at the top\nlevel, and adds bunch of files there, and if you are viewing it\nwith rename/copy detection you may even notice that those\nchanges are mostly copy edits.\n\nBut the above example brings up an interesting question.\nSubversion lets you copy freely and does not require the\ndeveloper to express machine-readably what that copy is about.\nAlso it lets copy partial trees. So it is entirely plausible to\nrun your project like this:\n\n\t1. Repo has /trunk/i386/blah.c; i.e. 'ls' at the\n toplevel of the working tree shows 'i386' directory.\n\n /trunk/i386/blah.h\n\n 2. Somebody wants to do x86-64 equivalent of existing\n thing, and starts preparing it by copying existing\n i386 thing, into his branch, and do development\n there.\n\n\t\t/trunk/i386/blah.c\n /branches/wip-x86-64/blah.c (copy from /trunk/i386)\n\n 3. Later, that x86-64 equivalent matures, and gets\n merged into trunk:\n\n\t\t/trunk/i386/blah.c\n\t\t/trunk/x86-64/blah.c (merge back from /branches/wip-x86-64)\n /branches/wip-x86-64/blah.c (development ceased)\n\nBut it is also plausible to do this instead:\n\n\t2'. Instead of the above, you copy the whole thing\n\n\t\t/trunk/i386/blah.c\n /branches/wip/i386/blah.c (copy from /trunk)\n /branches/wip/x86-64/blah.c (then copy from /branches/wip/i386)\n\n 3'. Instead of the above:\n\n\t\t/trunk/i386/blah.c (merge back from /branches/wip)\n\t\t/trunk/x86-64/blah.c (merge back from /branches/wip)\n /branches/wip/i386/blah.c (development ceased)\n /branches/wip/x86-64/blah.c (development ceased)\n\nDo you need to handle the history resulting from these cases\ndifferently when importing from subversion? I have a feeling\nthat the user needs to tell what really happend for you to\nhandle this sensibly (tree root level is different), but I am\nnot offhand sure what the issues are.\n"},{"id":"11511","messageId":"4373AE02.9050909@op5.se","threadId":"2424","inReplyTo":"20051110185423.GA7212@blackbean.org","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-10T20:30:58Z","receivedAt":"2005-11-10T20:30:58Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jim Radford wrote:\n> On Thu, Nov 10, 2005 at 12:14:29AM -0800, Junio C Hamano wrote:\n> \n>> I think archimport part needs to be split out just like its\n>> svn/cvs cousins,\n> \n> \n> I don't agree. The chance of running git-archimport and not having\n> arch installed is significantly less likely than the chance of not\n> noticing that the git-archimport program exists because it was moved\n> into a separate package that you didn't know you needed to install in\n> the first place.\n> \n\nHow is this different for when svnimport and cvsimport was moved out? I \ndon't think anyone expected people to run those commands by accident \nwithout noticing that they fail without the svn || cvs installed underneath.\n\n> The main reason I see for splitting cvs and email import out is the\n> non-standard dependencies, cvsps and perl(Email::Valid).\n\n\nDefine \"non-standard\". String::ShellQuote isn't installed by default on \nFedora Core 3 but is required by git-archimport.\n\n\n> While for\n> svn import it's to keep from requiring subversion-perl of everone who\n> installs git-core. This dependency is added automatically, so you\n> cannot easily just ignore it like you can in the arch/tla case.\n> \n\nIt's fairly simple to provide a custom find-requires script.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"11516","messageId":"7v4q6kxm9c.fsf@assigned-by-dhcp.cox.net","threadId":"2424","inReplyTo":"4373AE02.9050909@op5.se","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-10T20:48:15Z","receivedAt":"2005-11-10T20:48:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Jim Radford wrote:\n>> On Thu, Nov 10, 2005 at 12:14:29AM -0800, Junio C Hamano wrote:\n>>\n>>> I think archimport part needs to be split out just like its\n>>> svn/cvs cousins,\n>> I don't agree...\n>\n> How is this different for when svnimport and cvsimport was moved out?..\n>\n>> The main reason I see for splitting cvs and email import out is the\n>> non-standard dependencies, cvsps and perl(Email::Valid).\n>\n> Define \"non-standard\". String::ShellQuote isn't installed by default on \n> Fedora Core 3 but is required by git-archimport.\n\nI am with Andreas here.\n\nIf you are using git to manage development in a tightly knitted\ngroup (e.g. company internal project) and are unlikely to be\nexchanging email patches, not having to pull Email::Valid into\nyour system is a good thing, because you would not be using\ngit-mail. If you are not dealing with development history\nstored in svn or tla, not having to install git-svn nor git-tla\nis a good thing.\n\nTechnical reasons like package availablity and required package\nsize count, but I do not think we should be doing the split\npurely for technical reasons. The split should aim primarily\nto give convenience for the users.\n\nThat reminds me, Andreas, you said something about feeding me\nspec updates last week but Jim beated you. I am open to\nimprovements from both of you. Obviously the invitation is not\nlimited to two of you ;-).\n"},{"id":"11588","messageId":"Pine.LNX.4.63.0511111516170.7575@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2424","inReplyTo":"43737EC7.6090109@zytor.com","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-11T14:19:04Z","receivedAt":"2005-11-11T14:19:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 10 Nov 2005, H. Peter Anvin wrote:\n\n> May I *STRONGLY* urge you to name that something different. \"lost+found\" \n> is a name with special properties in Unix; for example, many backup \n> solutions will ignore a directory with that name.\n\nTwo reasons against renaming:\n\n- we call it fsck-objects for a reason. We are working on a file system, \n which just so happens to be implemented in user space, not kernel space.\n If lost+found has to find a new name, so does fsck-objects.\n\n- lost+found has a special meaning, granted. So, a backup would not be \n made of it. So what? I *don't* want it backup'ed. I want to repair what\n was wrong with it. When I repaired it, the result is stored somewhere\n else. To backup lost+found would make as much sense as to backup /tmp.\n\nCiao,\nDscho\n"},{"id":"11613","messageId":"4374D913.503@zytor.com","threadId":"2424","inReplyTo":"Pine.LNX.4.63.0511111516170.7575@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-11-11T17:46:59Z","receivedAt":"2005-11-11T17:46:59Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Johannes Schindelin wrote:\n> \n> Two reasons against renaming:\n> \n> - we call it fsck-objects for a reason. We are working on a file system, \n> which just so happens to be implemented in user space, not kernel space.\n> If lost+found has to find a new name, so does fsck-objects.\n> \n\nI'm sorry, but that is bull. The problem here isn't the conventional \nnaming, it's that you're implementing your filesystem on top of another \nfilesystem, and you're running into a layering conflict.\n\n> - lost+found has a special meaning, granted. So, a backup would not be \n> made of it. So what? I *don't* want it backup'ed. I want to repair what\n> was wrong with it. When I repaired it, the result is stored somewhere\n> else. To backup lost+found would make as much sense as to backup /tmp.\n> \n\nThe default should ALWAYS be no data loss.\n\n\t-hpa\n"},{"id":"11615","messageId":"20051111182336.GA24416@blackbean.org","threadId":"2424","inReplyTo":"7v4q6kxm9c.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Jim Radford","fromEmail":"radford@blackbean.org","sentAt":"2005-11-11T18:23:36Z","receivedAt":"2005-11-11T18:23:36Z","isPatch":false,"sender":{"key":"radford@blackbean.org","avatar":null},"body":"On Thu, Nov 10, 2005 at 12:48:15PM -0800, Junio C Hamano wrote:\n> Andreas Ericsson writes:\n> > Jim Radford wrote:\n\n> >> The main reason I see for splitting cvs and email import out is the\n> >> non-standard dependencies, cvsps and perl(Email::Valid).\n\n> > Define \"non-standard\". String::ShellQuote isn't installed by default on \n> > Fedora Core 3 but is required by git-archimport.\n\nYou are right. I had missed that it required String::ShellQuote. It\nshould go in it's own RPM (and it already has).\n\n-Jim\n"},{"id":"11616","messageId":"7v64qzni9c.fsf@assigned-by-dhcp.cox.net","threadId":"2424","inReplyTo":"43730E39.6030601@pobox.com","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-11T18:37:03Z","receivedAt":"2005-11-11T18:37:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Garzik writes:\n\n> Junio C Hamano wrote:\n>> - One important newcomer is git-pack-redundant...\n>\n> IMHO git-prune-packed should prune redundant pack files...\n\nMaybe not in git-prune-packed, but you are right. We should at\nleast do that in git-prune. Maybe with something like the patch\nat the end?\n\n>> Oh, and we will not be moving things out of /usr/bin/ during 1.0\n>> timeframe.\n>\n> :( bummer. I do like the elegance of having /usr/bin/git executing \n> stuff out of /usr/libexec/git.\n\nBummer here as well. This is not my first preference, but more\nor less \"all things considered...\". I can go over cogito and\nstgit with Pasky and Catalin and coordinate the transition, but\nat the same time, everybody's existing scripts need to be\nadjusted. As Linus said, we broke kernel.org snapshot scripts\nnumber of times.\n\nAlso places we execute git-upload-pack and git-receive-pack over\nan SSH connection need to be updated to execute 'git' with the\nfirst parameter 'upload-pack' and 'receive-pack' to make sure it\nwould keep working with older or newer git on the other end.\n\nAfter all that happens, we can start installing things in\n/usr/lib/git/. During the transition, the C rewrite of git\nwrapper posted by Andreas Ericsson might help, so I am planning\nto merge it before 1.0, after deciding what the right word for\nthe \"path to the rest of git executables\" should be.\n\nSo let's say 1.0 will ship with all things in /usr/bin/, with\nupdated docs that explain the situation: (1) the dash form\n'git-frotz' is being deprecated, and you are encouraged to spell\nit as 'git frotz'; (2) if you want to use the dash form in your\nscripts for performance reasons, you need to have something like\nPATH=\"$(git --exec-path):$PATH\" at the beginning of your script.\n\nAnd after some time (say 2 months) we can switch.\n\nI just do not want to wait that long before 1.0.\n\n-- >8 -- cut here -- >8 --\n[PATCH] git-prune: prune redundant packs.\n\n---\ndiff --git a/git-prune.sh b/git-prune.sh\nindex ef31bd2..aa79807 100755\n--- a/git-prune.sh\n+++ b/git-prune.sh\n@@ -27,3 +27,14 @@ sed -ne '/unreachable /{\n }\n \n git-prune-packed $dryrun\n+\n+redundant=$(git-pack-redundant --all)\n+if test \"\" != \"$redundant\"\n+then\n+\tif test \"\" = $dryrun\n+\tthen\n+\t\techo \"$redundant\" | xargs rm -f\n+\telse\n+\t\techo rm -f \"$redundant\"\n+\tfi\n+fi\n"},{"id":"11627","messageId":"43750A53.9090602@zytor.com","threadId":"2424","inReplyTo":"437392AD.20906@op5.se","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-11-11T21:17:07Z","receivedAt":"2005-11-11T21:17:07Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Andreas Ericsson wrote:\n>>\n>> It's nice in concept, but I think there are a lot of reasons why this \n>> is a bad idea:\n>>\n>> - \"man\" doesn't handle it. It would be another thing if \"man\" could \n>> be taught to understand commands like \"man cvs checkout\" or \"man git \n>> fetch\".\n> \n> This is moot. man-pages can still be named git-fetch.\n> \n\nYes, of course, but that requires the user to be aware of yet another \nprogram-specific convention. I do believe that supporting hierarchial \nman pages would be a good thing, but one has to start that in the proper \npoint.\n\n>> - There is no general way to teach shells etc about it, for tab \n>> completion etc.\n> \n> Add the lib directory to the path (for git-) or have it \n> auto-evaluate the result of a git command-listing.\n\n... which means the end user has to do something specific to their \nenvironment.\n\nAll in all, I think the negatives outweigh the positives.\n\n\t-hpa\n"},{"id":"11626","messageId":"43750A9D.7070400@zytor.com","threadId":"2424","inReplyTo":"7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-11-11T21:18:21Z","receivedAt":"2005-11-11T21:18:21Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n> \n>>May I *STRONGLY* urge you to name that something different. \n>>\"lost+found\" is a name with special properties in Unix; for example, \n>>many backup solutions will ignore a directory with that name.\n> \n> \n> Yeah, the original proposal (in TODO list) explicitly stated why\n> I chose lost-found instead of lost+found back then, and somebody\n> on the list (could have been Pasky but I may be mistaken) said\n> not to worry. In any case, if we go the route Daniel suggests,\n> we would not be storing anything on the filesystem ourselves so\n> this would be a non-issue.\n> \n\nJust realized one more issue with this... a lot of non-Unix filesystems \ncan't deal with files with a + sign.\n\n\t-hpa\n"},{"id":"11662","messageId":"4375D3F1.2070506@op5.se","threadId":"2424","inReplyTo":"43750A53.9090602@zytor.com","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-12T11:37:21Z","receivedAt":"2005-11-12T11:37:21Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"H. Peter Anvin wrote:\n> Andreas Ericsson wrote:\n> \n>>>\n>>> It's nice in concept, but I think there are a lot of reasons why this \n>>> is a bad idea:\n>>>\n>>> - \"man\" doesn't handle it. It would be another thing if \"man\" could \n>>> be taught to understand commands like \"man cvs checkout\" or \"man git \n>>> fetch\".\n>>\n>>\n>> This is moot. man-pages can still be named git-fetch.\n>>\n> \n> Yes, of course, but that requires the user to be aware of yet another \n> program-specific convention. I do believe that supporting hierarchial \n> man pages would be a good thing, but one has to start that in the proper \n> point.\n> \n\nSomeone sent in a (broken) patch that pulls up the proper man-page for\n\tgit help \n\nIt's a rather good idea, so I'll be working it into the C implementation \nof git as soon as the core of it is implemented.\n\n>>> - There is no general way to teach shells etc about it, for tab \n>>> completion etc.\n>>\n>>\n>> Add the lib directory to the path (for git-) or have it \n>> auto-evaluate the result of a git command-listing.\n> \n> \n> ... which means the end user has to do something specific to their \n> environment.\n> \n> All in all, I think the negatives outweigh the positives.\n> \n\nPerhaps, but allowing the possibility of splitting them can't be wrong. \nWhen that's in place we only have to decide if we're going to or not.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"11665","messageId":"4375DD4A.5050103@op5.se","threadId":"2424","inReplyTo":"7v64qzni9c.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9g","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-12T12:17:14Z","receivedAt":"2005-11-12T12:17:14Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n>>>Oh, and we will not be moving things out of /usr/bin/ during 1.0\n>>>timeframe.\n>>\n>>:( bummer. I do like the elegance of having /usr/bin/git executing \n>>stuff out of /usr/libexec/git.\n> \n> \n> Bummer here as well. This is not my first preference, but more\n> or less \"all things considered...\". I can go over cogito and\n> stgit with Pasky and Catalin and coordinate the transition, but\n> at the same time, everybody's existing scripts need to be\n> adjusted. As Linus said, we broke kernel.org snapshot scripts\n> number of times.\n> \n> Also places we execute git-upload-pack and git-receive-pack over\n> an SSH connection need to be updated to execute 'git' with the\n> first parameter 'upload-pack' and 'receive-pack' to make sure it\n> would keep working with older or newer git on the other end.\n> \n\nI've cooked up a patch that takes care of this if;\n\tgit daemon\nis executed (rather than git-daemon). Otherwise we could just mention in \nthe docs that git-daemon must be run with the --libdir parameter (or \nwhatever we decide to call it). If it prepends the libdir to the path \neverything will work same as always in the rest of the code so it'll be \na very small change.\n\n> After all that happens, we can start installing things in\n> /usr/lib/git/. During the transition, the C rewrite of git\n> wrapper posted by Andreas Ericsson might help, so I am planning\n> to merge it before 1.0,> after deciding what the right word for\n> the \"path to the rest of git executables\" should be.\n> \n\nAll I really need to finalize it is that name, so It's up to you how \nfast you want it. Perhaps we could take a poll?\n\nThe suggestions so far come from the threads \"git binary directory?\" and \n\"[PATCH] C implementation of the 'git' program\" and some I just thought \nup. And here are the nominees;\n\n\tlibdir\n\tpath\n\texec-path\n\n\nKay Sievers pointed out that libexec is not \"LSB conformant\" so it might \nbe going away and is thus not listed.\n\nexec-path was the last suggested name I got from Junio.\n\nThe form will be\n\texec_path=$(prefix)/lib/git-@@VERSION@@\n\tGIT_EXEC_PATH\n\t--exec-path\n\nfor Makefile, environment and 'git', respectively. Substitute the \nobvious part with whatever you prefer.\n\n> So let's say 1.0 will ship with all things in /usr/bin/, with\n> updated docs that explain the situation: (1) the dash form\n> 'git-frotz' is being deprecated, and you are encouraged to spell\n> it as 'git frotz'; (2) if you want to use the dash form in your\n> scripts for performance reasons, you need to have something like\n> PATH=\"$(git --exec-path):$PATH\" at the beginning of your script.\n> \n> And after some time (say 2 months) we can switch.\n> \n\nSounds sensible, although I'm implementing Linus' idea of prepending the \nGIT_EXEC_PATH to $PATH so the porcelainish scripts in git-core shouldn't \nhave to do it. If someone executes git-