{"thread":{"id":"3153","subject":"LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)","startedAt":"2006-01-26T02:10:54Z","lastAt":"2006-02-09T05:50:18Z","messageCount":105,"participants":["Martin Langhoff","Linus Torvalds","Junio C Hamano","Keith Packard","Morten Welinder","Fredrik Kuivinen","Radoslaw Szkodzinski","Greg KH","Dave Jones","Daniel Barkalow","Mike McCormack","Carl Baldwin","Johannes Schindelin","J. Bruce Fields","Jon Loeliger","Sam Ravnborg","Alex Riesen","Joel Becker","Petr Baudis","Carl Worth","Randal L. Schwartz","Jason Riedy","Nicolas Pitre","Julian Phillips","H. Peter Anvin","Florian Weimer","Andreas Ericsson","Alan Chandler","Chuck Lever"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15133","messageId":"46a038f90601251810m1086d353ne8c7147edee4962a@mail.gmail.com","threadId":"3153","inReplyTo":null,"subject":"LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-26T02:10:54Z","receivedAt":"2006-01-26T02:10:54Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/26/06, Linus Torvalds wrote:\n\n> If we get an error parsing the arguments, exit.\n\nThis bug found thanks to the 'demo' effect. ;-)\n\nThe workshop had a 2hr slot -- after 2hs 15, I asked Linus if he\nwanted to talk about the internals. He did, and the workshop went\non... for 2 hours more. It was actually hard to get people out of the\nroom.\n\nSadly, not many people actually played along on their laptop. Those\nwho did got an extra bit of help to migrate their preexisting CVS/SVN\nrepos ;-) (thanks to Sam Vilain for all the help!)\n\nI'll upload the presentation material soon -- very similar to the\nstuff I used @ Wellington Perl Mongers. Still text-based; given all\nthe talk about plumbing and porcelain, I steadfastly refuse to add\nimagery.\n\nDuring the presentation someone mentioned errors when running\ngit-cvsimport which I'm keen on hearing more about.\n\ncheers,\n\n\nm\n"},{"id":"15173","messageId":"Pine.LNX.4.64.0601272345540.2909@evo.osdl.org","threadId":"3153","inReplyTo":"46a038f90601251810m1086d353ne8c7147edee4962a@mail.gmail.com","subject":"Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-28T04:47:16Z","receivedAt":"2006-01-28T04:47:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 Jan 2006, Martin Langhoff wrote:\n> \n> During the presentation someone mentioned errors when running\n> git-cvsimport which I'm keen on hearing more about.\n\nMartin, I talked to Keith, and apparently you fixed some cvsimport problem \nthey had with Cairo during dinner last night? Was that something that \ncould have affected other people, or was it very specific to whatever \nCairo CVS insanity? I've not seen any messages from you on it..\n\n\t\tLinus\n"},{"id":"15176","messageId":"46a038f90601272133o53438987ka6b97c21d0cdf921@mail.gmail.com","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601272345540.2909@evo.osdl.org","subject":"Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-28T05:33:52Z","receivedAt":"2006-01-28T05:33:52Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/28/06, Linus Torvalds wrote:\n> > During the presentation someone mentioned errors when running\n> > git-cvsimport which I'm keen on hearing more about.\n>\n> Martin, I talked to Keith, and apparently you fixed some cvsimport problem\n> they had with Cairo during dinner last night? Was that something that\n> could have affected other people, or was it very specific to whatever\n> Cairo CVS insanity? I've not seen any messages from you on it..\n\nI've got a few small improvements to cvsimport in my laptop that I'll\npush out for Junio to merge as soon as I get back to the office. I've\nrun \"99% successful\" imports of cairo and of x.org (modular and\nmonolithic) with all their branches and tags. It isn't literally the\n20 years of commits Jim talked initially about -- cvs holds just the\nlast ~5 years.\n\nThe repos *are* a bit broken -- files missing (not moved, but really\nmissing) so some of the fixes are to make it easier to discover where\nit is dying and workaround it. There are a few more things that I need\nto debug in cvsimport -- there's a small delta between what I should\nhave and what I do have. As soon as they are 100% right I'll put them\non http://locke.catalyst.net.nz/gitweb for the X.org team to have a\nlook at them -- and a cronjob to keep them up to date with official\nCVS.\n\nBTW, have you still got that patch to git-merge to seed the commit msg\nwith conflicted files? ;-)\n\ncheers,\n\n\nm\n"},{"id":"15177","messageId":"Pine.LNX.4.64.0601280047240.2909@evo.osdl.org","threadId":"3153","inReplyTo":"46a038f90601272133o53438987ka6b97c21d0cdf921@mail.gmail.com","subject":"Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-28T05:53:31Z","receivedAt":"2006-01-28T05:53:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 28 Jan 2006, Martin Langhoff wrote:\n> \n> BTW, have you still got that patch to git-merge to seed the commit msg\n> with conflicted files? ;-)\n\nNope. But it was something like the appended (totally untested, and \nslightly improved).\n\nThe point being that we'd fill in a template that the committer will \nhopefully edit to explain what he did to fix up the merge for each file \nthat had conflicts.\n\n\t\tLinus\n\n---\ndiff --git a/git-merge.sh b/git-merge.sh\nindex 0a158ef..9f828f3 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -301,5 +301,9 @@ then\n \t\"Automatic merge went well; stopped before committing as requested\"\n \texit 0\n else\n+\techo >\"$GIT_DIR/MERGE_MSG\"\n+\techo \"Conflicts in\" >\"$GIT_DIR/MERGE_MSG\"\n+\tgit-ls-files --unmerged | cut -f2 | uniq |\n+\t\tsed 's/^.*/ \\0:/' >\"$GIT_DIR/MERGE_MSG\"\n \tdie \"Automatic merge failed; fix up by hand\"\n fi\n"},{"id":"15178","messageId":"7v3bj8yia1.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601280047240.2909@evo.osdl.org","subject":"Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-28T06:32:22Z","receivedAt":"2006-01-28T06:32:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> The point being that we'd fill in a template that the committer will \n> hopefully edit to explain what he did to fix up the merge for each file \n> that had conflicts.\n\nThat is a sound idea from the point of view of good practice.\n\nWhile on the topic of conflicting merge, I've been wondering if\nit would make sense to do the \"combined diff\" between stage 2,\nstage 3 and the working tree file, in addition to the --ours and\n--theirs enhancements you added lately.\n\nThis would let you sanity check the merge you _could_ commit, in\nthe same format you would see later when you examine the merge\ncommit.\n"},{"id":"15180","messageId":"1138446030.9919.112.camel@evo.keithp.com","threadId":"3153","inReplyTo":"46a038f90601272133o53438987ka6b97c21d0cdf921@mail.gmail.com","subject":"Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-01-28T11:00:30Z","receivedAt":"2006-01-28T11:00:30Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Sat, 2006-01-28 at 18:33 +1300, Martin Langhoff wrote:\n\n> I've got a few small improvements to cvsimport in my laptop that I'll\n> push out for Junio to merge as soon as I get back to the office. I've\n> run \"99% successful\" imports of cairo and of x.org (modular and\n> monolithic) with all their branches and tags. It isn't literally the\n> 20 years of commits Jim talked initially about -- cvs holds just the\n> last ~5 years.\n\nYeah, X CVS is a scattered mess at present. I think it would be better\nto just leave that mess alone and grab a reasonably recent chunk of it\nto put into a GIT repository. Save a bunch of space too. We also haven't\nquite finished all of the recovery needed to span the whole twenty years\nyet.\n\nCarl and I hacked at the tool a bit to pull apart our ChangeLog-based\ncommit messages; extracting email addresses and separating the commit\nmessages from the (now useless) list of affected files. \n\nWe're getting clean cairo imports now, there are a few weirdnesses\naround branches that we've seen -- one commit appears on both the branch\nand trunk for some reason.\n\nOnce we're happy with the import, I'm pretty sure we'll just switch\ncairo over to git and dump the CVS bits. X.org is a harder case, for\nthat I suspect we'll migrate individual modules over one at a time,\nperhaps starting with the core X server pieces so that I can get my work\ndone, have it published in the main repository and not have it also\nbreak everyone else's X server.\n\nI'm not sure we'll need ongoing synchronization with existing X.org CVS\nfor long; there aren't any other developers doing any significant\nchanges to this part of the system, so we can abandon the losers with no\nremorse.\n \n-- \nkeith.packard@intel.com\n"},{"id":"15183","messageId":"7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"1138446030.9919.112.camel@evo.keithp.com","subject":"[Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-28T21:08:54Z","receivedAt":"2006-01-28T21:08:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Keith Packard writes:\n\n> Once we're happy with the import, I'm pretty sure we'll just switch\n> cairo over to git and dump the CVS bits. X.org is a harder case, for\n> that I suspect we'll migrate individual modules over one at a time,\n> perhaps starting with the core X server pieces so that I can get my work\n> done, have it published in the main repository and not have it also\n> break everyone else's X server.\n\nWow....... You are switching Cairo and X.org from CVS to git?\n\nIt could be that anything is better than CVS these days, but I\nhave to admit that my jaw dropped after reading this, primarily\nbecause I've have never touched anything as big as X.\n\nAwestruck, dumbstruck,... Xstruck. Yeah, I know I should have\nmore faith in git. Earlier I heard Wine folks are running git\nin parallel with CVS as their dual primary SCM now, and of\ncourse git is the primary SCM for the Linux kernel project.\n\nFor things like the source code management, it takes a new\nsoftware to be at least 10 times as good as the one that has\nbeen used, because switching _is_ a pain no matter how well tool\nhelps the transition. You have to transition not just the\nrepository, but people who interact with it.\n\nWhen the Linux kernel switched, it was not that hard to be\ninfinitely better than the previous one. Because the previous\none was no longer available to the kernel community; git did not\nhave to be 10 times better on technical merits alone when the\ntransition happened.\n\nCan I hear experiences from other big projects that tried to use\ngit [*1*]? I suspect there are many that have tried, and I\nwould not be surprised at all if git did not work out well for\nthem. For projects that already run on a (free) SCM, I would be\nvery surprised if the developers find the current git 10 times\nbetter than the SCM they have been using (probably with an\nexception of CVS), unless they have very specific need, such as\nparallel development of distributed nature like the Linux\nkernel.\n\nI do not do mailing list search as often as I would like to be\ndoing, but I have seen some projects tried and went back to CVS.\nWe would learn much from our failures to support them -- what\nthose people found lacking.\n\n\n[Foornote]\n\n*1* Please limit yourselves to reasonably well-known \"it is\nsurprising you haven't heard of this project\" kind...\n"},{"id":"15185","messageId":"118833cc0601281814i503bf934ge32b12e7b090c44@mail.gmail.com","threadId":"3153","inReplyTo":"7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2006-01-29T02:14:26Z","receivedAt":"2006-01-29T02:14:26Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"> Can I hear experiences from other big projects that tried to use\n> git [*1*]? I suspect there are many that have tried, and I\n> would not be surprised at all if git did not work out well for\n> them.\n\nI've been playing with Gnumeric under git.\n\n-rw-rw-r-- 1 welinder research 270M Nov 5 09:46\ngnumeric/.git/objects/pack/pack-91291de5477ddd06545b052460239b3dae89ad72.pack\n\n270M is about 40% of the cvs repository size. Given\ncompression I would have expected bigger savings.\n\nConversion isn't perfect, probably because the cvs tree has\nseen some hacking over the years. (I am not posting the URL\nbecause I don't want to kill gnome.org.)\n\nWe haven't switched yet, but I expect that we will. We are\nlooking for (in no particular order):\n\n1. Offline history.\n2. Patch sets and other things that'll make it easier to maintain\n more than one branch.\n\nIn other words, pretty-much anything but cvs will fit the bill, :-./\n\nM.\n"},{"id":"15186","messageId":"7v7j8jpu48.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"118833cc0601281814i503bf934ge32b12e7b090c44@mail.gmail.com","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-29T03:53:43Z","receivedAt":"2006-01-29T03:53:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Morten Welinder writes:\n\n>> Can I hear experiences from other big projects that tried to use\n>> git [*1*]? I suspect there are many that have tried, and I\n>> would not be surprised at all if git did not work out well for\n>> them.\n>\n> I've been playing with Gnumeric under git.\n> ...\n> We haven't switched yet, but I expect that we will...\n\nI might have sounded as if I was looking for failure report, but\nsuccess stories are of course welcome ;-). It's always good to\nhear their git experiences first-hand from people in the top\nechelon of public projects.\n\n> 270M is about 40% of the cvs repository size. Given\n> compression I would have expected bigger savings.\n\nI think that 40% sounds about right. My understanding of the\nunderlying format CVS uses, RCS, is that it stores an full copy\nof the tip of trunk uncompressed, and other versions of the file\nare represented as incremental delta from that. The packed git\nformat does not favor particular version based on the distance\nfrom the tip, and stores either a compressed full copy, or a\ndelta from some other revision (which may not necessarily be\nrepresented as a full copy). When we store something as a delta\nfrom something else, we limit the length of the delta chain to a\nfull copy to 10 (by default), so that you can get to a specific\nobject with at most 10 applications of delta on top of a full\ncopy.\n\nComparing these two formats for storage efficiency is tricky:\n\n - A full copy of the version at the tip in CVS is not\n compressed but in git a full copy is compressed -- zlib gives\n 50% for typical text sources -- git has some advantage here.\n\n - Because of delta-length limit, we store full copy, albeit\n compressed [*1*], every ten or so versions. This trades off\n storage effciency for run-time efficiency.\n\n - CVS storage records most things as delta for a long-lived\n project, and delta are less compressible (IOW, you could\n think of them as already compressed somewhat), so it is not\n _that_ inefficient to begin with.\n\n - Delta representation is used only when representing something\n as a delta from something else buys as enough space reduction\n than compressing it as a full copy in git. This is a pure\n improvement from the CVS format.\n\n[Footnote]\n\n*1* You could make different trade-off by using --depth flag\nwhen running git-pack-objects.\n"},{"id":"15192","messageId":"1138529385.9919.185.camel@evo.keithp.com","threadId":"3153","inReplyTo":"7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-01-29T10:09:45Z","receivedAt":"2006-01-29T10:09:45Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Sat, 2006-01-28 at 13:08 -0800, Junio C Hamano wrote:\n> Keith Packard writes:\n> \n> > Once we're happy with the import, I'm pretty sure we'll just switch\n> > cairo over to git and dump the CVS bits. X.org is a harder case, for\n> > that I suspect we'll migrate individual modules over one at a time,\n> > perhaps starting with the core X server pieces so that I can get my work\n> > done, have it published in the main repository and not have it also\n> > break everyone else's X server.\n> \n> Wow....... You are switching Cairo and X.org from CVS to git?\n\nWe're not switching 'X.org', we're switching the X server core. X.org is\nnow broken into many separate projects, and each one will get to choose\nSCM on their own. I expect to migrate the ones I maintain and use to\ngit, but migration of the dead code is unlikely to ever happen (and\nthere's lots of dead code) \n\n> It could be that anything is better than CVS these days, but I\n> have to admit that my jaw dropped after reading this, primarily\n> because I've have never touched anything as big as X.\n> \n> Awestruck, dumbstruck,... Xstruck. Yeah, I know I should have\n> more faith in git. Earlier I heard Wine folks are running git\n> in parallel with CVS as their dual primary SCM now, and of\n> course git is the primary SCM for the Linux kernel project.\n> \n> For things like the source code management, it takes a new\n> software to be at least 10 times as good as the one that has\n> been used, because switching _is_ a pain no matter how well tool\n> helps the transition. You have to transition not just the\n> repository, but people who interact with it.\n\nFortunately, there are very few people involved with any specific piece\nof the X.org distribution; there's really only one or two people\nactively developing the X.org core server, so that part of the migration\nwill be easy. Our users will be stuck, but there aren't many of them\neither, and git makes just sucking the current bits pretty easy. \n \n> When the Linux kernel switched, it was not that hard to be\n> infinitely better than the previous one. Because the previous\n> one was no longer available to the kernel community; git did not\n> have to be 10 times better on technical merits alone when the\n> transition happened.\n\ngit really does look 10x better than CVS at this point; mostly social\nissues are now blocking X development as weaker developers are refused\naccess to source code management to protect the project from damage. git\neliminates that barrier, and should let many new developers experiment\nand share their results without affecting my work\n\n> Can I hear experiences from other big projects that tried to use\n> git [*1*]? I suspect there are many that have tried, and I\n> would not be surprised at all if git did not work out well for\n> them. For projects that already run on a (free) SCM, I would be\n> very surprised if the developers find the current git 10 times\n> better than the SCM they have been using (probably with an\n> exception of CVS), unless they have very specific need, such as\n> parallel development of distributed nature like the Linux\n> kernel.\n\nEveryone *wants* parallel distributed development, CVS prevents it.\nAnd, remember that this is *not* a huge project, the core X server is\nonly 2M lines of source code. We separate out all of the drivers,\nlibraries and applications. Doing the migration in pieces allows us to\nincrementally affect developers, and repair issues without suspending\nall development.\n\nI don't know of other huge projects moving to git; it's not all that\ninteresting as we know the tool is stable and will scale to support our\nproject already. Also, hg and bzr are not ready for production use in my\nopinion; hg as it appears likely a flag day will be required before 1.0,\nand bzr because they didn't focus on repository format, and have\nsuggested that they will switch to a hash-addressed scheme at some point\nin the future...\n \n-- \nkeith.packard@intel.com\n"},{"id":"15193","messageId":"20060129101225.GA4815@c165.ib.student.liu.se","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601280047240.2909@evo.osdl.org","subject":"Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2006-01-29T10:12:25Z","receivedAt":"2006-01-29T10:12:25Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Sat, Jan 28, 2006 at 12:53:31AM -0500, Linus Torvalds wrote:\n> \n> \n> On Sat, 28 Jan 2006, Martin Langhoff wrote:\n> > \n> > BTW, have you still got that patch to git-merge to seed the commit msg\n> > with conflicted files? ;-)\n> \n> Nope. But it was something like the appended (totally untested, and \n> slightly improved).\n> \n> The point being that we'd fill in a template that the committer will \n> hopefully edit to explain what he did to fix up the merge for each file \n> that had conflicts.\n> \n\n\nWould it make sense to add an optional\n\n mergeresult \n\nline to merge commit objects? Here is supposed to be a SHA1 of\nthe tree object which corresponds to the result of the automatic part\nof a merge. Hence, for a given merge commit which had conflicts\n\"git-diff-tree \" would give a diff\nwhich shows the changes that was applied to resolve the conflict.\n\nWhen the recursive merge strategy is used we actually write the\n'mergeresult' tree object to the object database, so this thing should\nbe straight forward to implement in that case. If there is interest it\ncould be implemented for the resolve strategy too.\n\nI think those mergeresult lines might be useful when implementing\ngit-annotate across merges too. It makes it easy to distinguish\nchanges which came from the merged branches and changes introduced in\nthe merge itself.\n\nIt would not be backwards compatible with the current git though...\n\n- Fredrik\n"},{"id":"15194","messageId":"43DCA495.9040301@gorzow.mm.pl","threadId":"3153","inReplyTo":"1138529385.9919.185.camel@evo.keithp.com","subject":"Re: [Census] So who uses git?","fromName":"Radoslaw Szkodzinski","fromEmail":"astralstorm@gorzow.mm.pl","sentAt":"2006-01-29T11:18:45Z","receivedAt":"2006-01-29T11:18:45Z","isPatch":false,"sender":{"key":"astralstorm@gorzow.mm.pl","avatar":null},"body":"Keith Packard wrote:\n> Fortunately, there are very few people involved with any specific piece\n> of the X.org distribution; there's really only one or two people\n> actively developing the X.org core server, so that part of the migration\n> will be easy. Our users will be stuck, but there aren't many of them\n> either, and git makes just sucking the current bits pretty easy. \n> \n\nNot under Windows (bleh), but it's support for Cygwin is getting better\nand better.\n\n> I don't know of other huge projects moving to git; it's not all that\n> interesting as we know the tool is stable and will scale to support our\n> project already. Also, hg and bzr are not ready for production use in my\n> opinion; hg as it appears likely a flag day will be required before 1.0,\n\nI haven't seen any such flag day since 0.3. Repository format seems\nstable, except rename and modes support (these will be added in a\ncompatible way I think).\n0.8 release is imminent (today or tomorrow).\n\nI personally wouldn't mind git - it's great.\n\nThe only drawback is local cloning. This operation is like 4x slower\nthan plain copying of the repository. Probably because it works like an\nssh clone - creates a pack, copies it, then unpacks. This is just\ninefficient on a local machine.\n\n> and bzr because they didn't focus on repository format, and have\n> suggested that they will switch to a hash-addressed scheme at some point\n> in the future...\n> \n\nNot only that - they don't have an efficient network transfer protocol.\n(they use HTTP walkers, not even supporting persistent connections and\nalso do too many DNS lookups)\nThis is very unfortunate, especially for large projects.\n(branching Linux would take 3 days I think)\n\n-- \nGPG Key id: 0xD1F10BA2\nFingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2\n\nAstralStorm\n\n"},{"id":"15202","messageId":"118833cc0601290619k1e9c6bb8gc63937f1a2d2b31e@mail.gmail.com","threadId":"3153","inReplyTo":"7v7j8jpu48.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2006-01-29T14:19:23Z","receivedAt":"2006-01-29T14:19:23Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"> I think that 40% sounds about right. My understanding of the\n> underlying format CVS uses, RCS, is that it stores an full copy\n> of the tip of trunk uncompressed, and other versions of the file\n> are represented as incremental delta from that. The packed git\n> format does not favor particular version based on the distance\n> from the tip, and stores either a compressed full copy, or a\n> delta from some other revision (which may not necessarily be\n> represented as a full copy). When we store something as a delta\n> from something else, we limit the length of the delta chain to a\n> full copy to 10 (by default), so that you can get to a specific\n> object with at most 10 applications of delta on top of a full\n> copy.\n\nIf I understand this right, that means that for a log file (in this\ncase a ChangeLog file) that is appended to linearly as a\nfunction of revision number, we have...\n\ncvs: O(n) archive size\ngit: O(n*n) archive size\n\nAt least that is what we get if revision N is always deltad over\nrevision N-1. A good deal could be saved if instead of dumping\na full copy every 10 revisions, that revision would instead be\ndeltad off an earlier revision, but I think it'll still be O(n*n).\n\n(/me prepares for Linus chiming in and telling me I should not\nkeep ChangeLog files, :-)\n\nM.\n"},{"id":"15206","messageId":"20060129181240.GA11721@kroah.com","threadId":"3153","inReplyTo":"43DCA495.9040301@gorzow.mm.pl","subject":"Re: [Census] So who uses git?","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2006-01-29T18:12:40Z","receivedAt":"2006-01-29T18:12:40Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Sun, Jan 29, 2006 at 12:18:45PM +0100, Radoslaw Szkodzinski wrote:\n> \n> The only drawback is local cloning. This operation is like 4x slower\n> than plain copying of the repository. Probably because it works like an\n> ssh clone - creates a pack, copies it, then unpacks. This is just\n> inefficient on a local machine.\n\nHave you tried the \"-l\" option for cloneing locally? It's _very_ fast,\neven for my tiny little old laptop.\n\nIf you add a \"-n\" that will not checkout the source tree, so you can\ncompare the time of cloning with the checkout portion.\n\nthanks,\n\ngreg k-h\n"},{"id":"15211","messageId":"20060129183731.GE19685@redhat.com","threadId":"3153","inReplyTo":"7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Dave Jones","fromEmail":"davej@redhat.com","sentAt":"2006-01-29T18:37:31Z","receivedAt":"2006-01-29T18:37:31Z","isPatch":false,"sender":{"key":"davej@redhat.com","avatar":null},"body":"On Sat, Jan 28, 2006 at 01:08:54PM -0800, Junio C Hamano wrote:\n > Can I hear experiences from other big projects that tried to use\n > git [*1*]? I suspect there are many that have tried, and I\n > would not be surprised at all if git did not work out well for\n > them. For projects that already run on a (free) SCM, I would be\n > very surprised if the developers find the current git 10 times\n > better than the SCM they have been using (probably with an\n > exception of CVS), unless they have very specific need, such as\n > parallel development of distributed nature like the Linux\n > kernel.\n\nI've found switching from cvs->git even for small projects has\nmade me more productive. In part because it's got me away from\nthe 'check in to a centralised server like sourceforge' mentality,\nwithout the need to set up a local cvs server of my own.\nAdding changesets to a small project like x86info, now takes\nseconds, whereas it used to take minutes of thumb-twiddling whilst\nI waited for sf.net to do its thing. The ability to check in\nchangesets locally whilst I'm travelling, and then push them when\nI have network connectivity again is also a massive productivity\nwin over cvs.\n\nThere's also another git usage that I doubt I'm alone in doing.\nI regularly use git to import cvs trees from sourceforge etc for\nrandom projects, because I now find browsing history of projects\nwith tools like gitk much nicer than any cvs tool I've used.\n(cvs annotate is the only thing I really miss).\n\nWhat would be really cool, would be a web page pointing to public\nconversions of various projects cvs trees, so that everyone doesn't\nhave to keep hammering various repos to do the conversions themselves.\n(Sort of a pseudo bkbits.net).\n\n\t\tDave\n"},{"id":"15218","messageId":"7vslr6kcz7.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"118833cc0601290619k1e9c6bb8gc63937f1a2d2b31e@mail.gmail.com","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-29T20:15:08Z","receivedAt":"2006-01-29T20:15:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Morten Welinder writes:\n\n> If I understand this right, that means that for a log file (in this\n> case a ChangeLog file) that is appended to linearly as a\n> function of revision number, we have...\n>\n> cvs: O(n) archive size\n> git: O(n*n) archive size\n>\n> At least that is what we get if revision N is always deltad over\n> revision N-1. A good deal could be saved if instead of dumping\n> a full copy every 10 revisions, that revision would instead be\n> deltad off an earlier revision, but I think it'll still be O(n*n).\n\nI have not counted O()rders, but it is not as simple as that,\nbecause we do not really compare \"versions\". If version N\nreverts a change version N-1 introduced since version N-2, we\nwould not even store a copy for version N and version N-2\nseparately. We just store a single copy, which may be delta\ninformation against version N-1 (or the other way around and N-1\nmight be delta against N).\n\nFor the sake of math, let's say this project keeps only one\nfile, append only ChangeLog, with a straight line of development\nwithout branches (\"single strand of pearls\"), and has revisions\n1..N.\n\nIn RCS, you would have a full copy of the revision N, and\nrevision J is recorded as delta from revision J+1 for 1 <= J < N.\nThis delta is similar to \"ed\" script, and going backwards in the\nhistory for the ChangeLog example means only line deletion is\ninvolved, so what was removed is not recorded. It records how\nmany lines are removed from where. This is _very_ efficient and\ncompact.\n\nIn git, we would have a full copy of version N (because we favor\nkeeping larger blob associated with newer commits as a full\ncopy), and essentially the same thing as RCS happens. The only\ndifference is that our \"delta\" is binary delta, but in this\ncase, it just records \"copy N bytes from here to here\" which\nresults in about the same amount of information to represent\neach delta. As you say, if (10 < N), we would have a full copy\nevery once in a while. You could use depth other than the\ndefault to make this chaining longer and if you did so, your\nrepository would be *very* compactly compressed.\n\nHowever, retrieving cost of version 1 is quite different. RCS\nformat is O(n) -- you start from the tip, extract and interpret\n(N-1) deltas and apply them in turn to get to what you want.\n\nThe cost of extracting an arbitrary version is bounded in git\npackfile, because you need to do such an \"extract, interpret and\napply\" at most $depth cycles. This is primarily because we do\nnot store \"versions\" but individual objects, and do not apply\n\"newer revisions are far more likely to be accessed often\"\nheuristics, which RCS format is designed for.\n"},{"id":"15221","messageId":"7vhd7mkcyz.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"20060129101225.GA4815@c165.ib.student.liu.se","subject":"Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-29T20:15:16Z","receivedAt":"2006-01-29T20:15:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Kuivinen writes:\n\n> Would it make sense to add an optional\n>\n> mergeresult \n>\n> line to merge commit objects?\n\nTwo issues and a half.\n\n(1) Not all conflicting merge cases can write a sensible\n \"conflicted intermediate auto-merge result\". Look for cases\n where we punt in git-merge-one-file.\n\n(2) Modulo issue (1), it can be re-computed if and when needed,\n so this is akin to \"storing rename information in the commit\n by detecting renames while merging\".\n\n(3) Depending on the direction you pull, you would have\n logically the same \"conflicted auto-merge result\" that has\n <<< === >>> delimited hunks in reverse. Which one should\n you record?\n\nAnd annotate would not be helped much -- if it is needed you\ncould recompute it at that point. Annotate needs to look at the\ndiff from each parent _anyway_ to assign blames.\n\nBy the way, I brought up the issue (3) because it relates to how\nmy latest toy \"git rerere\" works ;-).\n"},{"id":"15220","messageId":"Pine.LNX.4.64.0601291438251.25300@iabervon.org","threadId":"3153","inReplyTo":"20060129183731.GE19685@redhat.com","subject":"Re: [Census] So who uses git?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-01-29T20:17:24Z","receivedAt":"2006-01-29T20:17:24Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 29 Jan 2006, Dave Jones wrote:\n\n> On Sat, Jan 28, 2006 at 01:08:54PM -0800, Junio C Hamano wrote:\n> > Can I hear experiences from other big projects that tried to use\n> > git [*1*]? I suspect there are many that have tried, and I\n> > would not be surprised at all if git did not work out well for\n> > them. For projects that already run on a (free) SCM, I would be\n> > very surprised if the developers find the current git 10 times\n> > better than the SCM they have been using (probably with an\n> > exception of CVS), unless they have very specific need, such as\n> > parallel development of distributed nature like the Linux\n> > kernel.\n> \n> I've found switching from cvs->git even for small projects has\n> made me more productive. In part because it's got me away from\n> the 'check in to a centralised server like sourceforge' mentality,\n> without the need to set up a local cvs server of my own.\n> Adding changesets to a small project like x86info, now takes\n> seconds, whereas it used to take minutes of thumb-twiddling whilst\n> I waited for sf.net to do its thing. The ability to check in\n> changesets locally whilst I'm travelling, and then push them when\n> I have network connectivity again is also a massive productivity\n> win over cvs.\n> \n> There's also another git usage that I doubt I'm alone in doing.\n> I regularly use git to import cvs trees from sourceforge etc for\n> random projects, because I now find browsing history of projects\n> with tools like gitk much nicer than any cvs tool I've used.\n> (cvs annotate is the only thing I really miss).\n\nI think this is the real driving factor for git adoption: it doesn't have \nto be 10x better for people to use it, because individuals can use it for \ninteracting with CVS projects without causing anybody else any pain. It \ndoesn't just enable distributed development, it enables a distributed \nchoice of SCM, which means a much lower activation energy threshold. I \nthink we'll see a lot more adoption when we have a CVS daemon interface \n(so projects can stop having a CVS repository, and support both sorts of \nusers with a git repository and have better metadata), and also if someone \nsets up a place for putting git imports of CVS projects, so people will \nknow that other people are using git.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"15225","messageId":"46a038f90601291229u3d357b7ci98109656e432e891@mail.gmail.com","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601291438251.25300@iabervon.org","subject":"Re: [Census] So who uses git?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-29T20:29:53Z","receivedAt":"2006-01-29T20:29:53Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/30/06, Daniel Barkalow wrote:\n> > There's also another git usage that I doubt I'm alone in doing.\n> > I regularly use git to import cvs trees from sourceforge etc for\n> > random projects, because I now find browsing history of projects\n> > with tools like gitk much nicer than any cvs tool I've used.\n> > (cvs annotate is the only thing I really miss).\n>\n> I think this is the real driving factor for git adoption: it doesn't have\n> to be 10x better for people to use it, because individuals can use it for\n> interacting with CVS projects without causing anybody else any pain.\n\nIMHO, this is a killer feature of GIT. From a CVS/SVN user point of\nview, it has vendor branches done right. At work, we do that with\nMoodle, Elgg, EPrints and GForge. And the list is growing. That's why\nI'm working on the toolchain to make interop with CVS smooth so I can\nland patches in upstream projects where I have cvs access.\n\ncheers,\n\n\nm\n"},{"id":"15258","messageId":"43DE2F7F.7090006@codeweavers.com","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601291438251.25300@iabervon.org","subject":"Re: [Census] So who uses git?","fromName":"Mike McCormack","fromEmail":"mike@codeweavers.com","sentAt":"2006-01-30T15:23:43Z","receivedAt":"2006-01-30T15:23:43Z","isPatch":false,"sender":{"key":"mike@codeweavers.com","avatar":null},"body":"\nDaniel Barkalow wrote:\n> I think we'll see a lot more adoption when we have a CVS daemon interface \n> (so projects can stop having a CVS repository, and support both sorts of \n> users with a git repository and have better metadata), and also if someone \n> sets up a place for putting git imports of CVS projects, so people will \n> know that other people are using git.\n\nThe Wine project is using a GIT repository which is mirrored into CVS. \nAlexandre wrote scripts to mirror GIT commits into CVS, so developers \ncan use whichever they're more comfortable with, and the CVS repository \nremains up to date.\n\nWe've found that patch submitters using GIT tend to send multiple \npatches per day, and that those using CVS tend to send a patch or two \noccasionally or just keep up to date with the source.\n\nMike\n"},{"id":"15270","messageId":"20060130185822.GA24487@hpsvcnb.fc.hp.com","threadId":"3153","inReplyTo":"7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Carl Baldwin","fromEmail":"cnb@fc.hp.com","sentAt":"2006-01-30T18:58:22Z","receivedAt":"2006-01-30T18:58:22Z","isPatch":false,"sender":{"key":"cnb@fc.hp.com","avatar":null},"body":"Junio,\n\nYou don't seem to give git enough credit. I am a hardware engineer with\nmany softwareish responsibilities. One of those is to keep up to date\nwith the many commercial and free SCM type tools that are available.\n\nGit has become my SCM tool of choice for many reasons.\n\n- Anyone can install and fire it up without license/contract hassles.\n\n- The infrastructure barriers to getting a project started with git are\n about as low as they can be.\n\n- Geographically distributed teams even inside a corporation are\n becoming more common. Git's repository design meets this need\n perfectly.\n\n- The repository is also to designed to be inherently safe from\n data-loss and corruption even in the face of concurrent writes due to\n each objects' immutable nature.\n\n- While on the subject of the repository. Good job keeping it simple.\n I was able to learn pretty much all there is to know from a technical\n stand-point about the objects and refs directories in an afternoon.\n It follows a principle I always work toward myself. \"Make it simple\n enough that there are obviously no difficiencies rather than making it\n complicated so that there are no obvious difficiencies.\"\n\n- In my opinion git is flexible enough to support just about any\n development/build/release flow that one can think of. Most of the\n free tools (including subversion and arch) make branching and merging\n --- on which most of these flows rely --- way too heavy-weight. Git\n shows how light-weight it can be.\n\n Not only can parallel development happen easily between\n users/repositories but parallel development is trivial even within the\n same repository. I think your 'pu' system illustrates how powerful\n it can be. I myself have had up to four concurrent branches where I\n implemented four different features in parallel in the same repository\n easily switching between them. It was almost too easy to bring them\n together using merge as each one finished.\n\n I was just reading through an article on how to choose an SCM last\n week and I kept thinking how git could be used to meet almost every\n one (if not all) of the needs discussed.\n\n- Git supports enough network protocols to make it immediately useful in\n about any situation with firewalls and such. This is where it leaves\n monotone behind.\n\nThe biggest hurdle that I've seen in adopting git is training the users.\nI myself took to it like a duck to water but I've found that even some\nof my brightest colleages have trouble wrapping their heads around it.\nCurrently, I'm trying to look at what parts they are having the most\ntrouble with. In general, I think it is grasping the reason for the\nindex file and how git commands like git-commit and git-diff interact\nwith it.\n\nEven so, I've always appreciated those tools that may have a steeper\nlearning curve but that pay dividends over time. Also, I should mention\nthat this learning curve has been flattening over time as git has\ndeveloped and obtained more porcelainish commands.\n\nCarl\n\nOn Sat, Jan 28, 2006 at 01:08:54PM -0800, Junio C Hamano wrote:\n> Keith Packard writes:\n> \n> Wow....... You are switching Cairo and X.org from CVS to git?\n> \n> It could be that anything is better than CVS these days, but I\n> have to admit that my jaw dropped after reading this, primarily\n> because I've have never touched anything as big as X.\n> \n> Awestruck, dumbstruck,... Xstruck. Yeah, I know I should have\n> more faith in git. Earlier I heard Wine folks are running git\n> in parallel with CVS as their dual primary SCM now, and of\n> course git is the primary SCM for the Linux kernel project.\n\n-- \n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n Carl Baldwin RADCAD (R&D CAD)\n Hewlett Packard Company\n MS 88 work: 970 898-1523\n 3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com\n Fort Collins, CO 80525 home: Carl@ecBaldwin.net\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n"},{"id":"15328","messageId":"20060130225107.GA3857@limbo.home","threadId":"3153","inReplyTo":"43DCA495.9040301@gorzow.mm.pl","subject":"Re: [Census] So who uses git?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-30T22:51:07Z","receivedAt":"2006-01-30T22:51:07Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Radoslaw Szkodzinski, Sun, Jan 29, 2006 12:18:45 +0100:\n> > Fortunately, there are very few people involved with any specific piece\n> > of the X.org distribution; there's really only one or two people\n> > actively developing the X.org core server, so that part of the migration\n> > will be easy. Our users will be stuck, but there aren't many of them\n> > either, and git makes just sucking the current bits pretty easy. \n> \n> Not under Windows (bleh), but it's support for Cygwin is getting better\n> and better.\n> \n\nI use git in cygwin for a project with more then 17k files (almost 6M lines).\nIt's real slow on ntfs (on 3.2Mhz PIV!), PITA on fat, and has some hiccups now\nand then (of the kind: \"windows unexpectedly does not have feature X, which\neverything else has\" or \"windows broke a 20-year-old feature Y\").\n\nBut its more intuitive and more powerful than any alternatives here (Perforce,\nSVN and CVS come to mind).\n"},{"id":"15289","messageId":"Pine.LNX.4.63.0601311127250.25248@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3153","inReplyTo":"20060130185822.GA24487@hpsvcnb.fc.hp.com","subject":"Re: [Census] So who uses git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-01-31T10:27:34Z","receivedAt":"2006-01-31T10:27:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 30 Jan 2006, Carl Baldwin wrote:\n\n> In general, I think it is grasping the reason for the index file and how \n> git commands like git-commit and git-diff interact with it.\n\nIMHO this is the one big showstopper. I had problems explaining the \nconcept myself.\n\nFor example, I had a hard time explaining to a friend why a git-add'ed \nfile is committed when saying \"git commit some_other_file\", but not \nanother (modified) file. Very unintuitive.\n\nCiao,\nDscho\n"},{"id":"15300","messageId":"20060131152429.GA26817@hpsvcnb.fc.hp.com","threadId":"3153","inReplyTo":"Pine.LNX.4.63.0601311127250.25248@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Census] So who uses git?","fromName":"Carl Baldwin","fromEmail":"cnb@fc.hp.com","sentAt":"2006-01-31T15:24:29Z","receivedAt":"2006-01-31T15:24:29Z","isPatch":false,"sender":{"key":"cnb@fc.hp.com","avatar":null},"body":"Its difficult to explain because it breaks away from the precedent set\nby other SCMs. I wouldn't call it a show-stopper for this reason. In\nfact, some who have wrapped their heads around the concept might call it\na valuable feature. I, myself, have found it a handy thing in certain\ncircumstances. In other circumstances I simply bypass it by adding -a\nto the command-line.\n\nThis doesn't fit my definition of a show-stopper.\n\nCarl\n\nOn Tue, Jan 31, 2006 at 11:27:34AM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 30 Jan 2006, Carl Baldwin wrote:\n> \n> > In general, I think it is grasping the reason for the index file and how \n> > git commands like git-commit and git-diff interact with it.\n> \n> IMHO this is the one big showstopper. I had problems explaining the \n> concept myself.\n> \n> For example, I had a hard time explaining to a friend why a git-add'ed \n> file is committed when saying \"git commit some_other_file\", but not \n> another (modified) file. Very unintuitive.\n> \n> Ciao,\n> Dscho\n> \n> \n\n-- \n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n Carl Baldwin RADCAD (R&D CAD)\n Hewlett Packard Company\n MS 88 work: 970 898-1523\n 3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com\n Fort Collins, CO 80525 home: Carl@ecBaldwin.net\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n"},{"id":"15301","messageId":"Pine.LNX.4.63.0601311628220.10176@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3153","inReplyTo":"20060131152429.GA26817@hpsvcnb.fc.hp.com","subject":"Re: [Census] So who uses git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-01-31T15:31:19Z","receivedAt":"2006-01-31T15:31:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 31 Jan 2006, Carl Baldwin wrote:\n\n> Its difficult to explain because it breaks away from the precedent set\n> by other SCMs. I wouldn't call it a show-stopper for this reason.\n\nI don't.\n\nThe strange concept from the user's perspective is that\n\n\tgit commit -m \"some message\" file-a.txt\n\ncan commit file-b.txt also.\n\n> [...] In other circumstances I simply bypass it by adding -a to the \n> command-line.\n\nThis is a different thing.\n\nCiao,\nDscho\n"},{"id":"15308","messageId":"Pine.LNX.4.64.0601310926330.7301@g5.osdl.org","threadId":"3153","inReplyTo":"Pine.LNX.4.63.0601311127250.25248@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-31T17:30:48Z","receivedAt":"2006-01-31T17:30:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 Jan 2006, Johannes Schindelin wrote:\n> \n> On Mon, 30 Jan 2006, Carl Baldwin wrote:\n> \n> > In general, I think it is grasping the reason for the index file and how \n> > git commands like git-commit and git-diff interact with it.\n> \n> IMHO this is the one big showstopper. I had problems explaining the \n> concept myself.\n> \n> For example, I had a hard time explaining to a friend why a git-add'ed \n> file is committed when saying \"git commit some_other_file\", but not \n> another (modified) file. Very unintuitive.\n\nI really think you should explain it one of two ways:\n\n - ignore it. Never _ever_ use git-update-index directly, and don't tell \n people about use individual filenames to git-commit. Maybe even add \n \"-a\" by default to the git-commit flags as a special installation \n addition.\n\n - talk about the index, and revel in it as a way to explain the staging \n area. This is what the old tutorial.txt did before it got simplified.\n\nThe \"ignore the index\" approach is the simple one to explain. It's \nstrictly less powerful, but hey, what else is new? \n\n\t\tLinus\n"},{"id":"15312","messageId":"20060131181248.GE11955@fieldses.org","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601310926330.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-01-31T18:12:48Z","receivedAt":"2006-01-31T18:12:48Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Jan 31, 2006 at 09:30:48AM -0800, Linus Torvalds wrote:\n> I really think you should explain it one of two ways:\n> \n> - ignore it. Never _ever_ use git-update-index directly, and don't tell \n> people about use individual filenames to git-commit. Maybe even add \n> \"-a\" by default to the git-commit flags as a special installation \n> addition.\n> \n> - talk about the index, and revel in it as a way to explain the staging \n> area. This is what the old tutorial.txt did before it got simplified.\n> \n> The \"ignore the index\" approach is the simple one to explain. It's \n> strictly less powerful, but hey, what else is new? \n\nYeah, I do wonder what's likely to be the best approach for most users.\nMy goal with the new tutorial was to get a reader doing something fun\nand useful as quickly as possible. So it just refers elsewhere for any\ndiscussion of the index file or SHA1 names. But probably everyone needs\nto pick up that stuff eventually anyway, and maybe it's better to get to\nit a little sooner, I dunno.\n\nBesides the git-add/git-commit thing, the other thing that caught me by\nsuprise was the behaviour of git reset. I expected there to be an\n\"inverse\" to git commit -a, meaning that\n\n\t1) the sequence\n\t\tgit reset HEAD^\n\t\tgit commit -a\n\t would be a no-op, in the sense that the new commit would\n\t get the same changes as the old one, and\n\t2) the sequence\n\t\tgit commit -a\n\t\tgit reset HEAD^\n\t would be a no-op, in the sense that \"git diff\" would report\n\t the same diff before and after.\n\nBut there isn't, and explaining how --soft and --mixed actually work\nrequires referring to the index file.\n\nIs that something that can be fixed in the tools or does the user\nfundamentally need to know about the index file to do this kind of\nstuff?\n\n--b.\n"},{"id":"15314","messageId":"43DFAD91.4080105@gorzow.mm.pl","threadId":"3153","inReplyTo":"20060129181240.GA11721@kroah.com","subject":"Re: [Census] So who uses git?","fromName":"Radoslaw Szkodzinski","fromEmail":"astralstorm@gorzow.mm.pl","sentAt":"2006-01-31T18:33:53Z","receivedAt":"2006-01-31T18:33:53Z","isPatch":false,"sender":{"key":"astralstorm@gorzow.mm.pl","avatar":null},"body":"Greg KH wrote:\n> On Sun, Jan 29, 2006 at 12:18:45PM +0100, Radoslaw Szkodzinski wrote:\n>> The only drawback is local cloning. This operation is like 4x slower\n>> than plain copying of the repository. Probably because it works like an\n>> ssh clone - creates a pack, copies it, then unpacks. This is just\n>> inefficient on a local machine.\n> \n> Have you tried the \"-l\" option for cloneing locally? It's _very_ fast,\n> even for my tiny little old laptop.\n\nBecause it's cp -rl and some file modifications, right?\nIt's what I've been using already.\n\nThis -l option should be more prominent in the documentation.\nMaybe it even already is. I've taught myself using git before 0.9.\n\nThank you. This helps a lot.\n\n> If you add a \"-n\" that will not checkout the source tree, so you can\n> compare the time of cloning with the checkout portion.\n\nCloning without -l option is much slower - some minutes vs below a minute.\nI could have time(8)d it, but it's no use.\n\n-- \nGPG Key id: 0xD1F10BA2\nFingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2\n\nAstralStorm\n\n"},{"id":"15315","messageId":"1138734110.18852.26.camel@evo.keithp.com","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601310926330.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-01-31T19:01:50Z","receivedAt":"2006-01-31T19:01:50Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Tue, 2006-01-31 at 09:30 -0800, Linus Torvalds wrote:\n\n> - ignore it. Never _ever_ use git-update-index directly, and don't tell \n> people about use individual filenames to git-commit. Maybe even add \n> \"-a\" by default to the git-commit flags as a special installation \n> addition.\n\nAs a newly initiated user, this would have been a more gentle\nintroduction to the system. But, it would be hard to make it entirely\ninvisible given the current interfaces. I'm not sure if obscuring the\npresense of the index is a great plan; it's already hard enough to\nfigure out how it works.\n\n-- \nkeith.packard@intel.com\n"},{"id":"15317","messageId":"Pine.LNX.4.64.0601311110210.7301@g5.osdl.org","threadId":"3153","inReplyTo":"1138734110.18852.26.camel@evo.keithp.com","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-31T19:21:52Z","receivedAt":"2006-01-31T19:21:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 Jan 2006, Keith Packard wrote:\n\n> On Tue, 2006-01-31 at 09:30 -0800, Linus Torvalds wrote:\n> \n> > - ignore it. Never _ever_ use git-update-index directly, and don't tell \n> > people about use individual filenames to git-commit. Maybe even add \n> > \"-a\" by default to the git-commit flags as a special installation \n> > addition.\n> \n> As a newly initiated user, this would have been a more gentle\n> introduction to the system. But, it would be hard to make it entirely\n> invisible given the current interfaces. I'm not sure if obscuring the\n> presense of the index is a great plan; it's already hard enough to\n> figure out how it works.\n\nNow, I do agree. I don't actually like hiding the index too much. \nUnderstanding the index is _invaluable_ whenever you're doing a merge with \nconflicts, and understanding what tools are available to you to resolve \nthose conflicts.\n\nThe index is also obviously very important when you do a partial commit, \nand it's something I do end up doing quite often. Again, maybe that's not \nsomething that a new git user should be encouraged to ever do, but it's a \nhuge convenience feature for power-users.\n\nUnderstanding the index also allows people to understand certain \nperformance-characteristics of git, and explains how \"git add\" (and \nremove, if we had one) actually works independently of the commit. \n\nSo I'm actually of the \"revel in the index\" camp (as could probably be \nguessed by the original tutorial).\n\nMy personal suggestion would be to introduce git \"gently\" by ignoring it, \nbut by the time a person actually _works_ on a project (as opposed to just \ngoing through a tutorial or following another persons project), he/she \nshould probably have been introduced to the index in order to understand \nwhat happens and to use its power.\n\n(In particular, the difference between \"git diff\" and \"git diff HEAD\" is \nan important one to understand eventually).\n\n\t\t\tLinus\n"},{"id":"15318","messageId":"7vbqxsyyym.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"20060131181248.GE11955@fieldses.org","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-31T19:33:21Z","receivedAt":"2006-01-31T19:33:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> On Tue, Jan 31, 2006 at 09:30:48AM -0800, Linus Torvalds wrote:\n>>\n>> The \"ignore the index\" approach is the simple one to explain. It's \n>> strictly less powerful, but hey, what else is new? \n>\n> Yeah, I do wonder what's likely to be the best approach for most users.\n> My goal with the new tutorial was to get a reader doing something fun\n> and useful as quickly as possible. So it just refers elsewhere for any\n> discussion of the index file or SHA1 names. But probably everyone needs\n> to pick up that stuff eventually anyway, and maybe it's better to get to\n> it a little sooner, I dunno.\n\nI think many good stuff git offers would not be helpful to the\nusers until index is understood as the third entity, in addition\nto the usual \"committed state\" and \"working tree state\". It\nmight be better to talk about it sooner rather than later. And\nthe tool is geared towards taking advantage of it, so until the\nuser understands that, behaviour of some tools would feel\nunintuitive.\n\nYou can have local throw-away modifications while applying\npatches and merging (I once broke merges by ignoring that it is\nperfectly valid to have index and working tree files be\ndifferent and keep working that way. That was a hard lesson).\nThe index file knows what working tree changes are meant to be\ncommitted. Another thing I find useful, which cannot be done\nwithout index, is to sanity check while developing. When \"git\ndiff\" gives too many diffs, running update-index on paths that I\nthink are more-or-less OK helps to reduce clutter, and I can\nview only further changes to those paths.\n\nIn a sense, update-index can be thought of to check in the\nchanges without committing. You can check in number of times,\nand the cumulative effect is committed later. \"reset --mixed\"\nis undoing these uncommitted check-ins. \"reset --hard\" undoes\nthe last commit.\n"},{"id":"15319","messageId":"1138736666.24410.38.camel@cashmere.sps.mot.com","threadId":"3153","inReplyTo":"7vbqxsyyym.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-01-31T19:44:27Z","receivedAt":"2006-01-31T19:44:27Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Tue, 2006-01-31 at 13:33, Junio C Hamano wrote:\n> \"J. Bruce Fields\" writes:\n\n> I think many good stuff git offers would not be helpful to the\n> users until index is understood as the third entity, in addition\n> to the usual \"committed state\" and \"working tree state\". It\n> might be better to talk about it sooner rather than later. And\n> the tool is geared towards taking advantage of it, so until the\n> user understands that, behaviour of some tools would feel\n> unintuitive.\n\nAgreed.\n\n> You can have local throw-away modifications while applying\n> patches and merging (I once broke merges by ignoring that it is\n> perfectly valid to have index and working tree files be\n> different and keep working that way. That was a hard lesson).\n> The index file knows what working tree changes are meant to be\n> committed. Another thing I find useful, which cannot be done\n> without index, is to sanity check while developing. When \"git\n> diff\" gives too many diffs, running update-index on paths that I\n> think are more-or-less OK helps to reduce clutter, and I can\n> view only further changes to those paths.\n\nAnd right there is where people get caught by surprise.\nWhat \"they\" then want to do is actually pick certain\nfiles to commit. And when they do, they get caught off\nguard by the _additional_ files.\n\nI have done this style of \"update-index on more-or-less OK\nfiles in order to clear up the diff. And it is also in that\ntime frame that I start feeling that certain changes belong\nto \"one commit\" or another. The result is, I want to then\npick the parts that get committed together. But _really_\nbeing certain exactly which files, and _only_ those files,\nwill really be committed is tough.\n\njdl\n"},{"id":"15320","messageId":"43DFBF9A.2020409@gorzow.mm.pl","threadId":"3153","inReplyTo":"43DFAD91.4080105@gorzow.mm.pl","subject":"Re: [Census] So who uses git?","fromName":"Radoslaw Szkodzinski","fromEmail":"astralstorm@gorzow.mm.pl","sentAt":"2006-01-31T19:50:50Z","receivedAt":"2006-01-31T19:50:50Z","isPatch":false,"sender":{"key":"astralstorm@gorzow.mm.pl","avatar":null},"body":"Radoslaw Szkodzinski wrote:\n> Cloning without -l option is much slower - some minutes vs below a minute.\n> I could have time(8)d it, but it's no use.\n> \n\nMake that time(1)d.\n\nResults for the kernel follow. Disc cache has been preheated with find.\n\ngit version: 5b2bcc7b2d546c636f79490655b3347acc91d17f\nFilesystem: ext3 data=writeback\nKernel: 2.6.16-rc1-astorm2 (mostly -ck patchset with \"hotfix\")\nElevator: CFQ\n\ntime git clone linux-2.6.git linux-2.6.git.new\nPacking 180025 objects\n\nreal 8m31.637s\nuser 3m19.571s\nsys 0m42.211s\n\nExtremely bad. The task is mostly cpu-bound.\nMade some background applications swap out late in the process.\n(that's the cause of the sys time)\n\ntime git clone -l linux-2.6.git linux-2.6.git.local\n0 blocks\n\nreal 0m42.339s\nuser 0m2.818s\nsys 0m4.040s\n\nGood enough for me. Possibly cp -rl of objects and then a checkout.\n\ntime cp -rl linux-2.6.git linux-2.6.git.rl\n\nreal 0m18.333s\nuser 0m0.103s\nsys 0m1.732s\n\nReally fast, but requires additional file modification.\n(namely .git/remotes/origin, removal of gitrc)\nAlso incompatible with apps having problems with hardlinks.\n\n-- \nGPG Key id: 0xD1F10BA2\nFingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2\n\nAstralStorm\n\n"},{"id":"15321","messageId":"7v7j8gyy2w.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"1138736666.24410.38.camel@cashmere.sps.mot.com","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-31T19:52:23Z","receivedAt":"2006-01-31T19:52:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger writes:\n\n> I have done this style of \"update-index on more-or-less OK\n> files in order to clear up the diff. And it is also in that\n> time frame that I start feeling that certain changes belong\n> to \"one commit\" or another. The result is, I want to then\n> pick the parts that get committed together. But _really_\n> being certain exactly which files, and _only_ those files,\n> will really be committed is tough.\n\n\t$ git diff --cached\n\nwould help. If you are _only_ comitting either all changes or no\nchange per path, 'git diff --cached --name-status' would be\nsufficient.\n"},{"id":"15322","messageId":"20060131200630.GB16561@fieldses.org","threadId":"3153","inReplyTo":"7vbqxsyyym.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-01-31T20:06:30Z","receivedAt":"2006-01-31T20:06:30Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Jan 31, 2006 at 11:33:21AM -0800, Junio C Hamano wrote:\n> I think many good stuff git offers would not be helpful to the\n> users until index is understood as the third entity, in addition\n> to the usual \"committed state\" and \"working tree state\". It\n> might be better to talk about it sooner rather than later. And\n> the tool is geared towards taking advantage of it, so until the\n> user understands that, behaviour of some tools would feel\n> unintuitive.\n\nYeah, makes sense. But I'd like to introduce that while still\nintroducing the higher-level tools earlier on than core-tutorial.txt\ndoes. I'll give some thought to how to move things in that direction,\nmaybe this weekend....\n\n--b.\n"},{"id":"15323","messageId":"7v8xsww2kt.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"43DFBF9A.2020409@gorzow.mm.pl","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-31T20:43:30Z","receivedAt":"2006-01-31T20:43:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Radoslaw Szkodzinski writes:\n\n> Radoslaw Szkodzinski wrote:\n>> Cloning without -l option is much slower - some minutes vs below a minute.\n>> I could have time(8)d it, but it's no use.\n>> \n>\n> Make that time(1)d.\n>\n> Results for the kernel follow. Disc cache has been preheated with find.\n\nWhile you are at it, \"git clone -l -s -n\" might be more interesting.\n"},{"id":"15324","messageId":"20060131205621.GC16561@fieldses.org","threadId":"3153","inReplyTo":"7vd5i8w2nc.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-01-31T20:56:22Z","receivedAt":"2006-01-31T20:56:22Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Jan 31, 2006 at 12:41:59PM -0800, Junio C Hamano wrote:\n> On the tutorial front, maybe we could start teaching people to\n> always use \"commit -a\", and not tell them about update-index nor\n> \"commit paths..\" at all. Have them do \"hello world\", review\n> changes since the last commit with \"git diff\", and make commit\n> with \"git commit -a\". Next tell them about index, and after\n> they understand index, finally tell them \"commit paths...\" is\n> there merely to reduce typing.\n\nYeah, I think that's approximately what you get right now if you read\ntutorial.txt followed by core-tutorial.txt, though the two currently may\nnot really work together well as sequels.\n\nSo I'm inclined to start by revising the two to make them read well as\nsequels, then maybe moving some of core-tutorial.txt into the earlier\ntutorial.txt. By the time we're done the two might end up being one\ndocument. Or they might still be two, but with the split being more\nclearly beginning/advanced instead of high-level/low-level.\n\nFeedback from people who'd actually worked through the two would\nobviously be useful.\n\n--b.\n"},{"id":"15325","messageId":"29639.194.237.142.10.1138741008.squirrel@194.237.142.10","threadId":"3153","inReplyTo":"1138734110.18852.26.camel@evo.keithp.com","subject":"Re: [Census] So who uses git?","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2006-01-31T20:56:48Z","receivedAt":"2006-01-31T20:56:48Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"> As a newly initiated user, this would have been a more gentle\n> introduction to the system. But, it would be hard to make it entirely\n> invisible given the current interfaces. I'm not sure if obscuring the\n> presense of the index is a great plan; it's already hard enough to\n> figure out how it works.\n\nI have found myself using a mixture of cogito and git commands lately.\nPart of it being that my finger type something like:\nrm `git ls-files -m`\ncg-restore\n\nand I have not convinced them about git reset --hard\n\n\nBut the primary thing is cg-commit\nI give you a list of files modified which can be edited and\nit have saved me a couple of times commiting to much.\nAnd I get vi fired up so no need to fiddle with command line argumetns.\n\n Sam\n"},{"id":"15329","messageId":"43DFD07D.7000903@gorzow.mm.pl","threadId":"3153","inReplyTo":"7v8xsww2kt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Radoslaw Szkodzinski","fromEmail":"astralstorm@gorzow.mm.pl","sentAt":"2006-01-31T21:02:53Z","receivedAt":"2006-01-31T21:02:53Z","isPatch":false,"sender":{"key":"astralstorm@gorzow.mm.pl","avatar":null},"body":"Junio C Hamano wrote:\n> Radoslaw Szkodzinski writes:\n> \n>> Radoslaw Szkodzinski wrote:\n>>> Cloning without -l option is much slower - some minutes vs below a minute.\n>>> I could have time(8)d it, but it's no use.\n>>>\n>> Make that time(1)d.\n>>\n>> Results for the kernel follow. Disc cache has been preheated with find.\n> \n> While you are at it, \"git clone -l -s -n\" might be more interesting.\n> \n> \n\nSure:\n\ntime git clone -l -s -n linux-2.6.git linux-2.6.git.lsn\n\nreal 0m0.458s\nuser 0m0.020s\nsys 0m0.027s\n\nSpeed demon. I'd use it, but I often need a checkout anyway, so...\n\ntime git clone -l -s linux-2.6.git linux-2.6.git.ls\n\nreal 0m35.752s\nuser 0m2.661s\nsys 0m2.374s\n\nNot really better than git clone -l and relies on the tools more.\nHowever, it should make for easier repacking and pruning. I'll keep it.\n\n-- \nGPG Key id: 0xD1F10BA2\nFingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2\n\nAstralStorm\n\n"},{"id":"15331","messageId":"Pine.LNX.4.64.0601311314030.7301@g5.osdl.org","threadId":"3153","inReplyTo":"20060130225107.GA3857@limbo.home","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-31T21:25:08Z","receivedAt":"2006-01-31T21:25:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 30 Jan 2006, Alex Riesen wrote:\n> \n> I use git in cygwin for a project with more then 17k files (almost 6M lines).\n> It's real slow on ntfs (on 3.2Mhz PIV!)\n\nOne thing that git does rely on is a fast \"lstat()\" system call. The index \nfile means that we almost never need to read the contents of a file to \ncompare, but git _does_ check that files haven't been modified, and doing \nan \"lstat()\" on every single file it knows about is the way to do that.\n\nNow, I suspect that you simply can't do basic filename lookups much faster \nthan Linux does them. The Linux VFS layer name caching reigns supreme: the \ndentries are just incredibly powerful, and the reason Linux kicks ass on \nmany benchmarks.\n\nAnd yes, git was designed for it. git is _really_ fast on Linux, but any \noperating system that is so stupid that it has to call down to the \nlow-level filesystem for filename lookup (which is most of them, and from \nwhat I have heard, the NT VFS layer is worse than most) will take a lot \nlonger.\n\nThis is sadly not something I think you can possibly avoid. Git is \nliterally being as fast as is humanly possible without doing explicit \nlocking. You _can_ avoid the \"lstat()\" calls if you are willing to always \nexplicitly mark files that you have changed (so that the SCM can stat just \n_those_ files and ignore all the others), but I personally much prefer \nbeing able to use any random tools on the files without having to prepare \nthem some way.\n\nSo we could speed it up on cygwin (and yes, it would speed git up a lot \neven on Linux, but since the cached lstat() case is so fast anyway, I \ndoubt a lot of Linux users care - the biggest win would be on a cold-cache \ntree). But it would require that you explicitly _mark_ the files you edit \nsome way.\n\nBtw, BK wanted that, and it wasn't _too_ painful. You had to do\n\n\tbk edit\n\nto mark a file as being ready to be dirtied, and as a helper command you \nwould use\n\n\tbk editor\n\nwhich would first do the \"bk edit\" thing and then start up your favourite \neditor (the usual ${EDITOR:${VISUAL:vi}} rules applied) on it, and it \nworked fine. We _could_ do the same in git.\n\nI'd just prefer not to.\n\nFor small projects (or big projects with fairly few files), it really \nshouldn't matter. Your 17k files example is hopefully fairly rare..\n\n> But its more intuitive and more powerful than any alternatives here (Perforce,\n> SVN and CVS come to mind).\n\nGood to know.\n\n\t\tLinus\n"},{"id":"15334","messageId":"20060131215247.GF16561@fieldses.org","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311314030.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-01-31T21:52:47Z","receivedAt":"2006-01-31T21:52:47Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Jan 31, 2006 at 01:25:08PM -0800, Linus Torvalds wrote:\n> So we could speed it up on cygwin (and yes, it would speed git up a lot \n> even on Linux, but since the cached lstat() case is so fast anyway, I \n> doubt a lot of Linux users care - the biggest win would be on a cold-cache \n> tree). But it would require that you explicitly _mark_ the files you edit \n> some way.\n\nYou couldn't depend on a combination of lstat's and some kind of\nfilesystem change notifications?\n\n--b.\n"},{"id":"15336","messageId":"20060131220148.GA19411@steel.home","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311314030.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-31T22:01:48Z","receivedAt":"2006-01-31T22:01:48Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Tue, Jan 31, 2006 22:25:08 +0100:\n> > I use git in cygwin for a project with more then 17k files (almost\n> > 6M lines). It's real slow on ntfs (on 3.2Mhz PIV!)\n> ...\n> So we could speed it up on cygwin (and yes, it would speed git up a lot \n> even on Linux, but since the cached lstat() case is so fast anyway, I \n> doubt a lot of Linux users care - the biggest win would be on a cold-cache \n> tree). But it would require that you explicitly _mark_ the files you edit \n> some way.\n\nI'd hate to have to do that. The project in question is just stuffed\nup beyond all reason, windows' VFS is a sorry piece of junk, and I\ncare much more about how comfortable the tool is.\n\n> ...\n> For small projects (or big projects with fairly few files), it really \n> shouldn't matter. Your 17k files example is hopefully fairly rare..\n\nI'd say it is fairly common. It's what driven by paranoia and\nsuffering from chronic undereducation projects in big companies\nusually end up with. Frequently right from the start...\n"},{"id":"15340","messageId":"7vzmlcrqbs.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"29639.194.237.142.10.1138741008.squirrel@194.237.142.10","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-31T22:21:43Z","receivedAt":"2006-01-31T22:21:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sam Ravnborg\" writes:\n\n> But the primary thing is cg-commit\n> I give you a list of files modified which can be edited and\n> it have saved me a couple of times commiting to much.\n> And I get vi fired up so no need to fiddle with command line argumetns.\n\n[this is what I sent in a separate message but I goofed up the\ndestination headers and the message did not appear on the list,\nso I am reprinting.]\n\nI have always felt \"git commit paths...\" was a mistake; it\nencourages partial commits by individual developers.\n\nBy \"partial commit\", I mean a commit that does not exactly match\nthe state of the working tree when the commit is made. There\nare two kinds of \"partial commits\". Good ones and bad ones.\n\nBeing able to make partial commits is handy for people whose\nprimary role is to integrate many changes from trusted\ndevelopers rather than testing each and every commit as a whole\n(read: Linus and subsystem maintainers). Integrators' job may\ninclude testing what have been merged as a whole by a compile\nand reboot cycle as the final \"wrap-up\" step, but the most\nimportant role they play is to sanity check the changes from\narchitectural perspective.\n\nFor that workflow to work effectively, however, the changes fed\nby individual developers to the integrators have to be clean and\nwell tested. A partial commit records something that never\nexisted in any working tree as a whole, so by definition it is\nan untested change. You would risk \"sorry I forgot to commit\nthe changes to these paths but without them it does not even\ncompile\", and end up wasting integrators' time.\n\nThe integrators make commits out of their working trees using\ngit-merge and git-apply to record changes made by others after\nreviewing them. These commands ignore unconflicting local\nchanges (but notices conflicting ones to operate correctly), and\nallow them to make partial commits. This is a good thing;\notherwise they would have to reset their own changes in their\nworking tree, only to do merges and to accept patches. However,\npeople playing the integrator role rarely have reason to use\n\"git commit paths...\" while merging from others to make such a\npartial commit. Only after they resolve conflicts by hand,\nperhaps. But that happens far less often than careless\nindividual developers making partial commits of bad kind using\nthe same \"git commit paths...\" command.\n\nThis is the reason why I feel \"git commit paths...\" is a bad\nfeature. It helps to make bad partial commits, without having\nto do much with making good partial commits.\n\nMany SCMs may have the ability to do \"commit paths...\", but that\ndoes not change the fact that it encourages carelessness for\nindividual developers, which is especially bad in a distributed\ndevelopment workflow like the Linux kernel style [*1*].\n\nBut that was not my change ;-).\n\n\n[Foornote]\n\n*1* It could be argued that being able to do partial commit is a\ngood thing in other SCM systems where there is no equivalent to\nour \"index\" file. It is one way for the developer to snapshot\ntheir work-in-progress state where they might later come back to\nif the approach they are currently pursuing does not pan out.\nBut for that, we have index file we can \"check into\" without\ncommitting.\n"},{"id":"15341","messageId":"20060131225514.GC2812@ca-server1.us.oracle.com","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311110210.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2006-01-31T22:55:14Z","receivedAt":"2006-01-31T22:55:14Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Tue, Jan 31, 2006 at 11:21:52AM -0800, Linus Torvalds wrote:\n> Now, I do agree. I don't actually like hiding the index too much. \n> Understanding the index is _invaluable_ whenever you're doing a merge with \n> conflicts, and understanding what tools are available to you to resolve \n> those conflicts.\n\n\tThis is precisely the experience I've had explaining GIT to\nfolks moving to it. The simplest workflow (clone; hack one file, commit\none file) is so similar to CVS/Subversion/Anything that it's immediately\nunderstood. But when pull, push, merge, and any non-linear history are\ndiscussed, I have to describe the index and the commit/tree layout.\nOnce I do, they get it.\n\n> So I'm actually of the \"revel in the index\" camp (as could probably be \n> guessed by the original tutorial).\n\n\tI'm going to second this, from a real-world \"explain it to\nothers\" standpoint.\n\nJoel\n\n-- \n\n\"Every day I get up and look through the Forbes list of the richest\n people in America. If I'm not there, I go to work.\"\n - Robert Orben\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"15343","messageId":"Pine.LNX.4.64.0601311750270.25300@iabervon.org","threadId":"3153","inReplyTo":"Pine.LNX.4.63.0601311127250.25248@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Census] So who uses git?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-01-31T23:16:26Z","receivedAt":"2006-01-31T23:16:26Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 31 Jan 2006, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Mon, 30 Jan 2006, Carl Baldwin wrote:\n> \n> > In general, I think it is grasping the reason for the index file and how \n> > git commands like git-commit and git-diff interact with it.\n> \n> IMHO this is the one big showstopper. I had problems explaining the \n> concept myself.\n> \n> For example, I had a hard time explaining to a friend why a git-add'ed \n> file is committed when saying \"git commit some_other_file\", but not \n> another (modified) file. Very unintuitive.\n\nI sort of suspect that \"git commit some_other_file\" should really read \nHEAD into a temporary index, update \"some_other_file\" in that (and the \nmain index), and commit it. The concept of the index isn't hard (it's the \npreparation you've made so far towards a commit), and plain \"git commit\" \nmakes sense with it; \"git commit -a\" also makes sense, since committing \nall changes is pretty clear. The surprising thing is that \"git commit path \n...\" means \"everything I've already mentioned, plus path...\" not just \n\"path ...\", and it's particularly surprising because people only tend to \nspecify paths when they've done something they don't want to commit.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"15346","messageId":"20060131233612.GC31278@pasky.or.cz","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311750270.25300@iabervon.org","subject":"Re: [Census] So who uses git?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-01-31T23:36:12Z","receivedAt":"2006-01-31T23:36:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Feb 01, 2006 at 12:16:26AM CET, I got a letter\nwhere Daniel Barkalow said that...\n> On Tue, 31 Jan 2006, Johannes Schindelin wrote:\n> \n> > Hi,\n> > \n> > On Mon, 30 Jan 2006, Carl Baldwin wrote:\n> > \n> > > In general, I think it is grasping the reason for the index file and how \n> > > git commands like git-commit and git-diff interact with it.\n> > \n> > IMHO this is the one big showstopper. I had problems explaining the \n> > concept myself.\n> > \n> > For example, I had a hard time explaining to a friend why a git-add'ed \n> > file is committed when saying \"git commit some_other_file\", but not \n> > another (modified) file. Very unintuitive.\n> \n> I sort of suspect that \"git commit some_other_file\" should really read \n> HEAD into a temporary index, update \"some_other_file\" in that (and the \n> main index), and commit it.\n\nFWIW, this is also what cg-commit does.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"15349","messageId":"7vek2oot7z.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311750270.25300@iabervon.org","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-31T23:47:28Z","receivedAt":"2006-01-31T23:47:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> I sort of suspect that \"git commit some_other_file\" should really read \n> HEAD into a temporary index, update \"some_other_file\" in that (and the \n> main index), and commit it.\n> ...\n> The surprising thing is that \"git commit path ...\" means\n> \"everything I've already mentioned, plus path...\" not just\n> \"path ...\", and it's particularly surprising because people\n> only tend to specify paths when they've done something they\n> don't want to commit.\n\nInteresting idea, and a good point.\n\nNot that I particularly would like to encourage people to make\npartial commits by making it easier, but as long as we allow our\nusers to say \"commit path...\", your proposal would reduce the\nconfusion.\n\nI wonder which is faster, to check if index differs from HEAD\nand do the temporary index only when they differ, or always use\na temporary without checking? The former needs one diff-index\n--cached, zero or one read-tree, one write-tree and one\ncommit-tree. The latter always needs one read-tree, one\nwrite-tree and one commit-tree.\n\nWait. We already do diff-index --cached during git-commit\nanyway (it is in git-status). Maybe with a bit of code\nrestructuring we can do the temporary index part optional.\n"},{"id":"15350","messageId":"Pine.LNX.4.64.0601311623240.7301@g5.osdl.org","threadId":"3153","inReplyTo":"7vek2oot7z.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T00:38:50Z","receivedAt":"2006-02-01T00:38:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 Jan 2006, Junio C Hamano wrote:\n> Daniel Barkalow writes:\n> \n> > I sort of suspect that \"git commit some_other_file\" should really read \n> > HEAD into a temporary index, update \"some_other_file\" in that (and the \n> > main index), and commit it.\n> > ...\n> > The surprising thing is that \"git commit path ...\" means\n> > \"everything I've already mentioned, plus path...\" not just\n> > \"path ...\", and it's particularly surprising because people\n> > only tend to specify paths when they've done something they\n> > don't want to commit.\n> \n> Interesting idea, and a good point.\n\nOne thing to be careful about is merges.\n\nThis actually happens to me:\n\n\tgit pull ....\n\n\t.. uhhuh, trivial conflict in one file ..\n\t.. edit the/file/that/conflicted ..\n\n\tgit commit the/file/that/conflicted\n\nand there is no way that it would ever be correct to then just commit that \none file. The fact that it's a merge means that the rest of the index - \nwhich is all from the merge, and correct - absolutely _must_ be committed \ntoo.\n\nAnd yes, I could use \"git commit -a\" (and I often do), but the thing is, I \nsurprisingly often have edits in unrelated files (stuff that the merge \nnever touched), and doing \"git commit -a\" would do the wrong thing.\n\nSo the current \"git commit filename\" behaviour is actually the only \npossible correct one for a merge. Nothing else makes any sense \nwhat-so-ever.\n\nNow, I can hear people arguing that \"ok, merges are special, and for \nmerges we always do it in the current index\", but that makes \"git commit \npathname\" act very _differently_ for a merge than for a normal commit. \nThat just smells wrong to me.\n\nSo if you do this change (which may be the right one) then please make \nsure that \"git commit \" doesn't work _at_all_ when a merge is in \nprogress (ie MERGE_HEAD exists), because it would do the wrong thing.\n\nAnd yes, then I'll just have to force my fingers to do a simple\n\n\tgit-update-index filename\n\tgit commit\n\ninstead. I can do that.\n\nOh, one final suggestion: if you give a filename to \"git commit\", and you \ndo the new semantics which means something _different_ than \"do a \ngit-update-index on that file and commit\", then I'd really suggest that \nthe _old_ index for that filename should match the parent exactly. \nOtherwise, you may have done a\n\n\tgit diff filename\n\nand you _thought_ you were committing just a two-line thing (because you \ndidn't understand about the index), but another, earlier, action caused \nthe index to be different from the file you had in HEAD, and in reality \nyou're actually committing a much bigger diff.\n\nIn other words: if you want \"git commit \" to _not_ care about \nthe current index, then it should make sure that the index at least \n_matches_ the current HEAD in the files mentioned.\n\nIe \"git-diff-index --cached HEAD \" should return empty. Or \nsomething like that.\n\n\t\t\tLinus\n"},{"id":"15353","messageId":"7vek2noq75.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311623240.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T00:52:46Z","receivedAt":"2006-02-01T00:52:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> One thing to be careful about is merges.\n> ...\n> So the current \"git commit filename\" behaviour is actually the only \n> possible correct one for a merge. Nothing else makes any sense \n> what-so-ever.\n\nAgreed 100%, and I kind of feel silly about not mentioning that\nmyself. It _might_ even make sense to reject explicit filenames\nwhen MERGE_HEAD does not exist ;-).\n\n> Oh, one final suggestion: if you give a filename to \"git\n> commit\", and you do the new semantics which means something\n> _different_ than \"do a git-update-index on that file and\n> commit\", then I'd really suggest that the _old_ index for that\n> filename should match the parent exactly.\n\nThat is also a good safety measure.\n"},{"id":"15357","messageId":"Pine.LNX.4.64.0601311747360.7301@g5.osdl.org","threadId":"3153","inReplyTo":"20060201013901.GA16832@mail.com","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T02:04:31Z","receivedAt":"2006-02-01T02:04:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 Jan 2006, Ray Lehtiniemi wrote:\n> \n> for what it's worth, it's certainly true here... i'm using git to help\n> me manage a similar project where i work.\n\nHmm.\n\nWe _could_ actually fairly easily add a flag to the index which means \n\"don't even bother comparing - assume same\", and then have specific \noperations to clear that flag.\n\nThat would allow people with slow filesystems (not just Windows: even \nunder Linux, the cold-cache case is always going to be pretty slow) to \nhave a _choice_: they could continue to use git it is done now (explicit \nchecks), _or_ they could mark all their index caches as \"implicitly \nup-to-date\" and use a separate program to mark them as being potentially \nedited.\n\nWe still have one unused bit in the cache-entry \"ce_flags\", so we wouldn't \neven need to break any existing index files with it.\n\nWe'd just need to have two new (fast) operations:\n\n - mark one or more files as being \"implicitly up-to-date\"\n\n \"git checkout\" would do this if the proper flag was set in the \n .git/config file.\n\n \"git-update-index --refresh\" would do this for files that weren't \n already implicitly up-to-date _and_ the refresh actually showed it to \n match (and the .git/config file said so).\n\n - mark one or more files as _not_ being implicitly up-to-date:\n\n people would do this by hand when editing a file (or when just deciding \n that they want git to re-check everything again)\n\nThey're fast, because they are purely in the cache (well, git-update-index \nobviously isn't, but the new op wouldn't be any _slower_ than the old \none).\n\nLooks simple enough. The big thing to remember is to clear that \n\"implicitly up-to-date\" flag whenever we make changes (ie we'd probably \nmake \"add_cache_entry()\" always clear it, possibly with a flag to add it \nas \"pre-verified\" which would set it).\n\nComments? Junio, what do you think?\n\n> we're working on a vendor supplied tree which is also hacked upon\n> by various VAR companies. the tree in question has ~20,000 files\n> totalling nearly 1.4 GB of source files, ms word docs, binary-only\n> libraries for a wide array of processor variants, windows exe\n> files, video clips, etc. (however, the amount of actual source code\n> interspersed in there is only about 6000 files totaling about 112 MB)\n> \n> here's a repo sitting on the local linux filesystem with cold cache:\n> \n> reiserfs$ time git update-index --refresh\n> real 0m17.422s\n> user 0m0.025s\n> sys 0m0.320s\n\n.. somewhat painful, but with enough memory this is hopefully a pretty \nrare case.\n\n> and with hot cache\n> \n> reiserfs$ time git update-index --refresh\n> real 0m0.151s\n> user 0m0.020s\n> sys 0m0.067s\n\nThis is how it _should_ look.\n\nBut:\n\n> for comparison, one of our sandboxes is sitting on an NTFS file system,\n> accessed via SMB:\n> \n> smbfs$ time git update-index --refresh\n> real 11m36.502s\n> user 0m6.830s\n> sys 0m5.086s\n\nOuch, ouch, ouch.\n\nSounds like every single stat() will go out the wire. I forget what the \nLinux NFS client does, but I _think_ it has a metadata timeout that avoids \nthis. But it might be as bad under NFS.\n\nHas anybody used git over NFS? If it's this bad (or even close to), I \nguess the \"mark files as up-to-date in the index\" approach is a really \ngood idea..\n\nOf course, the whole point of git is that you should keep your repository \nclose, but sometimes NFS - or similar - is enforced upon you by other \nissues, like the fact that the powers-that-be want anonymous workstations \nand everybody should work with a home-directory automounted over NFS..\n\n\t\t\tLinus\n"},{"id":"15358","messageId":"Pine.LNX.4.64.0601311807470.7301@g5.osdl.org","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311747360.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T02:09:32Z","receivedAt":"2006-02-01T02:09:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 Jan 2006, Linus Torvalds wrote:\n> \n> We still have one unused bit in the cache-entry \"ce_flags\", so we wouldn't \n> even need to break any existing index files with it.\n\nIn case it wasn't clear, the _core_ of this optimization would be as \nsimple as something like the appended.\n\nThe real meat is just making sure that CE_VALID gets set/cleared properly.\n\n(That's also the most complex part, of course, but this trivial patch \nmight help show the basic idea)\n\n\t\tLinus\n\n---\ndiff --git a/cache.h b/cache.h\nindex bdbe2d6..7adc2e6 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -91,6 +91,7 @@ struct cache_entry {\n #define CE_NAMEMASK (0x0fff)\n #define CE_STAGEMASK (0x3000)\n #define CE_UPDATE (0x4000)\n+#define CE_VALID (0x8000)\n #define CE_STAGESHIFT 12\n \n #define create_ce_flags(len, stage) htons((len) | ((stage) << CE_STAGESHIFT))\ndiff --git a/read-cache.c b/read-cache.c\nindex c5474d4..738fe78 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -148,7 +148,16 @@ static int ce_match_stat_basic(struct ca\n \n int ce_match_stat(struct cache_entry *ce, struct stat *st)\n {\n-\tunsigned int changed = ce_match_stat_basic(ce, st);\n+\tunsigned int changed;\n+\n+\t/*\n+\t * If it's marked as always valid in the index, it's \n+\t * valid whatever the checked-out copy says\n+\t */\n+\tif (ce->ce_flags & htons(CE_VALID))\n+\t\treturn 0;\n+\n+\tchanged = ce_match_stat_basic(ce, st);\n \n \t/*\n \t * Within 1 second of this sequence:\n"},{"id":"15359","messageId":"Pine.LNX.4.64.0601312046480.25300@iabervon.org","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311623240.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-02-01T02:19:50Z","receivedAt":"2006-02-01T02:19:50Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 31 Jan 2006, Linus Torvalds wrote:\n\n> So if you do this change (which may be the right one) then please make \n> sure that \"git commit \" doesn't work _at_all_ when a merge is in \n> progress (ie MERGE_HEAD exists), because it would do the wrong thing.\n\nAgreed. I suppose it could accept doing a commit of only a few files which \nweren't touched by the merge, but I don't think even you multitask enough \nto want to do that; anyway, the user can just ditch the merge, commit \ntheir stuff, and try the merge again. (I bet this is a case where new \nusers would be really surprised by the behavior of \"git commit filename\", \nexcept that they wouldn't think it would do anything other than give an \nerror.)\n\n> And yes, then I'll just have to force my fingers to do a simple\n> \n> \tgit-update-index filename\n> \tgit commit\n> \n> instead. I can do that.\n>\n> Oh, one final suggestion: if you give a filename to \"git commit\", and you \n> do the new semantics which means something _different_ than \"do a \n> git-update-index on that file and commit\", then I'd really suggest that \n> the _old_ index for that filename should match the parent exactly. \n> Otherwise, you may have done a\n> \n> \tgit diff filename\n> \n> and you _thought_ you were committing just a two-line thing (because you \n> didn't understand about the index), but another, earlier, action caused \n> the index to be different from the file you had in HEAD, and in reality \n> you're actually committing a much bigger diff.\n> \n> In other words: if you want \"git commit \" to _not_ care about \n> the current index, then it should make sure that the index at least \n> _matches_ the current HEAD in the files mentioned.\n> \n> Ie \"git-diff-index --cached HEAD \" should return empty. Or \n> something like that.\n\nAgreed here, too.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"15361","messageId":"7v64nzollt.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311747360.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T02:31:58Z","receivedAt":"2006-02-01T02:31:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> They're fast, because they are purely in the cache (well, git-update-index \n> obviously isn't, but the new op wouldn't be any _slower_ than the old \n> one).\n>\n> Looks simple enough. The big thing to remember is to clear that \n> \"implicitly up-to-date\" flag whenever we make changes (ie we'd probably \n> make \"add_cache_entry()\" always clear it, possibly with a flag to add it \n> as \"pre-verified\" which would set it).\n>\n> Comments? Junio, what do you think?\n\nSomehow this reminds me of a \"feature\" we added quite a long\ntime ago to support \"update-index without working tree\".\n\nI think this should work fine as a mechanism, but I am a bit\nworried about the convenience and safety aspect. It _might_\nmake sense to do what RCS does; check out read-only copy by\ndefault and set the \"assume unchanged\" flag, to prevent people\nfrom accidentally modifying the working tree copy without\ntelling the index about it.\n"},{"id":"15362","messageId":"46a038f90601311852ie8cfac0rbe92779edea4da1b@mail.gmail.com","threadId":"3153","inReplyTo":"20060201013901.GA16832@mail.com","subject":"Re: [Census] So who uses git?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-02-01T02:52:05Z","receivedAt":"2006-02-01T02:52:05Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 2/1/06, Ray Lehtiniemi wrote:\n> by various VAR companies. the tree in question has ~20,000 files\n> totalling nearly 1.4 GB\n...\n> reiserfs$ time git update-index --refresh\n\nIf you have such a tree, your workflow _must_ be such that you know\nexactly what files you have changed. Asking any tool to go out and\n\"find which of my 20K files has changed\" is doable, but it's just\nmagic that it works on recent linuxes.\n\n> for comparison, one of our sandboxes is sitting on an NTFS file system,\n> accessed via SMB:\n\nyou have the samba stack, network, SMB/CIFS stack and NTFS itself in\nthe middle. Replace the ethernet with carrier pigeons for a more\ncomplete picture ;-)\n\nPerhaps a local git/cygwin on NTFS would be more reasonable to benchmark?\n\ncheers,\n\n\nmartin\n"},{"id":"15363","messageId":"Pine.LNX.4.64.0601311938130.7301@g5.osdl.org","threadId":"3153","inReplyTo":"7v64nzollt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T03:43:12Z","receivedAt":"2006-02-01T03:43:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 Jan 2006, Junio C Hamano wrote:\n> \n> I think this should work fine as a mechanism, but I am a bit\n> worried about the convenience and safety aspect. It _might_\n> make sense to do what RCS does; check out read-only copy by\n> default and set the \"assume unchanged\" flag, to prevent people\n> from accidentally modifying the working tree copy without\n> telling the index about it.\n\nYes, I think the \"assume unchanged\" flag goes well together with making \nsure that the checked-out file is non-writable at the time.\n\nOf course, any number of editors and other actions won't care: if you do \nanything like\n\n\tfor i in *.c\n\tdo\n\t\tsed 's/xyzzy/bas/g' < $i > $i.new\n\t\tmv $i.new $i\n\tdone\n\nyou'll never have even noticed that the old file was marked read-only. So \nit's obviously not in any way any guarantee, but it probably makes sense \nas a crutch.\n\nYour point that we discussed a similar flag for the \"don't require a full \ncheckout\" is a good one: we should try to make sure that it works for both \nuses. Although maybe we decided for some reason that nobody cared about \nthe non-checked-out case?\n\n\t\tLinus\n"},{"id":"15364","messageId":"Pine.LNX.4.64.0601311943290.7301@g5.osdl.org","threadId":"3153","inReplyTo":"46a038f90601311852ie8cfac0rbe92779edea4da1b@mail.gmail.com","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T03:48:37Z","receivedAt":"2006-02-01T03:48:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Feb 2006, Martin Langhoff wrote:\n> \n> If you have such a tree, your workflow _must_ be such that you know\n> exactly what files you have changed. Asking any tool to go out and\n> \"find which of my 20K files has changed\" is doable, but it's just\n> magic that it works on recent linuxes.\n\nIt's not magic, and it's not all that recent. Linux FS ops have always \nbeen pretty good, and the dentry cache was introduced in 2.0.x, I think, \nso you'd be hard-pressed to find a Linux system that doesn't have it.\n\nNow, I bet Linux will be better (often by a factor of 2-3) than most other \nsystems, but that still doesn't mean that 20k files is totally \nunreasonable on other setups. \n\nI suspect cygwin is worse than most because (a) the NT VFS layer is \npiss-poor and you need a kernel service to get good performance and (b) \ncygwin probably adds its own overhead for handling symlinks, so the \n\"lstat()\" call is probably even more expensive.\n\nNow, the networked filesystems are a potential problem for everybody.\n\n\t\tLinus\n"},{"id":"15368","messageId":"Pine.LNX.4.64.0601312104190.7301@g5.osdl.org","threadId":"3153","inReplyTo":"20060201045337.GC25753@mail.com","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T05:04:46Z","receivedAt":"2006-02-01T05:04:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 Jan 2006, Ray Lehtiniemi wrote:\n> \n> what if the user wants to change the mode bits of an assume-unchanged\n> file with the twiddled permissions, but forgets to clear the flag\n> first? seems like that change is likely to get lost, especially if the\n> new mode is read-only....\n\nRemember - git only cares about execute permissions. The write permissions \nare entirely ignored by git ..\n\n\t\tLinus\n"},{"id":"15369","messageId":"7vy80vmy7c.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"20060201045337.GC25753@mail.com","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T05:42:47Z","receivedAt":"2006-02-01T05:42:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ray Lehtiniemi writes:\n\n> what if the user wants to change the mode bits of an assume-unchanged\n> file with the twiddled permissions, but forgets to clear the flag\n> first? seems like that change is likely to get lost, especially if the\n> new mode is read-only....\n\nNo problem, since we only record u+x bit and nothing else. Most\nimportantly, we do not record any of the +w bits.\n"},{"id":"15370","messageId":"7v4q3jlgw2.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311623240.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T06:42:05Z","receivedAt":"2006-02-01T06:42:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Oh, one final suggestion: if you give a filename to \"git commit\", and you \n> do the new semantics which means something _different_ than \"do a \n> git-update-index on that file and commit\", then I'd really suggest that \n> the _old_ index for that filename should match the parent exactly. \n> Otherwise, you may have done a\n>\n> \tgit diff filename\n>\n> and you _thought_ you were committing just a two-line thing (because you \n> didn't understand about the index), but another, earlier, action caused \n> the index to be different from the file you had in HEAD, and in reality \n> you're actually committing a much bigger diff.\n\nThis \"I thought I was only checking in the two-liner I did as\nthe last step but you committed the whole thing, stupid git!\"\nconfusion feels to be a parallel of \"I thought I was only\nchecking in the files I specified on the command line but you\nalso committed the files I earlier git-add'ed, stupid git!\"\nconfusion.\n\nTaken together with your \"during a partially conflicted merge\"\nexample, it feels to me that the simplest safety valve would be\nto refuse \"git commit paths...\" if the index does not exactly\nmatch HEAD. Not just mentioned paths but anywhere.\n\nPeople who do not like this can set in their config file some\nflag, say, 'core.index = understood', to get the current\nbehaviour.\n\nThe reason I am bringing this up is because of this command\nsequence:\n\n\t# start from a clean tree, after 'git reset --hard'\n $ create a-new-file\n $ git add a-new-file\n $ edit existing-file\n $ edit another-file\n $ git commit existing-file\n\nThere is no question we do not commit \"another-file\" and we do\ncommit changes to the \"existing-file\" as a whole. What should\nwe do to \"a-new-file\", and how do we explain why we do so to\nnovices?\n\nWe can argue it either way. We could say we shouldn't because\n\"commit\" argument does not mention it. We could say we should\nbecause the user already told that he wants to add that file to\ngit. Either makes sort-of sense from what the end user did.\n\nI think a file \"cvs add\"ed is committed if whole subdirectory\ncommit (similar to our \"commit -a\") is done or the file is\nexplicitly specified on the \"cvs commit\" command line, and that\nmay match people's expectations. That's an argument for not\ncommitting \"a-new-file\". But to be consistent with that, this\nshould not commit anything:\n\n # the same clean tree.\n\t$ create a-new-file\n $ git add a-new-file\n $ git commit\n\nWhich is counterintuitive to me by now (because I played too\nlong with git).\n\nWe could make \"git commit\" without paths to mean the current\n\"-a\" behaviour, which would match CVS behaviour more closely.\nHowever, it would make commit after a merge conflict resolution\nin a dirty working tree _very_ dangerous -- it may give more\nfamiliar feel to CVS people, but it is not an improvement for\ngit people at all. I would rather not.\n\nRight now, \"git add\" means \"stage this for the next commit in\nthe index\". If we change the semantics of \"git add\" to mean \"I\nam not adding it for the next commit yet; I am just letting you\nknow there is a file in the working tree so that you can keep an\neye on it for me\", using the intent-to-add index entry I've\nmentioned a couple of times, I think the above problem might\nnaturally be solved. For people who do not use update-index,\n\"commit -a\" and \"commit paths...\" are the only two ways to\nactually check-in anything to the index file for the next\ncommit (\"git add\" alone does not count). \"commit -a\" would do\nthe equivalent of current \"update all the not-up-to-date file to\nthe index and then commit\", which would include the intent-to-add\npaths.\n"},{"id":"15371","messageId":"7vmzhbk1b8.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311938130.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T07:03:55Z","receivedAt":"2006-02-01T07:03:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Your point that we discussed a similar flag for the \"don't require a full \n> checkout\" is a good one: we should try to make sure that it works for both \n> uses. Although maybe we decided for some reason that nobody cared about \n> the non-checked-out case?\n\nWe gave them a way to add --cacheinfo but did not do any more\nthan that, because they are independently coming up with some\nhash (not necessarily be a proper git blob object name), they\ndid not have the huge blob data with the working tree anyway,\nand the only thing they cared about was which paths changed and\nthey did not even want to see how the contents changed.\nI.e. \"diff-tree -r\" was the only thing they cared about.\n\nIf we end up doing \"assume unchanged\", I should remember to do a\nsensible thing for \"diff-index\" without --cached. It should not\nlook at the working tree file for paths marked as such. This\nimplies one optimization in \"diff-index -p\" and \"diff-tree -p\"\nmay need to be disabled. They cheat and avoid expanding blob\nobjects when their cache entries are clean and required blobs\nare in the working tree. If \"assume unchanged\" path was\nactually changed, such a diff would show up as a confusing\nunexpected change.\n\nWell, the user is asking for it, so that confusion is not _my_\nproblem, though ;-).\n"},{"id":"15373","messageId":"87vevzpmql.wl%cworth@cworth.org","threadId":"3153","inReplyTo":"7v4q3jlgw2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-01T07:22:10Z","receivedAt":"2006-02-01T07:22:10Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 31 Jan 2006 22:42:05 -0800, Junio C Hamano wrote:\n> \n> There is no question we do not commit \"another-file\" and we do\n> commit changes to the \"existing-file\" as a whole. What should\n> we do to \"a-new-file\", and how do we explain why we do so to\n> novices?\n\nI'll offer a couple of ill-informed comments from a novice's\npoint-of-view if I may.\n\nMy first exposure to git (about 1 week ago) was \"A short git\ntutorial\" [*]\n\nI found the discussion of the index, git-update-index, and the subtle\ndistinctions between the various git-diff commands rather intimidating\nfor an initial introduction. After getting to know the system better\nover the past week, it seems it should be possible to have a class of\n\"novice ready\" tools that provide for common use cases and that never\nrequire any mention of the index in their documentation. If so, that\nseems to me a useful goal to work toward and a useful guide in this\ndiscussion.\n\n> We could make \"git commit\" without paths to mean the current\n> \"-a\" behaviour, which would match CVS behaviour more closely.\n\nAgain, my novice experience leads me to favor that change. After\nreading the tutorial, I had the following sequence in mind for\ncommitting an edited file:\n\n\tgit update-index edited-file\n\tgit commit\n\nwhich seemed like more pain than strictly necessary. The next day,\nwhen I went to the linux.conf.au tutorial and saw Linus use:\n\n\tgit commit -a\n\nfor the same operation it was a breath of fresh air. I was left\nscratching my head wondering why the -a behavior wasn't the default\nfor \"git commit\" with no paths.\n\n> However, it would make commit after a merge conflict resolution\n> in a dirty working tree _very_ dangerous -- it may give more\n> familiar feel to CVS people, but it is not an improvement for\n> git people at all. I would rather not.\n\nI'm still not \"git people\" I guess. Could you explain what the danger\nis here? And is it something the tool could detect and prevent?\n\n-Carl\n\n[*] http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html [*\n\nA better initial introduction for me would likely have been \"A\ntutorial introduction to git\":\n\nhttp://www.kernel.org/pub/software/scm/git/docs/tutorial.html\n\nso a link to the latter from the first paragraph or so of the former\nmight be very helpful.\n\n"},{"id":"15375","messageId":"7virrzfpse.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"87vevzpmql.wl%cworth@cworth.org","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T08:26:25Z","receivedAt":"2006-02-01T08:26:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> ... it seems it should be possible to have a class of\n> \"novice ready\" tools that provide for common use cases and that never\n> require any mention of the index in their documentation. If so, that\n> seems to me a useful goal to work toward and a useful guide in this\n> discussion.\n\nI agree it is a worthy goal. Unfortunately I lost my git\nvirginity long time ago, so a fresh perspective is really\nappreciated in this discussion.\n\n> ... Could you explain what the danger is here?\n\nAs Linus mentioned in an earlier message in this thread, one of\nthe important task for him is to take other peoples' trees and\nmerge it into his mainline. The workflow goes like this:\n\n\t$ git pull from-somewhere\n ... oops there are conflicts\n $ edit conflicted/file\n $ edit more/conflicted/file\n ... maybe compile test ...\n\t$ git diff -c ;# final sanity check\n $ git update-index conflicted/file\n $ git update-index more/conflicted/file\n $ git commit\n\nHe does *not* want to do \"git commit -a\" here, because he\nusually has unrelated changes in his working tree he has not\ndone update-index on and does _not_ want to commit [*1*]. \"git\ncommit\" to imply \"git commit -a\" increases the risk of\naccidentally committing those unrelated changes mixed in the\nmerge (eh, actually makes the risk 100%).\n\nWe _could_ detect that we were in the middle of a merge,\nenumerate the paths touched by the merged branches. Then we can\nsay paths that are different between the index and the working\ntree and not in the paths touched by the merge are his unrelated\nchanges. But it is conceivable he may need to modify a file\nneither branch touches in order to _logically_ resolve the\nmerge, even when the merge phisically does not conflict in\ntextual diff basis, so while that heuristics may work pretty\nwell most of the time, doing so might make things even less\neasier to explain to other people.\n\n\n[Footnotes]\n\n*1* The reason he has unrelated changes while doing a merge is\nbecause he works on things himself (I am speculating about\nthis), and for these modified paths he never runs git-add nor\ngit-update-index until he is ready to commit his changes (I am\nnot speculating about this). As long as he knows what he is\npulling in from outside does not overlap with what he has been\nworking on, he can merge and commit the result without worrying\nabout his own unrelated changes, and git is careful not to touch\nanything in his working tree to cause information loss when the\nchanges do overlap [*2*].\n\nHe is committing something that he never tested himself in his\nworking tree as a whole. The tree resulting from the merge\nnever existed outside his index file, so there is no way he\ncould have even compile tested it properly. But for somebody\nwho is playing an integrator's role, it is not his primary job\nto examine and test every change he merges in as a whole at\nnitty-gritty level -- that is what the originator of the change\nshould have done. So having uncommitted changes in the working\ntree for an integrator person is not a sign of bad discipline at\nall, and supporting this workflow _is_ important for git.\n\nThe primary reason I first got involved in git was because I\nwanted to help the workflow of the kernel people, especially\nLinus and the subsystem maintainers. To be honest, I personally\nstill consider the kernel people the first tier customers for\nme, and I stop and try to think twice when thinking about a\nchange or a new feature that may help individual developers and\nnewcomers, to make sure such a change does not make life less\nconvenient for the 'integrator' people. Helping integrators to\nbe more efficient is important because they can become\nbottlenecks.\n\n*2* I once got yelled at by Linus when I carelessly broke this\nfeature and changed 'git-merge' to require a clean working tree\nwithout changes before starting a merge; it was quickly\nreverted.\n"},{"id":"15381","messageId":"86bqxr8kms.fsf@blue.stonehenge.com","threadId":"3153","inReplyTo":"7virrzfpse.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-02-01T09:59:39Z","receivedAt":"2006-02-01T09:59:39Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> *1* The reason he has unrelated changes while doing a merge is\nJunio> because he works on things himself (I am speculating about\nJunio> this),\n\nYou need to speculate that Linus works on things himself? :)\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"15396","messageId":"Pine.LNX.4.63.0602011535220.28923@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3153","inReplyTo":"20060131225514.GC2812@ca-server1.us.oracle.com","subject":"Re: [Census] So who uses git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-01T14:43:56Z","receivedAt":"2006-02-01T14:43:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 31 Jan 2006, Joel Becker wrote:\n\n> On Tue, Jan 31, 2006 at 11:21:52AM -0800, Linus Torvalds wrote:\n> > Now, I do agree. I don't actually like hiding the index too much. \n> > Understanding the index is _invaluable_ whenever you're doing a merge with \n> > conflicts, and understanding what tools are available to you to resolve \n> > those conflicts.\n> \n> \tThis is precisely the experience I've had explaining GIT to\n> folks moving to it. The simplest workflow (clone; hack one file, commit\n> one file) is so similar to CVS/Subversion/Anything that it's immediately\n> understood. But when pull, push, merge, and any non-linear history are\n> discussed, I have to describe the index and the commit/tree layout.\n> Once I do, they get it.\n> \n> > So I'm actually of the \"revel in the index\" camp (as could probably be \n> > guessed by the original tutorial).\n> \n> \tI'm going to second this, from a real-world \"explain it to\n> others\" standpoint.\n\nHow about talking about the index a bit at the end of tutorial.txt like \nthis:\n\n-- snip --\nFor a number of (mostly technical) reasons, \"git diff\" does not show the \nchanges of the current working directory with respect to the latest \ncommit, but rather to an intermediate stage: the \"index\".\n\nThink of the index as a staging area just before committing: the commit \nobject (and the tree and blob objects referenced from it) are assembled \nthere.\n\nAlso, when you checkout, the index is used to disassemble the commit \nobject just before writing the corresponding files and directories.\n-- snap --\n\nMay this be worth the work?\n\nCiao,\nDscho\n"},{"id":"15398","messageId":"81b0412b0602010655i7b538bdck2baa216203279bce@mail.gmail.com","threadId":"3153","inReplyTo":"46a038f90601311852ie8cfac0rbe92779edea4da1b@mail.gmail.com","subject":"Re: [Census] So who uses git?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-01T14:55:58Z","receivedAt":"2006-02-01T14:55:58Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/1/06, Martin Langhoff wrote:\n> Perhaps a local git/cygwin on NTFS would be more reasonable to benchmark?\n\n$ time git update-index --refresh\n\nreal 0m21.500s\nuser 0m0.358s\nsys 0m1.406s\n\nWinNT, NTFS, 13k files, hot cache.\n"},{"id":"15408","messageId":"14138.1138810543@lotus.CS.Berkeley.EDU","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311747360.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-02-01T16:15:43Z","receivedAt":"2006-02-01T16:15:43Z","isPatch":false,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And Linus Torvalds writes:\n - \n - Has anybody used git over NFS? If it's this bad (or even close to), I \n - guess the \"mark files as up-to-date in the index\" approach is a really \n - good idea..\n\nMy normal use is on NFS (Solaris and Linux) and IBM's GPFS \n(AIX and Linux). I haven't noticed any particular problems, \nand LAPACK and the reference BLAS make a moderately sized \nworking set of around 3000 source files. Not kernel sized, \nbut not tiny.\n\nHowever, I mostly use git over NFS on a relatively slow \nmachine. NFS is faster than the local disk...\n\nJason\n"},{"id":"15409","messageId":"Pine.LNX.4.64.0602010815480.21884@g5.osdl.org","threadId":"3153","inReplyTo":"81b0412b0602010655i7b538bdck2baa216203279bce@mail.gmail.com","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T16:25:36Z","receivedAt":"2006-02-01T16:25:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Feb 2006, Alex Riesen wrote:\n> \n> $ time git update-index --refresh\n> \n> real 0m21.500s\n> user 0m0.358s\n> sys 0m1.406s\n> \n> WinNT, NTFS, 13k files, hot cache.\n\nThat's 25% less files than the Linux kernel, and I can do that operation \nin 0m0.062s (0.012s user, 0.048s system).\n\nSo WinNT/cygwin is about 2.5 _orders_of_maginitude_ slower here, or 340 \ntimes slower.\n\nNow, I'm tempted to say that NT is a piece of sh*t, but the fact is, your \nCPU-times seem to indicate that most of it is IO (and the \"real\" cost is \njust 1.7 seconds, much of which is system time, which in turn itself is \nprobably due to the IO costs too - so even that isn't comparable with \nthe ).\n\nWhich may mean that you simply don't have enough memory to cache the whole \nthing. Which may be NT sucking, of course (\"we don't like to use more than \n10% of memory for caches\"), but it might also be a tunable (which is sucky \nin itself, of course), but finally, it might just be that you just don't \nhave a ton of memory. I've got 2GB in my machines, although 1GB is plenty \nto cache the kernel.\n\n\t\t\tLinus\n"},{"id":"15411","messageId":"Pine.LNX.4.64.0602010856150.21884@g5.osdl.org","threadId":"3153","inReplyTo":"7v4q3jlgw2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T17:11:59Z","receivedAt":"2006-02-01T17:11:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 Jan 2006, Junio C Hamano wrote:\n> \n> Taken together with your \"during a partially conflicted merge\"\n> example, it feels to me that the simplest safety valve would be\n> to refuse \"git commit paths...\" if the index does not exactly\n> match HEAD. Not just mentioned paths but anywhere.\n\nBut at that point, the existing \"git commit\" semantics actually are the \nones we'd use, and the only difference ends up being that we error out \nif the index doesn't match HEAD.\n\nThe problem with that is that it appears that some of the people who don't \nlike the current \"git commit \" thing _do_ actually understand \nthe index, but they want to commit just that one file. \n\nSo at least from my understanding, I think Dscho was arguing for the new \nsemantics of \"git commit \" to _work_, but to only commit , \neven if he does understand the index perfectly well, and might have done a \n\"git add\" or updated a file for some other reason..\n\nBtw, one thing that _can_ be confusing is that you do\n\n\tgit commit fileA\n\nand then when you edit the commit message, you realize that you don't \nactually want to do this at all, so you exit out of the editor without \nchanges (which aborts the commit). Now \"git commit\" will not actually have \ndone the commit, but it _will_ have done the \"git-update-index\" on that \nfile.\n\nSo next time, when you do\n\n\tgit commit fileB\n\nyou'll currently commit _both_ fileA and fileB.\n\nThis is, in my opinion, the biggest argument for the suggested _new_ \nsemantics: if you explicitly name a set of files, it should always do a\n\n\t# Verify current state\n\tparent=$(git-rev-parse --verify HEAD) || exit\n\n\t# Verify that the current index is ok in the named files\n\ta=$(git-diff-files --name-only --cached $parent \"$@\") || exit\n\tif [ \"$a\" ]; then\n\t echo -e >&2 \"Files are changed in the index:\\n $a\"\n\t exit 2\n\tfi\n\n\t# create the new tree object\n\texport GIT_INDEX_FILE=tmpfile\n\tnewtree=$(git-read-tree $parent &&\n\t git-update-index \"$@\" &&\n\t git-write-tree) || exit\n\n\t# edit message\n\t... edit message ..\n\n\t# do commit\n\tnewhead=$(git-commit-tree -p $parent < msg)\n\tgit-update-ref HEAD $newhead $parent\n\nor similar. That has the advantage that if we _do_ decide to break out of \nthe commit, we will not have changed the current index (only the temporary \none).\n\n\t\tLinus\n"},{"id":"15412","messageId":"Pine.LNX.4.64.0602011125370.5397@localhost.localdomain","threadId":"3153","inReplyTo":"7v4q3jlgw2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-02-01T17:18:10Z","receivedAt":"2006-02-01T17:18:10Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 31 Jan 2006, Junio C Hamano wrote:\n\n> This \"I thought I was only checking in the two-liner I did as\n> the last step but you committed the whole thing, stupid git!\"\n> confusion feels to be a parallel of \"I thought I was only\n> checking in the files I specified on the command line but you\n> also committed the files I earlier git-add'ed, stupid git!\"\n> confusion.\n> \n> Taken together with your \"during a partially conflicted merge\"\n> example, it feels to me that the simplest safety valve would be\n> to refuse \"git commit paths...\" if the index does not exactly\n> match HEAD. Not just mentioned paths but anywhere.\n> \n> People who do not like this can set in their config file some\n> flag, say, 'core.index = understood', to get the current\n> behaviour.\n\nI'd avoid hidden config options that magically change behaviors and \nsemantics like that as much as possible. _This_ would pave the way to \neven greater confusion and prevent the git user base from converging on \na unified semantics knowledge. Better add a command line option which \nhas the vertue of being visible, and name it such that it make the \nintention explicit whether the previous index state is preserved or not,\nsomething like --current-index or the like.\n\n> The reason I am bringing this up is because of this command\n> sequence:\n> \n> \t# start from a clean tree, after 'git reset --hard'\n> $ create a-new-file\n> $ git add a-new-file\n> $ edit existing-file\n> $ edit another-file\n> $ git commit existing-file\n> \n> There is no question we do not commit \"another-file\" and we do\n> commit changes to the \"existing-file\" as a whole. What should\n> we do to \"a-new-file\", and how do we explain why we do so to\n> novices?\n> \n> We can argue it either way. We could say we shouldn't because\n> \"commit\" argument does not mention it. We could say we should\n> because the user already told that he wants to add that file to\n> git. Either makes sort-of sense from what the end user did.\n\nIt is much more intuitive to expect that, if you specify path arguments \nto commit, then only those paths are considered, and even if you didn't \ndo a git add on some of them. If nothing is specified then the current \nindex (the default, including a-new-file) is considered.\n\n> I think a file \"cvs add\"ed is committed if whole subdirectory\n> commit (similar to our \"commit -a\") is done or the file is\n> explicitly specified on the \"cvs commit\" command line, and that\n> may match people's expectations. That's an argument for not\n> committing \"a-new-file\".\n\nExact.\n\n> But to be consistent with that, this should not commit anything:\n> \n> # the same clean tree.\n> \t$ create a-new-file\n> $ git add a-new-file\n> $ git commit\n> \n> Which is counterintuitive to me by now (because I played too\n> long with git).\n\nIMHO this should commit a_new_file simply because you added it to the \nindex and a commit without any argument should commit the whole \n(refreshed) index.\n\n> We could make \"git commit\" without paths to mean the current\n> \"-a\" behaviour, which would match CVS behaviour more closely.\n\nExact.\n\n> However, it would make commit after a merge conflict resolution\n> in a dirty working tree _very_ dangerous -- it may give more\n> familiar feel to CVS people, but it is not an improvement for\n> git people at all. I would rather not.\n\nFor that case, (assuming that -a would be the default) maybe something \nmeaning the opposite of -a could be specified on the commit argument \nlist like I suggested earlier. And maybe it should always be the \ndefault when committing a merge (in which case the -a would override \nthat and refresh everything and not only the merged files plus those \nspecified on the command line).\n\nSo to resume:\n\n - a non-merge commit without any argument would imply -a.\n\n - a non-merge commit with path arguments implies _only_ those paths, \n regardless if they were previously \"git add\"ed or not.\n\n - a non-merge commit with, say, --no-auto or --current-index or \n whatever would preserve the current behavior, with or without \n additional paths.\n\n - a merge commit would imply that --no-auto behavior automatically.\n\n - a merge commit could override the --no-auto with an explicit -a.\n\nThis might look complicated when presented like that, but I think that \nthe default behavior of each (non-merge vs merge) commit would more \nclosely fit most people's expectations. The merge commit create a shift \nin semantics of course, but committing a merge is already something a \nbit more involved anyway and at that point git users should have gained \na bit more experience with the index concept and the default merge \nbehavior is probably what most people will expect at that point as well.\n\n\nNicolas\n"},{"id":"15414","messageId":"Pine.LNX.4.64.0602011909330.6498@beast.quantumfyre.co.uk","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311747360.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2006-02-01T19:20:09Z","receivedAt":"2006-02-01T19:20:09Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Tue, 31 Jan 2006, Linus Torvalds wrote:\n\n> Sounds like every single stat() will go out the wire. I forget what the\n> Linux NFS client does, but I _think_ it has a metadata timeout that avoids\n> this. But it might be as bad under NFS.\n>\n> Has anybody used git over NFS? If it's this bad (or even close to), I\n> guess the \"mark files as up-to-date in the index\" approach is a really\n> good idea..\n\nAs it happens, yes ... I can't say that I've noticed git being \nparticularly slow, but then - I've not tried running git with a local \nrepos ... ;)\n\nusing a recentish 2.6 kernel repos, directly on the server I get:\n\nserver: linux-2.6>time git update-index --refresh\n\nreal 0m0.067s\nuser 0m0.015s\nsys 0m0.052s\n\nthen against the same repos over NFS, I get:\n\nclient: linux-2.6>time git update-index --refresh\n\nreal 0m1.578s\nuser 0m0.018s\nsys 0m0.366s\n\nand if I do it from the client again soon afterward I get:\n\nclient: linux-2.6>time git update-index --refresh\n\nreal 0m0.145s\nuser 0m0.012s\nsys 0m0.118s\n\n>\n> Of course, the whole point of git is that you should keep your repository\n> close, but sometimes NFS - or similar - is enforced upon you by other\n> issues, like the fact that the powers-that-be want anonymous workstations\n> and everybody should work with a home-directory automounted over NFS..\n>\n\n-- \nJulian\n\n ---\nYou know it's going to be a bad day when you want to put on the clothes\nyou wore home from the party and there aren't any.\n"},{"id":"15416","messageId":"Pine.LNX.4.64.0602011124090.21884@g5.osdl.org","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602011909330.6498@beast.quantumfyre.co.uk","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T19:29:07Z","receivedAt":"2006-02-01T19:29:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Feb 2006, Julian Phillips wrote:\n> \n> As it happens, yes ... I can't say that I've noticed git being particularly\n> slow, but then - I've not tried running git with a local repos ... ;)\n\nWell, NFS seems to be ok. Which is not that surprising: NFS has gotten a \n_lot_ of attention in the caching area (I worked on it myself a couple of \nyears back when the page cache transition happened during 2.3.x, but \nhappily we've had very good NFS maintainership since, so I don't get \ninvolved any more).\n\nYour numbers show that NFS is fine (my \"benchmark\" is that I refuse to see \nthe kinds of commit times that \"cvs commit\" does - easily several minutes \nfor a big project. If it goes over 2 seconds, it's painful, and over ten \nseconds is totally unacceptable).\n\nYour numbers seem to say that at least with a good network/server, NFS on \nLinux is not a problem at all.\n\nCIFS is likely a very different animal. I suspect the cifs people have \nspent a whole lot more effort on strange Windows interaction issues than \non trying to make sure that cached performance is top-notch.\n\n\t\t\tLinus\n"},{"id":"15415","messageId":"43E10C48.3030405@zytor.com","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311943290.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2006-02-01T19:30:16Z","receivedAt":"2006-02-01T19:30:16Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> It's not magic, and it's not all that recent. Linux FS ops have always \n> been pretty good, and the dentry cache was introduced in 2.0.x, I think, \n> so you'd be hard-pressed to find a Linux system that doesn't have it.\n> \n\n2.1.14, I seem to remember -- it was definitely 2.1.1x-ish. I mostly \nrecall because autofs didn't just break horribly, it took adding several \ndcache hooks to make it work again :)\n\n\t-hpa\n"},{"id":"15418","messageId":"43E10CCE.5090500@zytor.com","threadId":"3153","inReplyTo":"20060130185822.GA24487@hpsvcnb.fc.hp.com","subject":"Re: [Census] So who uses git?","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2006-02-01T19:32:30Z","receivedAt":"2006-02-01T19:32:30Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Carl Baldwin wrote:\n> \n> - Anyone can install and fire it up without license/contract hassles.\n> \n\nFor something like an SCM this is a big deal, and not just for the Open \nSource world. In a company, it means not having to worry about having \nenough licenses, and getting budget approval, etc, etc, before a new \nperson can join a project. Perhaps more importantly, it allows someone \nwho normally isn't *on* the project to look at it and participate.\n\n\t-hpa\n"},{"id":"15419","messageId":"43E10D57.4060307@zytor.com","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601310926330.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2006-02-01T19:34:47Z","receivedAt":"2006-02-01T19:34:47Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n>>\n>>For example, I had a hard time explaining to a friend why a git-add'ed \n>>file is committed when saying \"git commit some_other_file\", but not \n>>another (modified) file. Very unintuitive.\n> \n> I really think you should explain it one of two ways:\n> \n> - ignore it. Never _ever_ use git-update-index directly, and don't tell \n> people about use individual filenames to git-commit. Maybe even add \n> \"-a\" by default to the git-commit flags as a special installation \n> addition.\n> \n> - talk about the index, and revel in it as a way to explain the staging \n> area. This is what the old tutorial.txt did before it got simplified.\n> \n> The \"ignore the index\" approach is the simple one to explain. It's \n> strictly less powerful, but hey, what else is new? \n> \n\nI think both of these are probably the wrong answer, and it's pretty \nmuch a matter of the git model violating the principle of least \nsurprise. Perhaps added (or removed?) files need to be handled in a \ndifferent way than they currently are.\n\n\t-hpa\n"},{"id":"15424","messageId":"7vhd7ibza2.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602011125370.5397@localhost.localdomain","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T20:27:17Z","receivedAt":"2006-02-01T20:27:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Tue, 31 Jan 2006, Junio C Hamano wrote:\n>\n>> People who do not like this can set in their config file some\n>> flag, say, 'core.index = understood', to get the current\n>> behaviour.\n>\n> I'd avoid hidden config options that magically change behaviors and \n> semantics like that as much as possible....\n\nI agree; it was tongue-in-cheek sort of suggestion ;-)\n\n> It is much more intuitive to expect that, if you specify path arguments \n> to commit, then only those paths are considered, and even if you didn't \n> do a git add on some of them. If nothing is specified then the current \n> index (the default, including a-new-file) is considered.\n\nGood thinking. I was not thinking about the case where you\nexplicitly list an untracked file to be added.\n\n> - a non-merge commit without any argument would imply -a.\n>\n> - a non-merge commit with path arguments implies _only_ those paths, \n> regardless if they were previously \"git add\"ed or not.\n>\n> - a non-merge commit with, say, --no-auto or --current-index or \n> whatever would preserve the current behavior, with or without \n> additional paths.\n>\n> - a merge commit ...\n> - a merge commit ...\n>\n> This might look complicated when presented like that, but I think that \n> the default behavior of each (non-merge vs merge) commit would more \n> closely fit most people's expectations....\n\nIf I may correct what I said earlier, I now realize the\n\"automatic -a is dangerous\" argument does not have anything to\ndo with merges. If the user usually works with a dirty working\ntree, is aware of the index, and takes advantage of the index as\nthe staging area for the next commit, your --no-auto would be\nneeded to help her workflow. I in principle agree with the\nfirst three items in the above summary, except that I think it\nwould make more sense to do that for all commits.\n\nHow about this:\n\n - \"git commit --also fileA...\" means: update index at listed\n paths (add/remove if necessary) and then commit the tree\n described in index (the current behaviour with explicit paths).\n\n - \"git commit fileA...\" means: create a temporary index from the\n current HEAD commit (or empty index if there is none), update\n it at listed paths (add/remove if necessary) and commit the\n resulting tree. Also update the real index at the listed\n paths (add/remove if necessary). In the original index file,\n the paths listed must be either empty or match exactly the\n HEAD commit -- otherwise we error out (Linus' suggestion).\n\n - \"git commit\" means: update index with all local changes and\n then commit the tree described in index (current \"-a\"\n behaviour).\n\n - In all cases, revert the index to the state before the\n command is run if we end up not making the commit (e.g. index\n unmerged, empty log message, pre-commit hook refusal).\n\nExperienced git users would end up saying \"--also\" without\nexplicit paths to defeat the automatic -a behaviour all the\ntime, and while the flag --also makes perfect sense when used\nwith one or more paths, using it like this look awkward:\n\n $ edit some-file\n $ git update-index some-file\n $ git commit --also\n\nIt's just a flag name so we could make --no-auto synonym to --also.\n\nA minor twist of the above to make it friendlier to the current\ngit users is to do this:\n\n - \"git commit fileA...\", \"git commit -a\", and \"git commit\" keep\n the existing semantics.\n\n - \"git commit --only fileA...\" does the new temporary index\n thing.\n\nThis has an advantage that existing use is not affected, and\nanother advantage is that internally it is more consistent (\"git\ncommit\" is a natural extension of \"git commit fileA...\" with\nzero path). But one possible downside is that you need to\nexplicitly say --only when you want cvs-like \"commit\".\n\nSince we are discussing that the people find existing\ninterface to be unintuitive, being consistent with the current\nusage may not count as a big advantage after all..\n"},{"id":"15427","messageId":"7vvevyajpr.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"86bqxr8kms.fsf@blue.stonehenge.com","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T20:48:48Z","receivedAt":"2006-02-01T20:48:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Junio\" == Junio C Hamano writes:\n>\n> Junio> *1* The reason he has unrelated changes while doing a merge is\n> Junio> because he works on things himself (I am speculating about\n> Junio> this),\n>\n> You need to speculate that Linus works on things himself? :)\n\nForgot a smiley ;-).\n"},{"id":"15430","messageId":"Pine.LNX.4.64.0602011307250.21884@g5.osdl.org","threadId":"3153","inReplyTo":"7vhd7ibza2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T21:09:19Z","receivedAt":"2006-02-01T21:09:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Feb 2006, Junio C Hamano wrote:\n> \n> How about this:\n> \n> - \"git commit --also fileA...\" means: update index at listed\n> paths (add/remove if necessary) and then commit the tree\n> described in index (the current behaviour with explicit paths).\n\nI'd suggest \"--incremental\" instead of \"--also\".\n\n> - \"git commit fileA...\" means: create a temporary index from the\n> current HEAD commit (or empty index if there is none), update\n> it at listed paths (add/remove if necessary) and commit the\n> resulting tree. Also update the real index at the listed\n> paths (add/remove if necessary). In the original index file,\n> the paths listed must be either empty or match exactly the\n> HEAD commit -- otherwise we error out (Linus' suggestion).\n\nYes.\n\n> - \"git commit\" means: update index with all local changes and\n> then commit the tree described in index (current \"-a\"\n> behaviour).\n\nNo. Please no. \"git commit\" should continue to do what it does now. \nOtherwise you can't do the two-stage thing in any sane way.\n\nRequiring \"--incremental\"/\"--also\" is very confusing.\n\nIf somebody doesn't know about the index, he normally will never have \nindex changes _anyway_, except for the \"git add\" case. In which case \"git \ncommit\" does the right thing for him: it will either commit the added \nfiles, or it will say \"nothing to commit\".\n\n\t\tLinus\n"},{"id":"15433","messageId":"Pine.LNX.4.64.0602011622371.5397@localhost.localdomain","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602011307250.21884@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-02-01T21:34:34Z","receivedAt":"2006-02-01T21:34:34Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 1 Feb 2006, Linus Torvalds wrote:\n\n> \n> \n> On Wed, 1 Feb 2006, Junio C Hamano wrote:\n> > \n> > How about this:\n> > \n> > - \"git commit --also fileA...\" means: update index at listed\n> > paths (add/remove if necessary) and then commit the tree\n> > described in index (the current behaviour with explicit paths).\n> \n> I'd suggest \"--incremental\" instead of \"--also\".\n> \n> > - \"git commit fileA...\" means: create a temporary index from the\n> > current HEAD commit (or empty index if there is none), update\n> > it at listed paths (add/remove if necessary) and commit the\n> > resulting tree. Also update the real index at the listed\n> > paths (add/remove if necessary). In the original index file,\n> > the paths listed must be either empty or match exactly the\n> > HEAD commit -- otherwise we error out (Linus' suggestion).\n> \n> Yes.\n\nAgreed.\n\n> > - \"git commit\" means: update index with all local changes and\n> > then commit the tree described in index (current \"-a\"\n> > behaviour).\n> \n> No. Please no. \"git commit\" should continue to do what it does now. \n> Otherwise you can't do the two-stage thing in any sane way.\n> \n> Requiring \"--incremental\"/\"--also\" is very confusing.\n> \n> If somebody doesn't know about the index, he normally will never have \n> index changes _anyway_, except for the \"git add\" case. In which case \"git \n> commit\" does the right thing for him: it will either commit the added \n> files, or it will say \"nothing to commit\".\n\nSensible. As long as \"commit files...\" actually commits _only_ those \nfiles unless --index (or something) is specified to also explicitly \ninclude the index changes.\n\nWhat is really counter-intuitive is to have index changes merged by \ndefault when a single file is specified as argument to commit.\n\n\nNicolas\n"},{"id":"15436","messageId":"7v8xsu91vf.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602011307250.21884@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T21:59:32Z","receivedAt":"2006-02-01T21:59:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n>> - \"git commit\" means: update index with all local changes and\n>> then commit the tree described in index (current \"-a\"\n>> behaviour).\n>\n> No. Please no. \"git commit\" should continue to do what it does now. \n> Otherwise you can't do the two-stage thing in any sane way.\n> Requiring \"--incremental\"/\"--also\" is very confusing.\n\nI myself did not like it but...\n\n> If somebody doesn't know about the index, he normally will never have \n> index changes _anyway_, except for the \"git add\" case. In which case \"git \n> commit\" does the right thing for him: it will either commit the added \n> files, or it will say \"nothing to commit\".\n\n... the original complaint was that \"git commit\" without\nexplicit paths does not quack like \"cvs/svn commit\" -- commit\nall my changes in the working tree.\n\nAnd actually the one you are responding to was my cunning move\nto pull this exact reaction from you: \"No commit without\nparameter should not imply -a\". I prefer the \"minor twist\"\nversion in the same messge myself.\n\nTo recap:\n\n - \"git commit fileA...\" means: update index at listed paths\n (add/remove if necessary) and then commit the tree described\n in index (the same as the current behaviour with explicit\n paths).\n\n - \"git commit -a\" means: update index with all local changes and\n then commit the tree described in index (the same as the\n current behaviour).\n\n - \"git commit\" means: write out the current index and commit\n (the same as the current behaviour).\n\n - \"git commit --only fileA...\" means: create a temporary index\n from the current HEAD commit (or empty index if there is\n none), update it at listed paths (add/remove if necessary)\n and commit the resulting tree. Also update the real index at\n the listed paths (add/remove if necessary). In the original\n index file, the paths listed must be either empty or match\n exactly the HEAD commit -- otherwise we error out (Linus'\n suggestion).\n\n - In all cases, revert the index to the state before the\n command is run if we end up not making the commit (e.g. index\n unmerged, empty log message, pre-commit hook refusal). With\n this, \"git diff-files fileA\" would show the differences as it\n showed beforean aborted \"git commit -a\" or \"git commit fileA\"\n and removes one common gripe.\n"},{"id":"15437","messageId":"20060201220055.GS2812@ca-server1.us.oracle.com","threadId":"3153","inReplyTo":"7vhd7ibza2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2006-02-01T22:00:55Z","receivedAt":"2006-02-01T22:00:55Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Wed, Feb 01, 2006 at 12:27:17PM -0800, Junio C Hamano wrote:\n> - \"git commit fileA...\" means: create a temporary index from the\n> current HEAD commit (or empty index if there is none), update\n> it at listed paths (add/remove if necessary) and commit the\n\n\tPlease don't do the add/remove automatically. I know, it's\npretty convenient if I explicitly say \"git commit filetoadd\", but what\nhappens if I say \"git commit libfoo/*\"? I know that I want all my\nchanges in libfoo/ to be commited, ignoring my changes in libbar/. But\nI forgot that I created libfoo/testfoo.c to debug my changes, and now\nit's in the repository -- and I might not even notice it for weeks.\n\tCVS and Subversion require an explicit \"add\" for this very\nreason. Even then, almost everyone gets an \"import\" or two wrong,\npulling in a couple built files (eg, \"configure\") they didn't mean to\nget.\n\tI guess you could query the user. \"I noticed that you specified\nfiletoadd, and you never said 'git add'. Do you want to add it now\n[Y/n]?\"\n\nJoel\n\n\n-- \n\n\"When I am working on a problem I never think about beauty. I\n only think about how to solve the problem. But when I have finished, if\n the solution is not beautiful, I know it is wrong.\"\n - Buckminster Fuller\n\nJoel Becker\nPrincipal Software Developer\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"15438","messageId":"Pine.LNX.4.64.0602011717010.5397@localhost.localdomain","threadId":"3153","inReplyTo":"7v8xsu91vf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-02-01T22:25:18Z","receivedAt":"2006-02-01T22:25:18Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 1 Feb 2006, Junio C Hamano wrote:\n\n> To recap:\n> \n> - \"git commit fileA...\" means: update index at listed paths\n> (add/remove if necessary) and then commit the tree described\n> in index (the same as the current behaviour with explicit\n> paths).\n\nNo.\n\n> - \"git commit -a\" means: update index with all local changes and\n> then commit the tree described in index (the same as the\n> current behaviour).\n\nSensible.\n\n> - \"git commit\" means: write out the current index and commit\n> (the same as the current behaviour).\n\nSensible.\n\n> - \"git commit --only fileA...\" means: create a temporary index\n> from the current HEAD commit (or empty index if there is\n> none), update it at listed paths (add/remove if necessary)\n> and commit the resulting tree. Also update the real index at\n> the listed paths (add/remove if necessary). In the original\n> index file, the paths listed must be either empty or match\n> exactly the HEAD commit -- otherwise we error out (Linus'\n> suggestion).\n\nActually, my opinion is that should be the behavior for your first item \nabove (when only filenames are specified). If you want to _also_ \ninclude the index like you describe in your first item then an \nadditional switch should be provided.\n\nIn other words, the --only should become --with-index with the behavior \nswapped.\n\nThe fact is that when you simply specify a filename, you really expect \n_only_ that filename will be affected and the rest be left alone. \nThat's the most probable expectation for any tool. If you want \n_additional_ stuff to also be merged along with the files specified then \nit is logical to have an additional argument in that case, not the other \nway around.\n\n\nNicolas\n"},{"id":"15439","messageId":"Pine.LNX.4.64.0602011433290.21884@g5.osdl.org","threadId":"3153","inReplyTo":"7v8xsu91vf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T22:35:33Z","receivedAt":"2006-02-01T22:35:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Feb 2006, Junio C Hamano wrote:\n> \n> ... the original complaint was that \"git commit\" without\n> explicit paths does not quack like \"cvs/svn commit\" -- commit\n> all my changes in the working tree.\n\nAgreed. However, I think that one is pretty easy to explain, and \nconceptually it's not a problem to just tell people to use the \"-a\" flag \nif they want to get CVS/SVN semantics.\n\nAfter all, \"git commit\" will actually make it pretty obvious in the commit \nmessage status, _and_ if you haven't done any \"git add\" you'll get the \n\"nothing to commit\" thing, so it's not like this is hard to explain.\n\nThe real _confusion_ I think came from the filename usage.\n\n\t\tLinus\n"},{"id":"15440","messageId":"7v8xsu7kys.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602011717010.5397@localhost.localdomain","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T22:50:03Z","receivedAt":"2006-02-01T22:50:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Actually, my opinion is that should be the behavior for your first item \n> above (when only filenames are specified). If you want to _also_ \n> include the index like you describe in your first item then an \n> additional switch should be provided.\n\nOK, agreed. Sorry to be slow.\n\nSo, to recap:\n\ngit commit paths...\t\t\t(temporary index thing)\ngit commit --incremental paths...\t(same as current w/o --incremental)\ngit commit \t\t(same as current)\ngit commit -a\t\t\t\t(same as current)\t\n\nAnd I agree with Joel that we should not automatically imply\n\"git add\" with or without --incremental.\n\nI do not particularly have much preference among --also,\n--with-index, or --incremental, but:\n\n - 'with-index' is precise but might be too technical;\n - 'incremental' is not really incremental -- you can use it\n only once.\n\nBecause you do not have to say \"git commit --also\" without paths\n(which _is_ awkward) to get the traditional behaviour, maybe it\nis a good name for that flag (it is also the shortest).\n"},{"id":"15443","messageId":"Pine.LNX.4.64.0602011747380.25300@iabervon.org","threadId":"3153","inReplyTo":"7v8xsu91vf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-02-01T22:57:47Z","receivedAt":"2006-02-01T22:57:47Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 1 Feb 2006, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > If somebody doesn't know about the index, he normally will never have \n> > index changes _anyway_, except for the \"git add\" case. In which case \"git \n> > commit\" does the right thing for him: it will either commit the added \n> > files, or it will say \"nothing to commit\".\n> \n> ... the original complaint was that \"git commit\" without\n> explicit paths does not quack like \"cvs/svn commit\" -- commit\n> all my changes in the working tree.\n\nActually, the original complaint was about \"git commit path ...\", I \nbelieve. That's the case where new users are finding that the behavior is \nsurprising, rather than just unfamiliar.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"15448","messageId":"87lkwupsbr.wl%cworth@cworth.org","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602011433290.21884@g5.osdl.org","subject":"Two ideas for improving git's user interface","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-01T23:33:44Z","receivedAt":"2006-02-01T23:33:44Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 1 Feb 2006 14:35:33 -0800 (PST), Linus Torvalds wrote:\n>\n> Agreed. However, I think that one is pretty easy to explain, and \n> conceptually it's not a problem to just tell people to use the \"-a\" flag \n> if they want to get CVS/SVN semantics.\n\n\"Just use -a\" is tempting, but I don't think it's a satisfying stance\nto take.\n\nConsider the following operations:\n\n\techo \"original\" > A; git add A; echo \"modified\" > A;\n\tgit commit -a -m \"add A\";\n\n\techo \"original\" > B; git add B; echo \"modified\" > B;\n\tgit commit -m \"add B\" B;\n\n\techo \"original\" > C; git add C; echo \"modified\" > C;\n\tgit commit -m \"add C\";\n\nAfter which we can see:\n\n\t$ git diff\n\tdiff --git a/C b/C\n\tindex 4b48dee..2e09960 100644\n\t--- a/C\n\t+++ b/C\n\t@@ -1 +1 @@\n\t-original\n\t+modified\n\nTo explain this, \"just use -a\" isn't enough, it would have to be\nsomething like, \"always use -a or else 'git commit' just won't work\nand you can end up committing stale garbage\". And perhaps \"unless you\nalso add the filename to the commit line, then it will start working\nagain.\"\n\nThere's explanation for the above behavior requires a rather careful\ndescription of the index, the operations, the flags, and some rather\nsubtle interactions between them.\n\nI don't even think \"embrace the index\" is enough to make the above\nbehavior obvious---the variations in the above behavior are a bit too\nsubtle. \n\nBut I don't think git is doomed to be hard to learn or that its\nbehavior needs to be hard to predict. I think this should be fairly\neasy to fix.\n\nHere's a fundamental question I have, (and thanks to Keith Packard for\nhelping me to phrase it):\n\n\tIs it ever useful (reasonable, desirable) to commit file\n\tcontents that differ from the contents of the working\n\tdirectory?\n\nI don't think it is, (but please let me know if I've missed some\nuseful case).\n\nIdea #1 (prevent the index from being used to commit stale data)\n-------\nIf this isn't useful, then I think git would do well to make it\nharder/impossible to perform this operation. For example, the index\ncould have a new notion of \"use working directory contents\" for a\ngiven file in addition to the current \"use this blob\". This would\nallow a user to use the index to stage subsequent file\nadditions/modifications for commit without introducing the various\nopportunities for confusing commits of stale data.\n\nI would think this would then naturally resolve the confusion around\nthe various diff operations, (diff-index, diff-index --cached, and\ndiff-files).\n\nIdea #2 (make it easy to preview diffs of what will be committed)\n-------\nIndependent of the above, I'd like to propose another change to help\nprevent confusion and to help users learn git. There should be an\nobvious \"diff\" operation that presents exactly the result of what any\n\"commit\" operation will perform.\n\nI assume that there currently exist appropriate diff operations for\nany commit, but the correspondence certainly isn't obvious. For\nexample, the simplest of commit commands:\n\n\tgit commit\n\nseems to correspond to a rather complex diff command (which I may not\nhave completely correct yet---and if not, that would just demonstrate\nthe point even more):\n\n\tgit diff-index -p --cached HEAD\n\nWhat I would love to have is the ability to pass the same arguments to\ngit diff to get a preview of what any get commit would do. For\nexample, something like:\n\n\tgit diff\t\t# would be a preview of:\n\tgit commit\n\n\tgit diff -a\t\t# would be a preview of:\n\tgit commit -a\n\n\tgit diff fileA fileB\t# would be a preview of:\n\tgit commit fileA fileB\n\netc.\n\nAgain, thanks for your consideration to these thoughts from woefully\nclueless and inexperienced user.\n\n-Carl\n"},{"id":"15452","messageId":"7v1wym4msq.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"87lkwupsbr.wl%cworth@cworth.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-02T00:38:45Z","receivedAt":"2006-02-02T00:38:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> To explain this, \"just use -a\" isn't enough, it would have to be\n> something like, \"always use -a or else 'git commit' just won't work\n> and you can end up committing stale garbage\". And perhaps \"unless you\n> also add the filename to the commit line, then it will start working\n> again.\"\n\nI do not think you have to make it sound *that* negative. I\nagree it may be counterintuitive until the user groks the index.\n\nLet's assume that we will fix things to (1) require \"--also\" (or\n\"--incremental\") to get the current \"git commit paths...\"\nbehaviour, (2) without any arguments we commit the index as is,\n(3) with explicit paths we commit clean HEAD plus only specified\npaths using a temporary index. I think a fairer way to say what\nyou said would be:\n\n Always use -a, or explicit paths. With -a all of your\n changes in the working tree are committed. With paths,\n only changes to those paths are committed.\n\n Once you are comfortable with making commits this way,\n you might want to learn about index file and then start\n using 'git commit' without any argument. This works in\n a way that cannot be understood until you learn how the\n index file works, so stick to \"-a or explicit paths\"\n rule for now. That rule is good enough for everyday\n use.\n\nAnd you can probably go a long way without ever knowing about\nindex. Initially when I wrote the above two paragraphs, I said\n\"appreciated\" instead of \"understood\". But depending on your\nworkflow, you may not even need what \"git commit\" without\narguments would give you, in which case there is nothing to\nappreciate about, so I changed the wording.\n\nOld-timer git people seem to like what it gives them but that\ndoes not mean everybody should marvel at what it does and adopt\nthe workflow to take advantage of the index file.\n\n> Here's a fundamental question I have, (and thanks to Keith Packard for\n> helping me to phrase it):\n>\n> \tIs it ever useful (reasonable, desirable) to commit file\n> \tcontents that differ from the contents of the working\n> \tdirectory?\n\nWhat that means is people should always do \"git commit -a\". Not\neven \"git commit paths...\". It matches _my_ sense of developer\ndiscipline, especially for individual developers, but it is a\nrather cumbersome straightjacket if enforced upon you in\npractice. It is a useful timesaver to be able to leave\nunrelated changes around in the working tree.\n\n> I don't think it is, (but please let me know if I've missed some\n> useful case).\n\nI think I've already done this a couple of times today.\n\nYour \"git diff\" is interesting, but I'd rather make them\ncompletely separate command from \"git diff\". Perhaps \"git\nndiff\" and \"git ncommit\", that assumes there is nothing but \"git\ncommit -a\" kind of commits.\n"},{"id":"15456","messageId":"87irrya7bx.wl%cworth@cworth.org","threadId":"3153","inReplyTo":"7v1wym4msq.fsf@assigned-by-dhcp.cox.net","subject":"Re: Two ideas for improving git's user interface","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-02T01:16:18Z","receivedAt":"2006-02-02T01:16:18Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 01 Feb 2006 16:38:45 -0800, Junio C Hamano wrote:\n> \n> I do not think you have to make it sound *that* negative.\n\nSorry about that. I was just trying to emphasize the new-user\nconfusion, and perhaps I went overboard.\n\n> It is a useful timesaver to be able to leave\n> unrelated changes around in the working tree.\n> \n> > I don't think it is, (but please let me know if I've missed some\n> > useful case).\n> \n> I think I've already done this a couple of times today.\n\nI'm sorry. I didn't succeed in phrasing the question the way I\nwanted. Yes, it is useful to be able to leave unrelated changes around\nin the working tree. So in that sense, it is clearly useful to be able\nto commit something that is different (in a repository-wide sense)\nthan what is in the working tree.\n\nThe question I was trying to ask is, for a _single file_ is it ever\nuseful to commit contents that differ from the contents of the working\ndirectory? Let's call this a \"skewed file\" in the index.\n\nI haven't used git much yet, but I found two cases for when one might\nend up committing a skewed file:\n\n1) Modification of working directory after git-update-index or git-add.\n\n There has been discussion in this thread already that the user can\n get a confusing commit in this case.\n\n2) git-read-tree -m\t# without -u\n\n The git documentation already advertises that not using -u here\n leads to confusion. This one looks historical, and it's not obvious\n to me whether git-read-tree is used in practice without -u.\n\nSo, in both of those cases the skewed files seem to lead only to\nconfusion. Are there any non-confusing cases where it's useful to be\nable to commit a skewed file?\n\nIf not, we should be able to simplify things since a lot of the\nUI complexity being discussed (-a vs. no -a, path names vs. no path\nnames), hinges on the handling of skewed files.\n\n> Your \"git diff\" is interesting, but I'd rather make them\n> completely separate command from \"git diff\". Perhaps \"git\n> ndiff\" and \"git ncommit\", that assumes there is nothing but \"git\n> commit -a\" kind of commits.\n\nI'd be fine with some other name than \"diff\" if strictly necessary,\nbut I'm not suggesting something that makes any assumption about \"git\ncommit -a\" only. What I want is a simple way to take any \"git commit\"\ncommand and be able to examine the diff that it will be committing.\n\nMy workflow has been to always perform a final review of such a diff\nwhile composing the commit message. I'd like to be able to do that\nwith git.\n\nAnd I think this tool would make a very good learning tool for users\ntrying to figure out the various commit operations, (particularly if\nwe end up with different semantics for merge vs. non-merge, -a vs. no\n-a, path names vs. no path names, etc.).\n\n-Carl\n"},{"id":"15458","messageId":"Pine.LNX.4.64.0602011656130.21884@g5.osdl.org","threadId":"3153","inReplyTo":"87lkwupsbr.wl%cworth@cworth.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-02T01:23:38Z","receivedAt":"2006-02-02T01:23:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Feb 2006, Carl Worth wrote:\n> \n> Here's a fundamental question I have, (and thanks to Keith Packard for\n> helping me to phrase it):\n> \n> \tIs it ever useful (reasonable, desirable) to commit file\n> \tcontents that differ from the contents of the working\n> \tdirectory?\n\nYes. I do it all the time.\n\nI tend to have a certain fairly constant set of changes in my working \ntree, namely every time a release is getting closer, I always tend to have \nthe \"Makefile\" already updated for the new version (but not checked in: I \ndo that just before I actually tag it, so that the tag will match the \ncommit that actually changes the version).\n\nI do that largely for historical reasons, namely that I've forgotten too \nmany times to actually change the version number, and then I usually get a \nbug report within minutes of cutting the release with a snickering \"hah, \nyou forgot to change the version again\".\n\nSo I do lots of commits with that Makefile being dirty, without ever \nactually committing the Makefile changes themselves. \"git commit -a\" as a \ndefault would be absolutely _horrible_ for me.\n\nI occasionally have other things dirty too in my tree - just random \nhacking. But the Makefile is dirty about 50% of the time for me, so it's \nthe common case.\n\nAnd most of those commits are automated, either through pulls that are \nsuccessful, or just my email patch-application scripts, and both of those \ncases actually check that the files that are _changed_ are never dirty in \nthe working directory.\n\nHowever, if the question was an even stricter \"do you ever commit \n_changes_ to a particular file where the last HEAD, the index _and_ the \nworking tree are all different\", then the answer is actually \"Yes\" to that \ntoo.\n\nWhat has happened is that I have had merges that have content conflicts \nthat I fix up by hand, but exactly _because_ I fix them up by hand, I \nactually want to re-compile the kernel and test my fixups.\n\nAnd in that case, I will actually re-apply my manual Makefile change, even \nif that file was part of the merge changes (in which case I had had to \nfirst un-apply the change in order to do the merge).\n\nSo what happens is that I recompile with my trivial changes in place \n_after_ I have fixed up any merge conflicts, reboot the thing to test, and \nthen commit the result if everything looks ok.\n\nAnd notice how I commit the _merge_ without actually committing my dirty \nstate in the tree - and whether the files involved in my standard dirty \nchanges (\"Makefile\") are part of the state that the merge changed or not \nis _totally_ irrelevant.\n\nSo I commit file contents that differ from my current working tree all the \ntime.\n\nALMOST all of the time, the actual _changes_ that I commit do not actually \ntouch the files that I have dirty, but as explained above, even that is \nnot at all impossible.\n\nThe thing is, once you get used to the git \"index\" as a staging place, \nit's really really powerful. \n\n> Idea #2 (make it easy to preview diffs of what will be committed)\n> -------\n> Independent of the above, I'd like to propose another change to help\n> prevent confusion and to help users learn git. There should be an\n> obvious \"diff\" operation that presents exactly the result of what any\n> \"commit\" operation will perform.\n\nActually, we do exactly that. Right now we expressly limit the \"preview\" \nto just the filenames, but we literally do run\n\n\tgit-diff-index -M --cached --name-status --diff-filter=MDTCRA HEAD\n\nas part of \"git status\", and the eventual end result is what we will \npopulate the commit message file with for your editing pleasure.\n\nAnd you can actually see that. \n\nSo I would suggest that new git users never be told about the \"-m\" flag to \n\"git commit\", so that they always have to edit the commit message by hand, \nbecause that commit message will contain exactly this information.\n\nNot the patch itself, though. Maybe we could make it show part of it, \nthough, if somebody really wants to see it ;)\n\n\t\tLinus\n"},{"id":"15459","messageId":"Pine.LNX.4.64.0602011732560.21884@g5.osdl.org","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602011656130.21884@g5.osdl.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-02T01:44:49Z","receivedAt":"2006-02-02T01:44:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Feb 2006, Linus Torvalds wrote:\n> \n> And notice how I commit the _merge_ without actually committing my dirty \n> state in the tree - and whether the files involved in my standard dirty \n> changes (\"Makefile\") are part of the state that the merge changed or not \n> is _totally_ irrelevant.\n\nIf you get the feeling that merging is special, then to some degree, yes, \nyou'd be right.\n\nMerging (especially with conflicts) is the _one_ operation where you \nabsolutely have to know about the index. If you don't know about how the \nindex works, you can get the conflict resolution right kind of by \naccident, simply because the default workflow of\n\n\t.. edit conflict to look ok ..\n\tgit commit file/with/conflict\n\nactually happens to do exactly the right thing (very much on purpose, \nbtw), but the fact is, to actually figure out more complicated conflicts \nand to _understand_ what happens, you absolutely need to be aware of the \nindex. Not being aware of it just isn't an option for any serious git \nuser.\n\n(Btw, I think this is where cogito falls down. Cogito tries to hide the \nindex file, but I don't think you really _can_ hide the index file and \nalso do merges well at the same time. Anybody who has non-trivial merges \nshould use raw git - not just because the \"recursive\" strategy just works \nbetter, but exactly because of the index file issue).\n\nSo when you work with a merge, the index file content really in a very \nreal way _is_ the merge. Yes, the index file is also technically how git \nactually does all the merging complexity, but in this case, there also is \nno \"diff\" to the parent, and the number of changed files may be in the \nhundreds, yet \"git diff\" should be basically empty when you finally commit \nyour merge.\n\nI say \"basically empty\", because as I've explained, at least I personally \nhave had dirty state in my tree at the time I commit a merge - on _top_ of \n(and independently of) the state that I actually commit.\n\nSo to recap:\n\n - you really do have to be aware of the index file at some point. Trying \n to hide it entirely is a huge mistake.\n\n - real git power users _will_ use their awareness of the index file when \n they commit. You will too, some day. Maybe it's only for merges, but I \n wouldn't be surprised if somebody at some point wants to take advantage \n of it even for \"normal\" working conditions (ie use \"git-update-index\" \n to \"freeze\" a certain state for committing, and then editing the file \n and _not_ committing those edits)\n\nSo making \"-a\" the default would be just a horrid horrid mistake. You can \nonly hide the index so far - don't even try to hide it more.\n\n\t\t\tLinus\n"},{"id":"15460","messageId":"7vek2mzec5.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"87irrya7bx.wl%cworth@cworth.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-02T02:25:46Z","receivedAt":"2006-02-02T02:25:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> If not, we should be able to simplify things since a lot of the\n> UI complexity being discussed (-a vs. no -a, path names vs. no path\n> names), hinges on the handling of skewed files.\n\nI am in agreement with you that \"skewed files\" might lead to\nconfusion, but I do not see how that relates to \"-a vs no -a\" nor\n\"path names vs no path names\" issues.\n\nLet's say we try to detect and forbid committing skewed files. How\nwould we do that? For the sake of clarity, let's say we fixed the\ncommit command the way I said in the message you are responding.\n\nNow:\n\n1. \"git commit\" is the traditional one; it commits the current index.\n We enumerate paths that 'git-diff-index --cached --name-only HEAD'\n tells are different (they are the paths to be committed -- what\n about merges? Maybe take union from all parents?). Then we see if\n the paths from \"git-diff-files --name-only\" (locally modified\n files) overlap with them. Overlapping ones will be skewed if we\n make a commit.\n\n2. \"git commit --also fileA...\" updates fileA... on top of the current\n index and commits that. After doing \"git update-index fileA...\",\n the story is the same as the previous case.\n\n3. \"git commit fileA...\" initializes a temporary index from the\n current HEAD, updates fileA... and commits that. We would need a\n check to make sure index matches HEAD at specified paths, but after\n that check passes, there is no skewed files being committed and\n there is nothing more to check.\n\n4. \"git commit -a\" by definition would not have skewed files and there\n is nothing to check.\n\nSo what you say sounds doable. But I wonder if that really helps\nmuch.\n\nLet's say we want to give an interface to a class of users who do\n_not_ want to worry about the presense of the index file. That means\nthey will _never_ run \"git update-index\" themselves, although \"git\ncommit\", \"git add\", and \"git merge\" may run update-index for them\ninternally. Essentially, you tell them to always use \"git commit -a\"\nor \"git commit fileA...\", and do not teach them \"git commit\", \"git\ncommit --also fileA...\". IOW they will be doing only 3 or 4. In this\ncase, we do not need any of the \"skewed files\" check.\n\nThe extra checks in 1 and 2 would prevent index-unaware users from\nmaking obvious mistakes, but if they do not understand index then they\nwould still be surprised anyway. For example, \"git commit\" commits\nthe files they previously run \"git add\" on, but leaves other modified\nfiles in the working tree uncommitted. This is different from either\n3 or 4 that they have learned so far. If they did \"git commit fileA\",\nthe file earlier they run \"git add\" is not committed. If they did\n\"git commit -a\", files other than the added files are also committed.\nSo in that sense the above checks are doable but I do not think it\nhelps that much to alleviate the confusion.\n\nThese extra checks in 1 and 2 may protect index-aware users from\nmaking mistakes, to a certain degree. I am not convinced enough\nmyself to pay the cost of extra checks, though, because my workflow is\nto do the final review exactly like what you said below.\n\n> My workflow has been to always perform a final review of such a diff\n> while composing the commit message. I'd like to be able to do that\n> with git.\n\nThat matches my workflow. I do either one of these (I never use \"git\ncommit paths...\"):\n\n\t$ work work work\n $ I may do update-index [--add|--remove] here\n $ git diff --cached\n $ git commit\n\n\t$ work work work\n $ I may do update-index [--add|--remove] here\n $ git diff HEAD\n $ git commit -a\n\nIn either cases \"skewed files\" do not matter. This can be summarized\nin a short paragraph:\n\n\tIf you are going to commit with \"git commit\" (no parameters),\n\tcheck the final result with \"git diff --cached\". If you are\n\tgoing to commit with \"git commit -a\", check with \"git diff\n\tHEAD\".\n\nI said why I do not do \"git commit paths...\" myself, but I think this\n\"skewed files\" discussion adds another thing to be careful about if\nyou use it. If you do this (with the current tool, you drop --also):\n\n\t$ work on file A\n $ git diff A\n ... that looks fine so far ...\n $ git update-index A\n $ work more on file A\n $ git diff A\n ... incrementally that looks fine ...\n $ git commit --also A\n\nyou would end up commiting something you have not done the \"final\nreview\". You need to have the final check before such a commit:\n\n\t$ work on file A\n $ git diff A\n ... that looks fine so far ...\n $ git update-index A\n $ work more on file A\n $ git diff A\n ... incrementally that looks fine ...\n +++++ $ git diff HEAD\n $ git commit --also A\n\nThis includes all changes that are not in the index and are not going\nto be included in the commit (i.e. changes to files other than A).\nFor that you may need to do something like:\n\n\tgit-diff-index --cached HEAD ;# already in index but do not look at A\n git-diff-index HEAD -- A ;# and path A is taken from working tree\n\nwhich is a bit cumbersome.\n\nWithout --also (the new semantics), the check would be\nstraightforward:\n\n\t$ work on file A\n $ git diff A\n ... that looks fine so far ...\n $ git update-index A\n $ work more on file A\n $ git diff A\n ... incrementally that looks fine ...\n +++++ $ git diff HEAD -- A\n\t$ git commit A\n"},{"id":"15481","messageId":"81b0412b0602020112l26f69728v11139ae84ea9b84f@mail.gmail.com","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602010815480.21884@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-02T09:12:26Z","receivedAt":"2006-02-02T09:12:26Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/1/06, Linus Torvalds wrote:\n> > $ time git update-index --refresh\n> >\n> > real 0m21.500s\n> > user 0m0.358s\n> > sys 0m1.406s\n> >\n> > WinNT, NTFS, 13k files, hot cache.\n>\n> That's 25% less files than the Linux kernel, and I can do that operation\n> in 0m0.062s (0.012s user, 0.048s system).\n\ncorrection. It's 18k files, which is almost the same as 2.6.13-rc6. But these\nfiles got *very* long names (the project poisoned by classical C++ education\nand breaks windows' 255 chars limit on filename length from time to time).\nRefresh index in 2.6.13 is actualy consistantly faster:\n\n$ cd src/linux-2.6.13-rc6\n$ time git update-index --refresh\nreal 0m1.344s\nuser 0m0.358s\nsys 0m0.984s\n\n> So WinNT/cygwin is about 2.5 _orders_of_maginitude_ slower here, or 340\n> times slower.\n>\n> Now, I'm tempted to say that NT is a piece of sh*t, but the fact is, your\n> CPU-times seem to indicate that most of it is IO (and the \"real\" cost is\n> just 1.7 seconds, much of which is system time, which in turn itself is\n> probably due to the IO costs too - so even that isn't comparable with\n> the ).\n>\n> Which may mean that you simply don't have enough memory to cache the whole\n> thing. Which may be NT sucking, of course (\"we don't like to use more than\n> 10% of memory for caches\"), but it might also be a tunable (which is sucky\n> in itself, of course), but finally, it might just be that you just don't\n> have a ton of memory. I've got 2GB in my machines, although 1GB is plenty\n> to cache the kernel.\n\nI have 2Gb, the \"System Cache\" is around 1.5Gb, and this is PIV 3.2GHz.\nThere seem to be no tunables for any kind of system stuff\n(savin' on support costs, do they?).\nYou'd be very hardpressed not to say that windows is a piece of sh*t.\n\nThe \"benchmark: several times in a row:\n\n$ time git update-index --refresh\nreal 0m1.766s\nuser 0m0.498s\nsys 0m1.203s\n\n$ time git update-index --refresh\nreal 0m1.766s\nuser 0m0.358s\nsys 0m1.390s\n\n$ time git update-index --refresh\nreal 0m1.781s\nuser 0m0.420s\nsys 0m1.311s\n\n$ time git update-index --refresh\nreal 0m1.875s\nuser 0m0.374s\nsys 0m1.343s\n\n$ time git update-index --refresh\nreal 0m1.766s\nuser 0m0.326s\nsys 0m1.375s\n\nIt is always almost the same time. I don't think it's IO, looks more like\ncache accesses. It is just that bad in this cygwin+win2k combination.\nBesides, I don't trust \"time \" on windows much: it returned\nsys time 0 for git-update-index in a directory which was read before.\nYes, there was disk activity, I can hear it real good with that barrakuda.\n"},{"id":"15488","messageId":"87mzhandqt.fsf@mid.deneb.enyo.de","threadId":"3153","inReplyTo":"87lkwupsbr.wl%cworth@cworth.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2006-02-02T12:31:38Z","receivedAt":"2006-02-02T12:31:38Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Carl Worth:\n\n> Here's a fundamental question I have, (and thanks to Keith Packard for\n> helping me to phrase it):\n>\n> \tIs it ever useful (reasonable, desirable) to commit file\n> \tcontents that differ from the contents of the working\n> \tdirectory?\n\nYou mean like \"darcs record\"? 8-)\n\nI think this is very useful functionality. Granted, it interferes\nwith a rigorous developer-side regression test policy (\"all changes\nmust have been built and passed the test suite\"). But it encourages\nthings like fixing typos in comments you spot while editing a file for\nother reasons. And you can keep some ugly debugging code while\nworking on a series of changes.\n"},{"id":"15516","messageId":"43E21E46.4040502@op5.se","threadId":"3153","inReplyTo":"7v8xsu7kys.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Census] So who uses git?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-02T14:59:18Z","receivedAt":"2006-02-02T14:59:18Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> I do not particularly have much preference among --also,\n> --with-index, or --incremental, but:\n> \n> - 'with-index' is precise but might be too technical;\n> - 'incremental' is not really incremental -- you can use it\n> only once.\n> \n> Because you do not have to say \"git commit --also\" without paths\n> (which _is_ awkward) to get the traditional behaviour, maybe it\n> is a good name for that flag (it is also the shortest).\n> \n\nExcept that -a, which is the logical shorthand, is already taken. How \nabout --include (or --include-index, or --index) and -i? commit being a \nfairly commonly used command, I think it's safe to assume that most \npeople will read the man-page or the help output if there's something \nthey don't undetstand.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"15491","messageId":"20060202163012.GB10937@hpsvcnb.fc.hp.com","threadId":"3153","inReplyTo":"87lkwupsbr.wl%cworth@cworth.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Carl Baldwin","fromEmail":"cnb@fc.hp.com","sentAt":"2006-02-02T16:30:12Z","receivedAt":"2006-02-02T16:30:12Z","isPatch":false,"sender":{"key":"cnb@fc.hp.com","avatar":null},"body":"On Wed, Feb 01, 2006 at 03:33:44PM -0800, Carl Worth wrote:\n> \tIs it ever useful (reasonable, desirable) to commit file\n> \tcontents that differ from the contents of the working\n> \tdirectory?\n\nWhat _is_ useful about the status quo is the ability to make some minor\nchange, update that change to the index when I've decided that it is a\ngood change and then use git diff to see what I've incrementally changed\nin the same file since that update. That way new incremental changes\ncan be viewed independantly of the change I've already decided was good.\n\n> What I would love to have is the ability to pass the same arguments to\n> git diff to get a preview of what any get commit would do. For\n> example, something like:\n> \n> \tgit diff\t\t# would be a preview of:\n> \tgit commit\n\n'git diff --cached' does this.\n\n> \tgit diff -a\t\t# would be a preview of:\n> \tgit commit -a\n\n'git diff HEAD' does this.\n\n> \tgit diff fileA fileB\t# would be a preview of:\n> \tgit commit fileA fileB\n\nPaths can be specified in conjunction with the above commands.\n\nYes, these are idioms specific to git and are not immediately intuitive\nto the new user. However, if the user has access to a good tutorial\nthat walks through these scenerios its not so bad.\n\nCarl\n\n-- \n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n Carl Baldwin RADCAD (R&D CAD)\n Hewlett Packard Company\n MS 88 work: 970 898-1523\n 3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com\n Fort Collins, CO 80525 home: Carl@ecBaldwin.net\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n"},{"id":"15541","messageId":"87mzh8vvuv.wl%cworth@cworth.org","threadId":"3153","inReplyTo":"7vek2mzec5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Two ideas for improving git's user interface","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-03T23:57:44Z","receivedAt":"2006-02-03T23:57:44Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"[I'm still hesitant to be jumping into this discussion with both feet\nlike this, so please imagine lots of disclaimers of ignorance before\nany claims I make---I would not be surprised or offended to learn I'm\nwildly wrong about how I think some things work.]\n\nOn Wed, 01 Feb 2006 18:25:46 -0800, Junio C Hamano wrote:\n> Carl Worth writes:\n> \n> > If not, we should be able to simplify things since a lot of the\n> > UI complexity being discussed (-a vs. no -a, path names vs. no path\n> > names), hinges on the handling of skewed files.\n> \n> I am in agreement with you that \"skewed files\" might lead to\n> confusion, but I do not see how that relates to \"-a vs no -a\" nor\n> \"path names vs no path names\" issues.\n\nIn the case of skewed files, \"-a\" commits the current file content,\nwhile \"no -a\" commits the skewed content. Similarly, \"path names\"\ncommits the current contents while \"no path names\" commits the skewed\ncontent.\n\n> Let's say we try to detect and forbid committing skewed files. How\n> would we do that?\n\nI wasn't imagining adding extra checks (== more complexity). Instead I\nwas imagining something like a command that would mark a path to be\ncommitted. I don't yet have a good suggestion for a short name for the\noperation, but I'll call it \"mark\" for sake of discussion. This mark\noperation would be used similarly to update-index but instead of\nstoring into the index an object created from the current contents of\nthe specified path, it would simply mark the path in the index as\nto-be-committed. When committing such a path later, the object would\nbe created based on the contents of the path at that time.\n\nSo I imagined eliminating skewed files first by providing operations\nbased around \"mark\" rather than update-index, (since \"mark\" avoids all\nof the confusing oops-I-committed-stale-file-contents scenarios), and\nsecond by making all commands that update the index from the object DB\nalso update the working directory, (effectively making git-read-tree\nalways act according to its current -u).\n\nBut as a prerequisite, this kind of plan would require the user to\nnever actually _want_ to stash skewed contents in the index. On a\nseparate branch of the current thread, Linus has said he likes to do\nthat, so I'll continue to discuss that there, and before the outcome\nof that discussion, this idea need not even be considered further.\n\n> 1. \"git commit\" is the traditional one; it commits the current index.\n> \n> 2. \"git commit --also fileA...\" updates fileA... on top of the current\n> \n> 3. \"git commit fileA...\" initializes a temporary index from the\n> \n> 4. \"git commit -a\" by definition would not have skewed files and there\n> is nothing to check.\n\nThe one comment I have about this proposal is a certain lack of\northogonality. Namely the base \"commit\" performs one operation,\n(committing the contents of the index), and \"commit --also\" performs\nthat same operation plus something more (that much is good so\nfar). The problem starts with \"commit file\" which does not perform the\nbase operation at all, but just does something different. Similarly,\n\"commit -a\" is also doing something different, (its behavior can be\ndescribed as an additional step performed _before_ the base \"commit\"\nbut could also be described as an operation independent of the\noriginal state of the index, if I'm not mistaken).\n\nBefore \"-a\" existed, there was better orthogonality, but apparently\nthere wasn't a good fit with what some users wanted to do, (hence the\naddition of \"-a\" and the recent proposal of yet more variations on\n\"commit\").\n\n> $ git diff --cached\n> $ git commit\n...\n> $ git diff HEAD\n> $ git commit -a\n...\n> For that you may need to do something like:\n> \n> \tgit-diff-index --cached HEAD ;# already in index but do not look at A\n> git-diff-index HEAD -- A ;# and path A is taken from working tree\n> \n> which is a bit cumbersome.\n> \n> Without --also (the new semantics), the check would be\n> straightforward:\n..\n> +++++ $ git diff HEAD -- A\n> \t$ git commit A\n\nThanks for the examples. If nothing else, I hope the above makes clear\nthat it's not always obvious how to achieve a preview diff of a\ncommit. I would love to see the number of fundamental variations of\n\"commit\" shrink rather than grow, but especially if it does grow, I\nthink it will always be important for users to be able to easily view\n\"status\" and \"diff\" previews of commits, (preferably by providing the\nsame arguments to some 'preview' commands as will be passed to\ncommit).\n\n-Carl\n"},{"id":"15543","messageId":"87lkwsvusp.wl%cworth@cworth.org","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602011656130.21884@g5.osdl.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-04T00:20:38Z","receivedAt":"2006-02-04T00:20:38Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 1 Feb 2006 17:23:38 -0800 (PST), Linus Torvalds wrote:\n>\n> I tend to have a certain fairly constant set of changes in my working \n> tree, namely every time a release is getting closer, I always tend to have \n> the \"Makefile\" already updated for the new version (but not checked in: I \n> do that just before I actually tag it, so that the tag will match the \n> commit that actually changes the version).\n\nOK. That use case I understand just fine.\n\n> However, if the question was an even stricter \"do you ever commit \n> _changes_ to a particular file where the last HEAD, the index _and_ the \n> working tree are all different\", then the answer is actually \"Yes\" to that \n> too.\n\nYes, this is the question I was trying to ask. Thanks for pretending\nthat I had actually asked it, and then answering it as well.\n\n> What has happened is that I have had merges that have content conflicts \n> that I fix up by hand, but exactly _because_ I fix them up by hand, I \n> actually want to re-compile the kernel and test my fixups.\n\nOK. I hadn't anticipated this use case, but I am interested in\nexploring it more fully.\n\n> And in that case, I will actually re-apply my manual Makefile change, even \n> if that file was part of the merge changes (in which case I had had to \n> first un-apply the change in order to do the merge).\n\nAre the un-apply and re-apply operations here primarily manual? or\ndoes git help you much with those (beyond alerting you that the merge\ncannot take place before you un-apply things)?\n\n> The thing is, once you get used to the git \"index\" as a staging place, \n> it's really really powerful.\n\nI believe that the staging operations you perform are quite desirable,\nbut I wonder if existing primitives in git might not provide a more\npowerful basis for the kinds of operation you're performing.\n\nFor example, in the case of the not-quite-ready-to-be-committed\nchanges that you want to carry along, couldn't you get additional\nbenefits if those changes could live on their own branch? I suppose\nthere may be a missing operator needed to allow you to easily merge\n*and* unmerge that branch if needed. Would that seem at all feasible?\n\nIf so, could your not-ready changes be implemented as some branch that\nis automatically unmerged prior to commit and then re-merged\nafterwards? Or something like that?\n\nI guess the feeling I get is that staging into the index feels\nconceptually similar to a commit to a branch, but it's a uniquely weak\nbranch (only one revision per file). And this uniqueness also\nintroduces complexity (the various diff operations), as well as\npossibilities of confusion when committing. Meanwhile the response to\nthe commit confusion seems to be to add yet more complexity to commit\nwhich doesn't seem like an improvement to me.\n\n[I'm maybe too far out on a limb at this point, since you've\ndefinitely identified a use case for staging in the index, and all\nI've offered as an alternative is hand-waving about \"branches should\nbe able to do that\". But if nothing else, I'm floating some ideas out\nloud, and next I'll try experimenting more with possibilities for\nnon-index staging.]\n\nI'm already having a lot of fun with git. It's a very impressive tool,\nwith a surprisingly simple/powerful core.\n\n> Actually, we do exactly that. Right now we expressly limit the \"preview\" \n> to just the filenames, but we literally do run\n> \n> \tgit-diff-index -M --cached --name-status --diff-filter=MDTCRA HEAD\n>\n> as part of \"git status\", and the eventual end result is what we will \n> populate the commit message file with for your editing pleasure.\n\nYes, that's a good thing to do. In my personal workflow, a\npre-populated commit message is a bit late, since I want to review and\nconvince myself I like things before I type the magic word \"commit\".\n\nAnd I'm not claiming that a preview patch is impossible to generate,\nI'm just saying that it's currently rather hard to figure what the correct\ncorrespondence for arguments to diff and arguments to commit, (see\nmore on this point in another branch of this thread).\n\n-Carl\n"},{"id":"15545","messageId":"Pine.LNX.4.64.0602031752160.3969@g5.osdl.org","threadId":"3153","inReplyTo":"87lkwsvusp.wl%cworth@cworth.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-04T02:08:19Z","receivedAt":"2006-02-04T02:08:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 3 Feb 2006, Carl Worth wrote:\n> \n> > And in that case, I will actually re-apply my manual Makefile change, even \n> > if that file was part of the merge changes (in which case I had had to \n> > first un-apply the change in order to do the merge).\n> \n> Are the un-apply and re-apply operations here primarily manual? or\n> does git help you much with those (beyond alerting you that the merge\n> cannot take place before you un-apply things)?\n\nThey're purely manual. If the changes are more extensive, I just create a \ntemporary branch for them, which is easy enough:\n\n\tgit checkout -b temp\n\tgit commit\n\tgit checkout master\n\nbefore I do the real merge, but the fact is, most of the changes in my \ntree tend to be pretty un-interesting. Most of the time it's literally \n_just_ the Makefile change, sometimes it's a trial patch that I'm not \nready commit and had just sent out to somebody for testing or similar.\n\n> I believe that the staging operations you perform are quite desirable,\n> but I wonder if existing primitives in git might not provide a more\n> powerful basis for the kinds of operation you're performing.\n\nNo. The point is that they are trivial to do, and that they don't _need_ \n\"powerful basis\".\n\nWhat they need is _usability_.\n\nAnd the git index _is_ that usability. It is incredibly powerful, and \nincredibly easy to use.\n\nWhen you argue against exposing the index, you argue against it from the \n\"let's not give them rope\" angle. You argue against power and flexibility. \n\nYou argue for the clippy, the helper app that says\n\n\tAre you sure you want to do this?\n\t\t[Yes] [No] [Cancel]\n\nwhile I'm trying to explain that it's actually part of the _power_ of git.\n\nThe fact, that I can keep dirty state in my tree and continue to work with \nit _without_ having to worry about it is a huge relief to me. \n\n> If so, could your not-ready changes be implemented as some branch that\n> is automatically unmerged prior to commit and then re-merged\n> afterwards? Or something like that?\n\nSure. They could. You could make things more complicated, and they would \nWORK. \n\nThey'd be inconvenient and not offer any actual improvement.\n\nThe \"index\" file in git really is very important.\n\nStaging into the index is _the_ most fundamental operation. You can't \nactually see it very well in the history of git (because the first commit \nexists only after git actually worked pretty fully), but the birth of git \nis really in the index file. That actually came _before_ the object store, \nas the way to quickly and efficiently track the notion of \"changes\".\n\nSo git itself started out very much with the index file being the staging \narea for tracking the state of a working tree efficiently.\n\nNo git operation actually ever lets the working tree interact directly \nwith the object store. The notion of \"diff this object against the \ncurrent working tree\" comes closest, but even that actually really goes \nthrough the index file: it's properly a \"diff this object against \nthe index file, and check at the same time the index entry against the \nworking tree\"\n\nIf you deny the index file, you really deny git itself.\n\nThink of it this way: when you start a new process, in UNIX you do that in \ntwo stages: first you fork() to create a copy, then you do exec() to \npopulate the copy with the new process. \n\nYour argument is akin to saying \"That's horribly wasteful: wouldn't it be \nmuch more intuitive to just do 'spawn()' to do it all, and avoid the \nunnecessary middle step\".\n\nBut that \"unnecessary\" middle step - whether it's \"fork()\" or the git \n\"index\" file - is actually the source of the flexibility. It's what allows \nyou to do the \"fixups\" in the middle when you switch file descriptors \naround, or when you fix up merge conflicts.\n\nAnd then occasionally, you do fork() _without_ doing an execve() at all. \nThe same way that sometimes you do operations on the index without \nactually committing them to a tree.\n\nThat's flexibility. Revel in it, instead of trying to push it under the \nrug. \n\n\t\t\tLinus\n"},{"id":"15559","messageId":"200602040803.45617.alan@chandlerfamily.org.uk","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602011732560.21884@g5.osdl.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-02-04T08:03:45Z","receivedAt":"2006-02-04T08:03:45Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Thursday 02 February 2006 01:44, Linus Torvalds wrote:\n> On Wed, 1 Feb 2006, Linus Torvalds wrote:\n> > And notice how I commit the _merge_ without actually committing my dirty\n> > state in the tree - and whether the files involved in my standard dirty\n> > changes (\"Makefile\") are part of the state that the merge changed or not\n> > is _totally_ irrelevant.\n>\n> If you get the feeling that merging is special, then to some degree, yes,\n> you'd be right.\n>\n> Merging (especially with conflicts) is the _one_ operation where you\n> absolutely have to know about the index. If you don't know about how the\n> index works, you can get the conflict resolution right kind of by\n> accident, simply because the default workflow of\n>\n> \t.. edit conflict to look ok ..\n> \tgit commit file/with/conflict\n>\n> actually happens to do exactly the right thing (very much on purpose,\n> btw), but the fact is, to actually figure out more complicated conflicts\n> and to _understand_ what happens, you absolutely need to be aware of the\n> index. Not being aware of it just isn't an option for any serious git\n> user.\n>\n> (Btw, I think this is where cogito falls down. Cogito tries to hide the\n> index file, but I don't think you really _can_ hide the index file and\n> also do merges well at the same time. Anybody who has non-trivial merges\n> should use raw git - not just because the \"recursive\" strategy just works\n> better, but exactly because of the index file issue).\n\n\nWow - light comes on.\n\nI have been using git (or rather to be exact git with cg-add, cg-rm and \ncg-commit) for about 6 months (bearing in mind I am only a part time \nprogrammer in the evenings for fun - even though I work in the computer \nindustry the last time I was paid to write code was in 1979 - so I don't \nreally need to be a power user). Although I knew about the index file since \nthe beginning I never really groked what it was about before.\n\nOf course I knew of its existance, and I even knew that it could be used as a \nstaging area, but up to now I had always thought of it as a necessary \ninconvenience to enable git to run as blazingly fast as it does - not as an \nessential part of work flow it complex situations\n\nI think the problem is with three crucial bits of documentation. Firstly, the \ndocument is full of the git doesn't do prorcelain statements - pushing towards \ncogito which then hides the existance of the index file. Git not doing \nporcelain was true at the very beginning, but I don't think that it is true \nany longer.\n\nSecondly the tutorial. The examples given start by using commands to \nexplicitly update the index and them they move on to show how you don't need \nto do that by using the more advanced commands of git-add and git-commit. So \nas I was trying to learn how to use git, I followed through this and thought \nthat you just try an avoid using it directly. Whats more, viewed in this \nlight git-commit seemed to be a rather poor implementation of cogito's \nsuperior cg-commit command\n\n[Incidentally there is a use case that doesn't seem to have been discussed in \nthis thread which I use cg-commit all the time for and will now have to see \nif there is a use index file equivalence for. That is, I am developing a web \napplication and in the running version the database framework (iBatis) is \nusing Tomcats connection pooling. In order to run my JUnit test harness, I \ndon't have tomcat, so I need to define a different version of iBatis \nconfiguration file to used its own database connection. So I have created a \ntest branch and edited the configuration file in that branch, and I update \nboth code and tests in a edit/compile/fix and text loop until I have written \nor changed both code and tests. I then do a cg-commit which lists the files \nI have changed. I ONLY commit those in the test harness - by deleting the \nothers from cogito's list of files to commit - and then repeat the commit \ncommiting the rest]. I then switch back to my master branch and cherry pick \ncommit that is the code changes - not the text harness] \n\nThirdly, \"discussion\" of the index file at the bottom end of the git man page \n(The \"index\" aka \"Current Directory Cache\") really concentrates on what it is \nand what operations you can perform with it in the normal situation.\n\nI tried looking at the core tutorial looking at what I might be a way of bring \nthis to the attention of the new learner into git and produced the following \n(partial) patch to the core-tutorial (It needs a whole set of examples on \nresolving merge problems which I have no idea at the moment how to do - this \nhas been the real area which never understood - basically because the \ntutorial itself says skip that part).\n\n--- a/Documentation/core-tutorial.txt\n+++ b/Documentation/core-tutorial.txt\n@@ -212,15 +212,22 @@ was just to show that `git-update-index`\n actually saved away the contents of your files into the git object\n database.\n\n+The Index File\n+--------------\n+\n Updating the index did something else too: it created a `.git/index`\n file. This is the index that describes your current working tree, and\n-something you should be very aware of. Again, you normally never worry\n-about the index file itself, but you should be aware of the fact that\n-you have not actually really \"checked in\" your files into git so far,\n-you've only *told* git about them.\n+something you should be very aware of. It is a staging area between your\n+working tree and the object store described above.\n+\n+In normal circumstances you do not worry about the index file itself, but you\n+should be aware of the fact that you have not actually really \"checked in\"\n+your files into git so far, you've only *told* git about them. Later you\n+will see how you can exploit the fact that there is this separate index\n+file to undertake more complex operations.\n\n-However, since git knows about them, you can now start using some of the\n-most basic git commands to manipulate the files or look at their status.\n+However, since git knows about these files, you can now start using some of\n+the most basic git commands to manipulate them or look at their status.\n\n In particular, let's not even check in the two files into git yet, we'll\n start off by adding another line to `hello` first:\n@@ -1188,8 +1195,8 @@ How does the merge work?\n We said this tutorial shows what plumbing does to help you cope\n with the porcelain that isn't flushing, but we so far did not\n talk about how the merge really works. If you are following\n-this tutorial the first time, I'd suggest to skip to \"Publishing\n-your work\" section and come back here later.\n+this tutorial the first time, I'd suggest to skip to \"Resolving Merge\n+Problems\" section and come back here later.\n\n OK, still with me? To give us an example to look at, let's go\n back to the earlier repository with \"hello\" and \"example\" file,\n@@ -1332,6 +1339,10 @@ merge for you to resolve. Notice that t\n unmerged, and what you see with `git diff` at this point is\n differences since stage 2 (i.e. your version).\n\n+Resolving Merge Problems\n+------------------------\n+\n+NOT SURE WHAT GOES HERE\n\n Publishing your work\n --------------------\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\nOpen Source. It's the difference between trust and antitrust.\n"},{"id":"15560","messageId":"7virrv4jk1.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"200602040803.45617.alan@chandlerfamily.org.uk","subject":"Re: Two ideas for improving git's user interface","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-04T08:25:34Z","receivedAt":"2006-02-04T08:25:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alan Chandler writes:\n\n> Wow - light comes on.\n\nThat's good.\n\n> -this tutorial the first time, I'd suggest to skip to \"Publishing\n> -your work\" section and come back here later.\n> +this tutorial the first time, I'd suggest to skip to \"Resolving Merge\n> +Problems\" section and come back here later.\n\nThe changes before this look very good to me, but these two\nlines do not make any sense. If you are going to talk about\n\"Resolving Merge Problems\", you _need_ to know about index, so\nyou cannot skip the material.\n\nI think having a section on manual merge resolution between the\nIndex File section and Publishing section makes sense. What\nkind of merges did you have trouble figuring out when you were\nstill git novice? That would be a good starting point.\n"},{"id":"15563","messageId":"200602040930.35727.alan@chandlerfamily.org.uk","threadId":"3153","inReplyTo":"7virrv4jk1.fsf@assigned-by-dhcp.cox.net","subject":"Re: Two ideas for improving git's user interface","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-02-04T09:30:35Z","receivedAt":"2006-02-04T09:30:35Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Saturday 04 February 2006 08:25, Junio C Hamano wrote:\n> Alan Chandler writes:\n> > Wow - light comes on.\n>\n> That's good.\n>\n> > -this tutorial the first time, I'd suggest to skip to \"Publishing\n> > -your work\" section and come back here later.\n> > +this tutorial the first time, I'd suggest to skip to \"Resolving Merge\n> > +Problems\" section and come back here later.\n>\n> The changes before this look very good to me, but these two\n> lines do not make any sense. If you are going to talk about\n> \"Resolving Merge Problems\", you _need_ to know about index, so\n> you cannot skip the material.\n\nMaybe - since the light has just come on, I need to understand a lot more \nabout this area before I can really comment. The tutorial invited one to \nskip it before, so I was just doing so again.\n\nEven today when I tried to read this section again my eyes glazed over. The \nlong sha outputs from git-ls-files screams off the page \"don't bother this is \ndetailed technical stuff\" :-(\n\n\n\n\n>\n> I think having a section on manual merge resolution between the\n> Index File section and Publishing section makes sense. What\n> kind of merges did you have trouble figuring out when you were\n> still git novice? That would be a good starting point.\n>\n\nI STILL come out in a cold sweat (actually that is a bit over the top:-) ) as \nsoon as a merge fails for whatever reason. The problem is that I am not \ndoing development full time, nor in a team, so I probably hit one about once \nevery 2 months. This means that I don't remember what to do, and need to go \nand look it up. But where - there is nothing in my main reference places \n(Everyday Git - or before that the tutorial). \n\nSo I normally attempt to do what I think is sensible. Manually searching for \nfiles that haven't merged. Edit the lines with the\n >>>>>>\n====\n<<< \nmarkers in them until I think the resultant file is what it should be and then \ntry commit again (probably cg-commit rather than git commit). But what \nhappens next is then hit or miss - sometimes it just works - sometimes it \ndoesn't and I am that place where there was a long thread a couple of months \nago entitled something like \"and what do I do now?\"\n\nI must admit it normally works OK - but I have come across situations a couple \nof weeks later where a file is in an unexpected state - seems to have been \nfrom the wrong branch, or missing a commit I thought I had made.\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\nOpen Source. It's the difference between trust and antitrust.\n"},{"id":"15640","messageId":"43E7BC55.8010908@citi.umich.edu","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311747360.7301@g5.osdl.org","subject":"Re: [Census] So who uses git?","fromName":"Chuck Lever","fromEmail":"cel@citi.umich.edu","sentAt":"2006-02-06T21:15:01Z","receivedAt":"2006-02-06T21:15:01Z","isPatch":false,"sender":{"key":"cel@citi.umich.edu","avatar":null},"body":"Linus Torvalds wrote:\n>>for comparison, one of our sandboxes is sitting on an NTFS file system,\n>>accessed via SMB:\n>>\n>> smbfs$ time git update-index --refresh\n>> real 11m36.502s\n>> user 0m6.830s\n>> sys 0m5.086s\n> \n> \n> Ouch, ouch, ouch.\n> \n> Sounds like every single stat() will go out the wire. I forget what the \n> Linux NFS client does, but I _think_ it has a metadata timeout that avoids \n> this. But it might be as bad under NFS.\n> \n> Has anybody used git over NFS? If it's this bad (or even close to), I \n> guess the \"mark files as up-to-date in the index\" approach is a really \n> good idea..\n> \n> Of course, the whole point of git is that you should keep your repository \n> close, but sometimes NFS - or similar - is enforced upon you by other \n> issues, like the fact that the powers-that-be want anonymous workstations \n> and everybody should work with a home-directory automounted over NFS..\n\nyes, i keep my Linux kernel repository in NFS (and my stgit and git \nrepositories too).\n\nthere are some things that are slow precisely because my think time is \nlonger than the NFS client's attribute timeout, which means that all of \ngit's lstat()s turn into GETATTRs.\n\nusing the \"noatime,nodiratime,actimeo=7200\" mount options can have some \nbenefit. however, i found that keeping the repository packed provides \nthe greatest positive impact. that means that most of the objects are \nin a single file, and can be validated with just one GETATTR.\n\none thing we might conclude from this is that making \"packing\" an \nefficient operation (or even an incremental one) would go a long way to \nhelping performance on network file systems.\n\n\nbegin:vcard\nfn:Chuck Lever\nn:Lever;Charles\norg:Network Appliance, Incorporated;Open Source NFS Client Development\nadr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA\nemail;internet:cel@citi.umich.edu\ntitle:Member of Technical Staff\ntel;work:+1 734 763 4415\ntel;fax:+1 734 763 4434\ntel;home:+1 734 668 1089\nx-mozilla-html:FALSE\nurl:http://troy.citi.umich.edu/u/cel/\nversion:2.1\nend:vcard\n\n"},{"id":"15650","messageId":"87ek2gdpfl.wl%cworth@cworth.org","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0602031752160.3969@g5.osdl.org","subject":"Re: Two ideas for improving git's user interface","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-02-06T23:42:54Z","receivedAt":"2006-02-06T23:42:54Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 3 Feb 2006 18:08:19 -0800 (PST), Linus Torvalds wrote:\n> \n> If you deny the index file, you really deny git itself.\n> \n\n[And the novice nearly reaches enlightenment.]\n\nOK. I now thoroughly understand that this use of the index is by\ndesign, not accident. So I won't propose modifying the index again.\n\nBut, I'm still not yet sure how to reconcile my personal workflow with\ngit yet. I don't think I'm yet an index-embracer that would relish\nusing \"update-index ; commit\" for everything. At the same time,\nI can appreciate the disdain for \"commit -a\" to the extent that it\ndoes deny the index.\n\nI suspect that what I want might fall somewhere in between, with\nsomething like \"mark ; commit-marked\" where commit-marked would\nupdate the index of all marked files, then commit. This would allow me\nto still use update-index for the times that I actually need to take\nadvantage of what that provides.\n\nSo, maybe I'll try scripting up something for that myself, (at the\nrisk of re-inventing cogito). Or maybe I'll just learn to live with\n(and love?) what git provides already.\n\n-Carl\n"},{"id":"15765","messageId":"7vek2di043.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"Pine.LNX.4.64.0601311807470.7301@g5.osdl.org","subject":"[PATCH] \"Assume unchanged\" git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-09T05:15:24Z","receivedAt":"2006-02-09T05:15:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> The real meat is just making sure that CE_VALID gets set/cleared properly.\n\nSetting is easier part. Deciding when to ignore/clear for the\nsake of safety and usability is harder. I think I got the\nbasics right but we might want to pass \"really\" from more places.\n\nThis is _not_ 1.2 material, but I think it is ready to be tested\nby people who asked for this feature. It applies on top of the\nrecent master branch.\n\n-- >8 --\n[PATCH] \"Assume unchanged\" git\n\nThis adds \"assume unchanged\" logic, started by this message in the list\ndiscussion recently:\n\n\t\n\nThis is a workaround for filesystems that do not have lstat()\nthat is quick enough for the index mechanism to take advantage\nof. On the paths marked as \"assumed to be unchanged\", the user\nneeds to explicitly use update-index to register the object name\nto be in the next commit.\n\nYou can use two new options to update-index to set and reset the\nCE_VALID bit:\n\n\tgit-update-index --assume-unchanged path...\n\tgit-update-index --no-assume-unchanged path...\n\nThese forms manipulate only the CE_VALID bit; it does not change\nthe object name recorded in the index file. Nor they add a new\nentry to the index.\n\nWhen the configuration variable \"core.ignorestat = true\" is set,\nthe index entries are marked with CE_VALID bit automatically\nafter:\n\n - update-index to explicitly register the current object name to the\n index file.\n\n - when update-index --refresh finds the path to be up-to-date.\n\n - when tools like read-tree -u and apply --index update the working\n tree file and register the current object name to the index file.\n\nThe flag is dropped upon read-tree that does not check out the index\nentry. This happens regardless of the core.ignorestat settings.\n\nIndex entries marked with CE_VALID bit are assumed to be\nunchanged most of the time. However, there are cases that\nCE_VALID bit is ignored for the sake of safety and usability:\n\n - while \"git-read-tree -m\" or git-apply need to make sure\n that the paths involved in the merge do not have local\n modifications. This sacrifices performance for safety.\n\n - when git-checkout-index -f -q -u -a tries to see if it needs\n to checkout the paths. Otherwise you can never check\n anything out ;-).\n\n - when git-update-index --really-refresh (a new flag) tries to\n see if the index entry is up to date. You can start with\n everything marked as CE_VALID and run this once to drop\n CE_VALID bit for paths that are modified.\n\nMost notably, \"update-index --refresh\" honours CE_VALID and does\nnot actively stat, so after you modified a file in the working\ntree, update-index --refresh would not notice until you tell the\nindex about it with \"git-update-index path\" or \"git-update-index\n--no-assume-unchanged path\".\n\nThis version is not expected to be perfect. I think diff\nbetween index and/or tree and working files may need some\nadjustment, and there probably needs other cases we should\nautomatically unmark paths that are marked to be CE_VALID.\n\nBut the basics seem to work, and ready to be tested by people\nwho asked for this feature.\n\nSigned-off-by: Junio C Hamano \n\n---\n\n apply.c | 2 +-\n cache.h | 6 +++--\n checkout-index.c | 1 +\n config.c | 5 ++++\n diff-files.c | 2 +-\n diff-index.c | 2 +-\n diff.c | 2 +-\n entry.c | 2 +-\n environment.c | 1 +\n read-cache.c | 28 +++++++++++++++++++----\n read-tree.c | 2 +-\n update-index.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++------\n write-tree.c | 2 +-\n 13 files changed, 99 insertions(+), 21 deletions(-)\n\nb169290f100cfa67b785c361bcae83f807487f5e\ndiff --git a/apply.c b/apply.c\nindex 2ad47fb..35ae48e 100644\n--- a/apply.c\n+++ b/apply.c\n@@ -1309,7 +1309,7 @@ static int check_patch(struct patch *pat\n \t\t\t\t\treturn -1;\n \t\t\t}\n \n-\t\t\tchanged = ce_match_stat(active_cache[pos], &st);\n+\t\t\tchanged = ce_match_stat(active_cache[pos], &st, 1);\n \t\t\tif (changed)\n \t\t\t\treturn error(\"%s: does not match index\",\n \t\t\t\t\t old_name);\ndiff --git a/cache.h b/cache.h\nindex bdbe2d6..cd58fad 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -91,6 +91,7 @@ struct cache_entry {\n #define CE_NAMEMASK (0x0fff)\n #define CE_STAGEMASK (0x3000)\n #define CE_UPDATE (0x4000)\n+#define CE_VALID (0x8000)\n #define CE_STAGESHIFT 12\n \n #define create_ce_flags(len, stage) htons((len) | ((stage) << CE_STAGESHIFT))\n@@ -144,8 +145,8 @@ extern int add_cache_entry(struct cache_\n extern int remove_cache_entry_at(int pos);\n extern int remove_file_from_cache(const char *path);\n extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);\n-extern int ce_match_stat(struct cache_entry *ce, struct stat *st);\n-extern int ce_modified(struct cache_entry *ce, struct stat *st);\n+extern int ce_match_stat(struct cache_entry *ce, struct stat *st, int);\n+extern int ce_modified(struct cache_entry *ce, struct stat *st, int);\n extern int ce_path_match(const struct cache_entry *ce, const char **pathspec);\n extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type);\n extern int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object);\n@@ -161,6 +162,7 @@ extern int commit_index_file(struct cach\n extern void rollback_index_file(struct cache_file *);\n \n extern int trust_executable_bit;\n+extern int assume_unchanged;\n extern int only_use_symrefs;\n extern int diff_rename_limit_default;\n extern int shared_repository;\ndiff --git a/checkout-index.c b/checkout-index.c\nindex 53dd8cb..957b4a8 100644\n--- a/checkout-index.c\n+++ b/checkout-index.c\n@@ -116,6 +116,7 @@ int main(int argc, char **argv)\n \tint all = 0;\n \n \tprefix = setup_git_directory();\n+\tgit_config(git_default_config);\n \tprefix_length = prefix ? strlen(prefix) : 0;\n \n \tif (read_cache() < 0) {\ndiff --git a/config.c b/config.c\nindex 8355224..7dbdce1 100644\n--- a/config.c\n+++ b/config.c\n@@ -222,6 +222,11 @@ int git_default_config(const char *var, \n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.ignorestat\")) {\n+\t\tassume_unchanged = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \tif (!strcmp(var, \"core.symrefsonly\")) {\n \t\tonly_use_symrefs = git_config_bool(var, value);\n \t\treturn 0;\ndiff --git a/diff-files.c b/diff-files.c\nindex d24d11c..c96ad35 100644\n--- a/diff-files.c\n+++ b/diff-files.c\n@@ -191,7 +191,7 @@ int main(int argc, const char **argv)\n \t\t\tshow_file('-', ce);\n \t\t\tcontinue;\n \t\t}\n-\t\tchanged = ce_match_stat(ce, &st);\n+\t\tchanged = ce_match_stat(ce, &st, 0);\n \t\tif (!changed && !diff_options.find_copies_harder)\n \t\t\tcontinue;\n \t\toldmode = ntohl(ce->ce_mode);\ndiff --git a/diff-index.c b/diff-index.c\nindex f8a102e..12a9418 100644\n--- a/diff-index.c\n+++ b/diff-index.c\n@@ -33,7 +33,7 @@ static int get_stat_data(struct cache_en\n \t\t\t}\n \t\t\treturn -1;\n \t\t}\n-\t\tchanged = ce_match_stat(ce, &st);\n+\t\tchanged = ce_match_stat(ce, &st, 0);\n \t\tif (changed) {\n \t\t\tmode = create_ce_mode(st.st_mode);\n \t\t\tif (!trust_executable_bit &&\ndiff --git a/diff.c b/diff.c\nindex ec51e7d..c72064e 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -311,7 +311,7 @@ static int work_tree_matches(const char \n \tce = active_cache[pos];\n \tif ((lstat(name, &st) < 0) ||\n \t !S_ISREG(st.st_mode) || /* careful! */\n-\t ce_match_stat(ce, &st) ||\n+\t ce_match_stat(ce, &st, 0) ||\n \t memcmp(sha1, ce->sha1, 20))\n \t\treturn 0;\n \t/* we return 1 only when we can stat, it is a regular file,\ndiff --git a/entry.c b/entry.c\nindex 6c47c3a..8fb99bc 100644\n--- a/entry.c\n+++ b/entry.c\n@@ -123,7 +123,7 @@ int checkout_entry(struct cache_entry *c\n \tstrcpy(path + len, ce->name);\n \n \tif (!lstat(path, &st)) {\n-\t\tunsigned changed = ce_match_stat(ce, &st);\n+\t\tunsigned changed = ce_match_stat(ce, &st, 1);\n \t\tif (!changed)\n \t\t\treturn 0;\n \t\tif (!state->force) {\ndiff --git a/environment.c b/environment.c\nindex 0596fc6..251e53c 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -12,6 +12,7 @@\n char git_default_email[MAX_GITNAME];\n char git_default_name[MAX_GITNAME];\n int trust_executable_bit = 1;\n+int assume_unchanged = 0;\n int only_use_symrefs = 0;\n int repository_format_version = 0;\n char git_commit_encoding[MAX_ENCODING_LENGTH] = \"utf-8\";\ndiff --git a/read-cache.c b/read-cache.c\nindex c5474d4..efbb1be 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -27,6 +27,9 @@ void fill_stat_cache_info(struct cache_e\n \tce->ce_uid = htonl(st->st_uid);\n \tce->ce_gid = htonl(st->st_gid);\n \tce->ce_size = htonl(st->st_size);\n+\n+\tif (assume_unchanged)\n+\t\tce->ce_flags |= htons(CE_VALID);\n }\n \n static int ce_compare_data(struct cache_entry *ce, struct stat *st)\n@@ -146,9 +149,18 @@ static int ce_match_stat_basic(struct ca\n \treturn changed;\n }\n \n-int ce_match_stat(struct cache_entry *ce, struct stat *st)\n+int ce_match_stat(struct cache_entry *ce, struct stat *st, int ignore_valid)\n {\n-\tunsigned int changed = ce_match_stat_basic(ce, st);\n+\tunsigned int changed;\n+\n+\t/*\n+\t * If it's marked as always valid in the index, it's\n+\t * valid whatever the checked-out copy says.\n+\t */\n+\tif (!ignore_valid && (ce->ce_flags & htons(CE_VALID)))\n+\t\treturn 0;\n+\n+\tchanged = ce_match_stat_basic(ce, st);\n \n \t/*\n \t * Within 1 second of this sequence:\n@@ -164,7 +176,7 @@ int ce_match_stat(struct cache_entry *ce\n \t * effectively mean we can make at most one commit per second,\n \t * which is not acceptable. Instead, we check cache entries\n \t * whose mtime are the same as the index file timestamp more\n-\t * careful than others.\n+\t * carefully than others.\n \t */\n \tif (!changed &&\n \t index_file_timestamp &&\n@@ -174,10 +186,10 @@ int ce_match_stat(struct cache_entry *ce\n \treturn changed;\n }\n \n-int ce_modified(struct cache_entry *ce, struct stat *st)\n+int ce_modified(struct cache_entry *ce, struct stat *st, int really)\n {\n \tint changed, changed_fs;\n-\tchanged = ce_match_stat(ce, st);\n+\tchanged = ce_match_stat(ce, st, really);\n \tif (!changed)\n \t\treturn 0;\n \t/*\n@@ -233,6 +245,11 @@ int cache_name_compare(const char *name1\n \t\treturn -1;\n \tif (len1 > len2)\n \t\treturn 1;\n+\n+\t/* Differences between \"assume up-to-date\" should not matter. */\n+\tflags1 &= ~CE_VALID;\n+\tflags2 &= ~CE_VALID;\n+\n \tif (flags1 < flags2)\n \t\treturn -1;\n \tif (flags1 > flags2)\n@@ -430,6 +447,7 @@ int add_cache_entry(struct cache_entry *\n \tint ok_to_add = option & ADD_CACHE_OK_TO_ADD;\n \tint ok_to_replace = option & ADD_CACHE_OK_TO_REPLACE;\n \tint skip_df_check = option & ADD_CACHE_SKIP_DFCHECK;\n+\n \tpos = cache_name_pos(ce->name, ntohs(ce->ce_flags));\n \n \t/* existing match? Just replace it. */\ndiff --git a/read-tree.c b/read-tree.c\nindex 5580f15..52f06e3 100644\n--- a/read-tree.c\n+++ b/read-tree.c\n@@ -349,7 +349,7 @@ static void verify_uptodate(struct cache\n \t\treturn;\n \n \tif (!lstat(ce->name, &st)) {\n-\t\tunsigned changed = ce_match_stat(ce, &st);\n+\t\tunsigned changed = ce_match_stat(ce, &st, 1);\n \t\tif (!changed)\n \t\t\treturn;\n \t\terrno = 0;\ndiff --git a/update-index.c b/update-index.c\nindex afec98d..767fd49 100644\n--- a/update-index.c\n+++ b/update-index.c\n@@ -23,6 +23,10 @@ static int quiet; /* --refresh needing u\n static int info_only;\n static int force_remove;\n static int verbose;\n+static int mark_valid_only = 0;\n+#define MARK_VALID 1\n+#define UNMARK_VALID 2\n+\n \n /* Three functions to allow overloaded pointer return; see linux/err.h */\n static inline void *ERR_PTR(long error)\n@@ -53,6 +57,25 @@ static void report(const char *fmt, ...)\n \tva_end(vp);\n }\n \n+static int mark_valid(const char *path)\n+{\n+\tint namelen = strlen(path);\n+\tint pos = cache_name_pos(path, namelen);\n+\tif (0 <= pos) {\n+\t\tswitch (mark_valid_only) {\n+\t\tcase MARK_VALID:\n+\t\t\tactive_cache[pos]->ce_flags |= htons(CE_VALID);\n+\t\t\tbreak;\n+\t\tcase UNMARK_VALID:\n+\t\t\tactive_cache[pos]->ce_flags &= ~htons(CE_VALID);\n+\t\t\tbreak;\n+\t\t}\n+\t\tactive_cache_changed = 1;\n+\t\treturn 0;\n+\t}\n+\treturn -1;\n+}\n+\n static int add_file_to_cache(const char *path)\n {\n \tint size, namelen, option, status;\n@@ -94,6 +117,7 @@ static int add_file_to_cache(const char \n \tce = xmalloc(size);\n \tmemset(ce, 0, size);\n \tmemcpy(ce->name, path, namelen);\n+\tce->ce_flags = htons(namelen);\n \tfill_stat_cache_info(ce, &st);\n \n \tce->ce_mode = create_ce_mode(st.st_mode);\n@@ -105,7 +129,6 @@ static int add_file_to_cache(const char \n \t\tif (0 <= pos)\n \t\t\tce->ce_mode = active_cache[pos]->ce_mode;\n \t}\n-\tce->ce_flags = htons(namelen);\n \n \tif (index_path(ce->sha1, path, &st, !info_only))\n \t\treturn -1;\n@@ -128,7 +151,7 @@ static int add_file_to_cache(const char \n * For example, you'd want to do this after doing a \"git-read-tree\",\n * to link up the stat cache details with the proper files.\n */\n-static struct cache_entry *refresh_entry(struct cache_entry *ce)\n+static struct cache_entry *refresh_entry(struct cache_entry *ce, int really)\n {\n \tstruct stat st;\n \tstruct cache_entry *updated;\n@@ -137,21 +160,22 @@ static struct cache_entry *refresh_entry\n \tif (lstat(ce->name, &st) < 0)\n \t\treturn ERR_PTR(-errno);\n \n-\tchanged = ce_match_stat(ce, &st);\n+\tchanged = ce_match_stat(ce, &st, really);\n \tif (!changed)\n \t\treturn NULL;\n \n-\tif (ce_modified(ce, &st))\n+\tif (ce_modified(ce, &st, really))\n \t\treturn ERR_PTR(-EINVAL);\n \n \tsize = ce_size(ce);\n \tupdated = xmalloc(size);\n \tmemcpy(updated, ce, size);\n \tfill_stat_cache_info(updated, &st);\n+\n \treturn updated;\n }\n \n-static int refresh_cache(void)\n+static int refresh_cache(int really)\n {\n \tint i;\n \tint has_errors = 0;\n@@ -171,12 +195,19 @@ static int refresh_cache(void)\n \t\t\tcontinue;\n \t\t}\n \n-\t\tnew = refresh_entry(ce);\n+\t\tnew = refresh_entry(ce, really);\n \t\tif (!new)\n \t\t\tcontinue;\n \t\tif (IS_ERR(new)) {\n \t\t\tif (not_new && PTR_ERR(new) == -ENOENT)\n \t\t\t\tcontinue;\n+\t\t\tif (really && PTR_ERR(new) == -EINVAL) {\n+\t\t\t\t/* If we are doing --really-refresh that\n+\t\t\t\t * means the index is not valid anymore.\n+\t\t\t\t */\n+\t\t\t\tce->ce_flags &= ~htons(CE_VALID);\n+\t\t\t\tactive_cache_changed = 1;\n+\t\t\t}\n \t\t\tif (quiet)\n \t\t\t\tcontinue;\n \t\t\tprintf(\"%s: needs update\\n\", ce->name);\n@@ -274,6 +305,8 @@ static int add_cacheinfo(unsigned int mo\n \tmemcpy(ce->name, path, len);\n \tce->ce_flags = create_ce_flags(len, stage);\n \tce->ce_mode = create_ce_mode(mode);\n+\tif (assume_unchanged)\n+\t\tce->ce_flags |= htons(CE_VALID);\n \toption = allow_add ? ADD_CACHE_OK_TO_ADD : 0;\n \toption |= allow_replace ? ADD_CACHE_OK_TO_REPLACE : 0;\n \tif (add_cache_entry(ce, option))\n@@ -317,6 +350,12 @@ static void update_one(const char *path,\n \t\tfprintf(stderr, \"Ignoring path %s\\n\", path);\n \t\treturn;\n \t}\n+\tif (mark_valid_only) {\n+\t\tif (mark_valid(p))\n+\t\t\tdie(\"Unable to mark file %s\", path);\n+\t\treturn;\n+\t}\n+\n \tif (force_remove) {\n \t\tif (remove_file_from_cache(p))\n \t\t\tdie(\"git-update-index: unable to remove %s\", path);\n@@ -467,7 +506,11 @@ int main(int argc, const char **argv)\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t\tif (!strcmp(path, \"--refresh\")) {\n-\t\t\t\thas_errors |= refresh_cache();\n+\t\t\t\thas_errors |= refresh_cache(0);\n+\t\t\t\tcontinue;\n+\t\t\t}\n+\t\t\tif (!strcmp(path, \"--really-refresh\")) {\n+\t\t\t\thas_errors |= refresh_cache(1);\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t\tif (!strcmp(path, \"--cacheinfo\")) {\n@@ -493,6 +536,14 @@ int main(int argc, const char **argv)\n \t\t\t\t\tdie(\"git-update-index: %s cannot chmod %s\", path, argv[i]);\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(path, \"--assume-unchanged\")) {\n+\t\t\t\tmark_valid_only = MARK_VALID;\n+\t\t\t\tcontinue;\n+\t\t\t}\n+\t\t\tif (!strcmp(path, \"--no-assume-unchanged\")) {\n+\t\t\t\tmark_valid_only = UNMARK_VALID;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(path, \"--info-only\")) {\n \t\t\t\tinfo_only = 1;\n \t\t\t\tcontinue;\ndiff --git a/write-tree.c b/write-tree.c\nindex f866059..addb5de 100644\n--- a/write-tree.c\n+++ b/write-tree.c\n@@ -111,7 +111,7 @@ int main(int argc, char **argv)\n \tfunny = 0;\n \tfor (i = 0; i < entries; i++) {\n \t\tstruct cache_entry *ce = active_cache[i];\n-\t\tif (ntohs(ce->ce_flags) & ~CE_NAMEMASK) {\n+\t\tif (ce_stage(ce)) {\n \t\t\tif (10 < ++funny) {\n \t\t\t\tfprintf(stderr, \"...\\n\");\n \t\t\t\tbreak;\n-- \n1.1.6.gbb042\n"},{"id":"15767","messageId":"7virrpgjyc.fsf_-_@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"7vek2di043.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] \"Assume unchanged\" git: do not set CE_VALID with --refresh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-09T05:49:47Z","receivedAt":"2006-02-09T05:49:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When working with automatic assume-unchanged mode using\ncore.ignorestat, setting CE_VALID after --refresh makes things\nmore cumbersome to use. Consider this scenario:\n\n (1) the working tree is on a filesystem with slow lstat(2).\n The user sets core.ignorestat = true.\n\n (2) \"git checkout\" to switch to a different branch (or initial\n checkout) updates all paths and the index starts out with\n \"all clean\".\n\n (3) The user knows she wants to edit certain paths. She uses\n update-index --no-assume-unchanged (we could call it --edit;\n the name is inmaterial) to mark these paths and starts\n editing.\n\n (4) After editing half of the paths marked to be edited, she\n runs \"git status\". This runs \"update-index --refresh\" to\n reduce the false hits from diff-files.\n\n (5) Now the other half of the paths, since she has not changed\n them, are found to match the index, and CE_VALID is set on\n them again.\n\nFor this reason, this commit makes update-index --refresh not to\nset CE_VALID even after the path without CE_VALID are verified\nto be up to date. The user still can run --really-refresh to\nforce lstat() to match the index entries to the reality.\n\nSigned-off-by: Junio C Hamano \n\n---\n\n update-index.c | 9 +++++++++\n 1 files changed, 9 insertions(+), 0 deletions(-)\n\nfd4e57f17733d85ed5346d70005ea900cb80b9ff\ndiff --git a/update-index.c b/update-index.c\nindex 767fd49..bb73050 100644\n--- a/update-index.c\n+++ b/update-index.c\n@@ -172,6 +172,15 @@ static struct cache_entry *refresh_entry\n \tmemcpy(updated, ce, size);\n \tfill_stat_cache_info(updated, &st);\n \n+\t/* In this case, if really is not set, we should leave\n+\t * CE_VALID bit alone. Otherwise, paths marked with\n+\t * --no-assume-unchanged (i.e. things to be edited) will\n+\t * reacquire CE_VALID bit automatically, which is not\n+\t * really what we want.\n+\t */\n+\tif (!really && assume_unchanged && !(ce->ce_flags & htons(CE_VALID)))\n+\t\tupdated->ce_flags &= ~htons(CE_VALID);\n+\n \treturn updated;\n }\n \n-- \n1.1.6.gbb042\n"},{"id":"15768","messageId":"7vd5hxgjxh.fsf@assigned-by-dhcp.cox.net","threadId":"3153","inReplyTo":"7vek2di043.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] ls-files: debugging aid for CE_VALID changes.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-09T05:50:18Z","receivedAt":"2006-02-09T05:50:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This is not really part of the proposed updates for CE_VALID,\nbut with this change, ls-files -t shows CE_VALID paths with\nlowercase tag letters instead of the usual uppercase. Useful\nfor checking out what is going on.\n\nSigned-off-by: Junio C Hamano \n\n---\n\n ls-files.c | 18 +++++++++++++++++-\n 1 files changed, 17 insertions(+), 1 deletions(-)\n\n775ca05ee2ba7e1f54ec4db1fed7069014364f2c\ndiff --git a/ls-files.c b/ls-files.c\nindex 6af3b09..3f06ece 100644\n--- a/ls-files.c\n+++ b/ls-files.c\n@@ -447,6 +447,22 @@ static void show_ce_entry(const char *ta\n \tif (pathspec && !match(pathspec, ce->name, len))\n \t\treturn;\n \n+\tif (tag && *tag && (ce->ce_flags & htons(CE_VALID))) {\n+\t\tstatic char alttag[4];\n+\t\tmemcpy(alttag, tag, 3);\n+\t\tif (isalpha(tag[0]))\n+\t\t\talttag[0] = tolower(tag[0]);\n+\t\telse if (tag[0] == '?')\n+\t\t\talttag[0] = '!';\n+\t\telse {\n+\t\t\talttag[0] = 'v';\n+\t\t\talttag[1] = tag[0];\n+\t\t\talttag[2] = ' ';\n+\t\t\talttag[3] = 0;\n+\t\t}\n+\t\ttag = alttag;\n+\t}\n+\n \tif (!show_stage) {\n \t\tfputs(tag, stdout);\n \t\twrite_name_quoted(\"\", 0, ce->name + offset,\n@@ -503,7 +519,7 @@ static void show_files(void)\n \t\t\terr = lstat(ce->name, &st);\n \t\t\tif (show_deleted && err)\n \t\t\t\tshow_ce_entry(tag_removed, ce);\n-\t\t\tif (show_modified && ce_modified(ce, &st))\n+\t\t\tif (show_modified && ce_modified(ce, &st, 0))\n \t\t\t\tshow_ce_entry(tag_modified, ce);\n \t\t}\n \t}\n-- \n1.1.6.gbb042\n"}]}