{"thread":{"id":"7712","subject":"GIT vs Other: Need argument","startedAt":"2007-04-17T09:02:18Z","lastAt":"2007-04-30T04:31:36Z","messageCount":120,"participants":["Pietro Mascagni","Matthieu Moy","Andy Parkins","Martin Langhoff","Tomash Brechko","Alex Riesen","Linus Torvalds","Guilhem Bonnefille","Shawn O. Pearce","Marcin Kasperski","Sam Vilain","Johannes Schindelin","Nicolas Pitre","Bill Lear","Steven Grimm","Yann Dirson","Theodore Tso","Michael K. Edwards","Daniel Barkalow","Jakub Narebski","Junio C Hamano","Julian Phillips","Christian MICHON","Petr Baudis","J. Bruce Fields","Karl Hasselström","Eric Blake","Jan Harkes","Carl Worth","Josef Weidendorfer","Brian Gernhardt","Dana How"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39620","messageId":"aa69c80b0704170202r3f35acc7ydb81708e747c69ff@mail.gmail.com","threadId":"7712","inReplyTo":null,"subject":"GIT vs Other: Need argument","fromName":"Pietro Mascagni","fromEmail":"pietromas@gmail.com","sentAt":"2007-04-17T09:02:18Z","receivedAt":"2007-04-17T09:02:18Z","isPatch":false,"sender":{"key":"pietromas@gmail.com","avatar":null},"body":"I am dealing with idiots. I'd rather not argue with them, but sadly I\ncannot ignore them as they are my \"seniors\".\n\nSo, in 15 seconds, how does one argue that GIT is vastly superior to\nother version control software, especially CVS.\n\nThanks,\nP.\n"},{"id":"39622","messageId":"vpqejmjjrdp.fsf@bauges.imag.fr","threadId":"7712","inReplyTo":"aa69c80b0704170202r3f35acc7ydb81708e747c69ff@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-04-17T09:13:06Z","receivedAt":"2007-04-17T09:13:06Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Pietro Mascagni\" writes:\n\n> So, in 15 seconds, how does one argue that GIT is vastly superior to\n> other version control software, especially CVS.\n\nVs CVS, in 15 seconds, I'd say:\n\n* Atomic commits. CVS makes it hard to get back to a consistant state\n in the past. What does it mean, for example to checkout revision 1.5\n of a project in CVS (hint: nothing, it's meaningfull for a file\n only).\n\n* Rename management.\n\n* Performance.\n\n* Perhaps your boss will be interested in the \"data integrity\" (i.e.\n git fsck) problem too.\n\nYou have also the joker argument \"Linus Torvalds is very intelligent,\nand he gave up with CVS looong ago\", but it might or might not work.\n\nIf you have to argue against SVN, you'll need more than 15\nseconds ;-).\n\n-- \nMatthieu\n"},{"id":"39634","messageId":"200704171126.48793.andyparkins@gmail.com","threadId":"7712","inReplyTo":"vpqejmjjrdp.fsf@bauges.imag.fr","subject":"Re: GIT vs Other: Need argument","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-17T10:26:47Z","receivedAt":"2007-04-17T10:26:47Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 April 17 10:13, Matthieu Moy wrote:\n\n> * Atomic commits. CVS makes it hard to get back to a consistant state\n> in the past. What does it mean, for example to checkout revision 1.5\n> of a project in CVS (hint: nothing, it's meaningfull for a file\n> only).\n>\n> * Rename management.\n>\n> * Performance.\n>\n> * Perhaps your boss will be interested in the \"data integrity\" (i.e.\n> git fsck) problem too.\n\nDon't forget\n * Can work offline\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"39636","messageId":"46a038f90704170333t38992792m77ddb3d927b21842@mail.gmail.com","threadId":"7712","inReplyTo":"aa69c80b0704170202r3f35acc7ydb81708e747c69ff@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-17T10:33:46Z","receivedAt":"2007-04-17T10:33:46Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/17/07, Pietro Mascagni wrote:\n> So, in 15 seconds, how does one argue that GIT is vastly superior to\n> other version control software, especially CVS.\n\nAdding some ammunition:\n\n - Old school SCMs allow you to branch, but are unable to keep track\nof merges in any meaningful way. Every time you merge, history is\nlost. GIT (and other DSCMs) have excellent branching _and_ merging\nfacilities.\n\n - Speed (try it on you project repo, or if the project is new, on a\nrepo sized to what you'd expectyour project to be).\n\n - Disconnected development. Checkouts on your laptop, continue\nworking when the server is down.\n\n - Extremely powerful and flexible if you are using the SCM to manage\nthe deployment.\n\n - Behaves transactionally, even when doing things like applying patches\n\n - Anon GIT is much easier to run (via http)\n\n - If the team is large, of for any reason the code needs review, you\ncan setup a tiered review/merge scheme like the linux team does --\ninstead of a shared repo, each developer has their own repos, and\nintegrators review and merge (or reject!).\n\n - Signed tags for releases\n\nAnd yet... If the project ends up using CVS, you can setup your\ncvs->git gateway. Even if you are always at the office, and just use\nCVS most of the time, It's enormously useful to be able to call gitk,\nuse pickaxe, etc. And just by having those tools around your project\nwill probably benefit.\n\ncheers,\n\n\nmartin\n"},{"id":"39637","messageId":"46a038f90704170337k41ea4af0uc80dd2863ed477c3@mail.gmail.com","threadId":"7712","inReplyTo":"vpqejmjjrdp.fsf@bauges.imag.fr","subject":"Re: GIT vs Other: Need argument","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-17T10:37:11Z","receivedAt":"2007-04-17T10:37:11Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/17/07, Matthieu Moy wrote:\n> If you have to argue against SVN, you'll need more than 15\n> seconds ;-).\n\n - Same branch/merge limitations as CVS: knows how to branch, not how\nto merge :-/\n\n - Repository corruption / Berkeley DB\n\ncheers,\n\n\nmartin\n"},{"id":"39639","messageId":"20070417104520.GB4946@moonlight.home","threadId":"7712","inReplyTo":"aa69c80b0704170202r3f35acc7ydb81708e747c69ff@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Tomash Brechko","fromEmail":"tomash.brechko@gmail.com","sentAt":"2007-04-17T10:45:20Z","receivedAt":"2007-04-17T10:45:20Z","isPatch":false,"sender":{"key":"tomash.brechko@gmail.com","avatar":null},"body":"On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:\n> So, in 15 seconds, how does one argue that GIT is vastly superior to\n> other version control software, especially CVS.\n\nI think you are not talking about choosing SCM for a new project, as\nit is even _hard to imagine_ that one would consider CVS nowadays :).\nAnd if you are trying to convince people to do the migration from CVS\nto GIT, then technical points alone won't probably help you. GIT, and\nactually most modern SCMs, are superior to CVS not simply because they\nhave some CVS's features improved, and some nice features added.\nModern SCMs implement completely different workflow model. GIT's own\npower in its rich toolset, but until people learn (or at least are\nwilling to learn) what the workflow is, and how it is supported by\nthese tools, there's little advantage in migration. You can't really\nexplain why 'git commit; git push' into some central repository is\nbetter than 'cvs commit', and pushing after every commit is what\npeople will be doing at first ;). You should also realize that the\nwhole process is probably already built around CVS (CVS-specific\nhooks, scripts that access CVS, say, for nightly testing, etc), that\nwould also have to be reimplemented.\n\nYou may consider another route: create a GIT mirror of CVS repository,\nand update it, say, daily, with git-cvsimport. Clone from this\nmirror, and work with your own GIT tree, pushing back to CVS with\ngit-cvsexportcommit. Yes, you will be dealing with problems that\nwouldn't be there in the first place if everyone would use GIT, and\nyou will basically use CVS workflow, but still, this way is quite\nmanageable. Then approach the most promising guy in the company, and\nexplain to him how you benefit from using GIT (gitk/qgit, git-bisect,\nStGIT are among your friends here :)). As the saying goes, \"Better to\nsee once, then to hear about a hundred of times\". You are not\ninterested in instant migration, and then being blamed if anything\nwould go wrong. When you will grow sufficient number of GIT experts\nin your company, then you will raise the migration question again.\n\n\nGood luck!\n\n-- \n Tomash Brechko\n"},{"id":"39650","messageId":"81b0412b0704170732g480794bcpa97a5f7d6b02fbd@mail.gmail.com","threadId":"7712","inReplyTo":"200704171126.48793.andyparkins@gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-17T14:32:38Z","receivedAt":"2007-04-17T14:32:38Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/17/07, Andy Parkins wrote:\n>\n> Don't forget\n> * Can work offline\n>\n\nBad argument with seniors. Being able to take your work home\nconsidered security breach. Being able to work indepently of the\nclueless technical support team considered inability to delegate\n(like \"pass the blame on\").\n\nThis one is already tried with the described effect.\n"},{"id":"39652","messageId":"81b0412b0704170739te4c35f0m8e4a3cd5bad440cd@mail.gmail.com","threadId":"7712","inReplyTo":"46a038f90704170333t38992792m77ddb3d927b21842@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-17T14:39:41Z","receivedAt":"2007-04-17T14:39:41Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/17/07, Martin Langhoff wrote:\n>\n> - Old school SCMs allow you to branch, but are unable to keep track\n> of merges in any meaningful way. Every time you merge, history is\n> lost. GIT (and other DSCMs) have excellent branching _and_ merging\n> facilities.\n>\n\nThis one was a bad argument too. Curiously, and I cannot explain why,\nability to branch is considered a weakness of GIT (\"because it confuses\nthe integrators\", them being old mean men). The Perforce is said to\nbe \"vastly superior to everything\" on these grounds: \"it also has\nbranching support, but luckily(!) it is hard enough for simple\ndevelopers. Was not their (Perforce's) fault, they just included it\nto keep up with the market\". Almost exact wording (I had to translate it).\n"},{"id":"39657","messageId":"Pine.LNX.4.64.0704170816390.5473@woody.linux-foundation.org","threadId":"7712","inReplyTo":"vpqejmjjrdp.fsf@bauges.imag.fr","subject":"Re: GIT vs Other: Need argument","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-17T15:28:22Z","receivedAt":"2007-04-17T15:28:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 Apr 2007, Matthieu Moy wrote:\n> \n> * Perhaps your boss will be interested in the \"data integrity\" (i.e.\n> git fsck) problem too.\n\nThe data integrity thing is a lot more than just fsck.\n\nI care a lot about my data, and it's an area where a *lot* of systems fall \ndown. CVS is just about the worst (basically no checksums or sanity \nchecking anywhere), and you can pretty much have total data corruption \nwithout ever even _realizing_, until you try to get some old version.\n\nEven more interesting with CVS is that you can have total data corruption \nand you'll not realize it *even*as* you use the data. Lots of people and \nprojects have been known to happily move *,v files around and edit the \nCVS repo files by hand to make things look right, which means that not \nonly did you do a \"rename\" in CVS, you actually renamed *retroactively* \ntoo - you made history look wrong!\n\nSo with CVS, you actually have no guarantees what-so-ever that when you \ncheck out something old, you'll get what you actually used to have. You \ncan tag things as much as you want - if people end up editing the CVS \nfiles (and people *do* that), you'll never have any indication that the \nhistory you checked out isn't the \"real\" history. So you can check out \nsome old version that you made a release to a customer off, and may be \ntotally unable to recreate the customer problem, because the release you \nchecked out doesn't even compile any more!\n\nYou can actually do the same with most other SCM's. It may need somebody \nwho is actually malicious, but even that isn't necessarily the case. Lots \nof SCM's don't have any checksums *at*all* on their data - the only way \nyou'd ever know that something bad happened and you had disk corruption, \nis when you check something out and it just looks corrupted!\n\nIn other words, in a lot of SCM's, you're actually *lucky* if the \ncorruption is so serious that it's not just a subtle \"data is wrong\" \nthing, it's so pervasive that you actually get an error from the SCM.\n\nIn git, every *single* piece of data is not just checksummed, it's \nCHECKSUMMED. Yeah, we use CRC's and Adler32 for some things, but even \nthose are actually *also* protected at a higher level by real \ncryptographic hashes. You simply *cannot* corrupt data by mistake and not \nknow about it. You can lose it, you can corrupt it, but it *will* be \nnoticed.\n\nIf that doesn't make you feel good about your data, I don't know what \nwill. Git will not replace backups in any way, shape, or form (although \nyou can obviously use git itself to _do_ those backups - the joy of \ndistributed SCMS), but it will tell you when you *need* those backups. \n\nGuaranteed.\n\nAnd I can tell you that that is actually very rare. I doubt *any* \ncommercial SCM will come even close. They might have checksums, but \nnothing really strong. It might be a CRC or even weaker. Or it might be \nnothing at all (and sadly, that's the *common* case).\n\n\t\t\t\tLinus\n"},{"id":"39659","messageId":"8b65902a0704170841q64fe0828mdefe78963394a616@mail.gmail.com","threadId":"7712","inReplyTo":"20070417104520.GB4946@moonlight.home","subject":"Re: GIT vs Other: Need argument","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2007-04-17T15:41:27Z","receivedAt":"2007-04-17T15:41:27Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"I'm new to Git, but completly crazy of it.\n\nIn my point of view, in corporate team, lot of people does not\nwant/need the power offered by Git.\nSo, my conclusion is the better model in a corporate is a centralyzed\nrepo with some users using Git as \"frontend\". Other people will simply\nuse the native tools for accessing the repo.\n\nI didn't try Git with CVS repo but seems less usable in day to day\nwork than a SVN repo with git-svn FANTASTIC tool.\n\nSo the problem is simply now: how to convince people to migrate from\nCVS to SVN. This will be really less difficult as CVS and SVN are\nquite similar.\n\nOn 4/17/07, Tomash Brechko wrote:\n> On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:\n> > So, in 15 seconds, how does one argue that GIT is vastly superior to\n> > other version control software, especially CVS.\n>\n> I think you are not talking about choosing SCM for a new project, as\n> it is even _hard to imagine_ that one would consider CVS nowadays :).\n> And if you are trying to convince people to do the migration from CVS\n> to GIT, then technical points alone won't probably help you. GIT, and\n> actually most modern SCMs, are superior to CVS not simply because they\n> have some CVS's features improved, and some nice features added.\n> Modern SCMs implement completely different workflow model. GIT's own\n> power in its rich toolset, but until people learn (or at least are\n> willing to learn) what the workflow is, and how it is supported by\n> these tools, there's little advantage in migration. You can't really\n> explain why 'git commit; git push' into some central repository is\n> better than 'cvs commit', and pushing after every commit is what\n> people will be doing at first ;). You should also realize that the\n> whole process is probably already built around CVS (CVS-specific\n> hooks, scripts that access CVS, say, for nightly testing, etc), that\n> would also have to be reimplemented.\n>\n> You may consider another route: create a GIT mirror of CVS repository,\n> and update it, say, daily, with git-cvsimport. Clone from this\n> mirror, and work with your own GIT tree, pushing back to CVS with\n> git-cvsexportcommit. Yes, you will be dealing with problems that\n> wouldn't be there in the first place if everyone would use GIT, and\n> you will basically use CVS workflow, but still, this way is quite\n> manageable. Then approach the most promising guy in the company, and\n> explain to him how you benefit from using GIT (gitk/qgit, git-bisect,\n> StGIT are among your friends here :)). As the saying goes, \"Better to\n> see once, then to hear about a hundred of times\". You are not\n> interested in instant migration, and then being blamed if anything\n> would go wrong. When you will grow sufficient number of GIT experts\n> in your company, then you will raise the migration question again.\n>\n>\n> Good luck!\n>\n> --\n> Tomash Brechko\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"39679","messageId":"vpqodlnapzx.fsf@bauges.imag.fr","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704170816390.5473@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-04-17T17:07:46Z","receivedAt":"2007-04-17T17:07:46Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 17 Apr 2007, Matthieu Moy wrote:\n>> \n>> * Perhaps your boss will be interested in the \"data integrity\" (i.e.\n>> git fsck) problem too.\n>\n> The data integrity thing is a lot more than just fsck.\n\nI have to revise my latin ;-). I meant _e. g._ git fsck, and the fact\nthat just given the full revision ID, you can make sure that both the\ndata and the history are uncorrupted is obviously a strong point for\ndata integrity, but not the only one (things like \"add, don't replace\"\npolicy is another).\n\n-- \nMatthieu\n"},{"id":"39681","messageId":"200704171818.28256.andyparkins@gmail.com","threadId":"7712","inReplyTo":"8b65902a0704170841q64fe0828mdefe78963394a616@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-17T17:18:26Z","receivedAt":"2007-04-17T17:18:26Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007, April 17, Guilhem Bonnefille wrote:\n> I'm new to Git, but completly crazy of it.\n>\n> In my point of view, in corporate team, lot of people does not\n> want/need the power offered by Git.\n> So, my conclusion is the better model in a corporate is a centralyzed\n> repo with some users using Git as \"frontend\". Other people will\n> simply use the native tools for accessing the repo.\n\nGit has you covered there - it works better than other version control \nsystems for that model too. I do it all the time; the only difference \nis that with git it's not the tool doesn't force the choice on you.\n\nIf you want a central repo, just make one - designate one repository as \ncentral, put it in the .git/config file for each of the others and away \nyou go. Pretend it's centralised if you want; you and your colleagues \nneed never know otherwise.\n\nWhat's even better is that everything will also work faster, take less \ndiskspace and be heavily backed up just by everyone doing their normal \nwork.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"39683","messageId":"20070417173007.GV2229@spearce.org","threadId":"7712","inReplyTo":"200704171818.28256.andyparkins@gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-04-17T17:30:07Z","receivedAt":"2007-04-17T17:30:07Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins wrote:\n> On Tuesday 2007, April 17, Guilhem Bonnefille wrote:\n> > So, my conclusion is the better model in a corporate is a centralyzed\n> > repo with some users using Git as \"frontend\". Other people will\n> > simply use the native tools for accessing the repo.\n> \n> Git has you covered there - it works better than other version control \n> systems for that model too. I do it all the time; the only difference \n> is that with git it's not the tool doesn't force the choice on you.\n\nActually my day-job corporate repo is probably more secured in\nGit than in PVCS Version Manager, even though every developer\nhas the entire history on their laptop.\n\nBasically with PVCS users cannot save their work-in-progress very\nwell, so they copy files onto random network shares to make backups.\nOur checked out tree is only about 120 MiB or so, but we have (and\nI'm not kidding) over 3 GiB worth of various copies of the source\non an open network drive that anyone in the company can access, even\nif they aren't authorized to view the source code of the product...\n\nNow that developers have switched to Git, they have stopped making\nthose copies onto the network drive. Why? Simple, the network drive\ncopy takes longer (and more effort) than `git commit; git push`!\nUsers are all pushing to private branch spaces on the server, so\ntheir work isn't merged until they really are ready for it, and\nthat server is backed up to secure tapes nightly, so all-in-all\nits a much better situation.\n\n-- \nShawn.\n"},{"id":"39690","messageId":"462521C7.2050103@softax.com.pl","threadId":"7712","inReplyTo":"20070417173007.GV2229@spearce.org","subject":"Re: GIT vs Other: Need argument","fromName":"Marcin Kasperski","fromEmail":"marcin.kasperski@softax.com.pl","sentAt":"2007-04-17T19:36:39Z","receivedAt":"2007-04-17T19:36:39Z","isPatch":false,"sender":{"key":"marcin.kasperski@softax.com.pl","avatar":"https://gravatar.com/avatar/876c331bb177f09eaebc1447c2c890dc36d7c46b3ac09754003b8da1633eb20b?d=mp&s=160"},"body":"Let me add some salt. At the moment, there are at least two immediate \nshow-stoppers\nfor using git in many organizations:\n\na) Windows are unsupported\nb) Learning curve is too steep. Unclear relationship git-vs-cogito makes \nit even worse.\n\nThird is also very likely:\n\nc) Lack of reasonable subproject support (plus detailed permission model).\n\n From tools similar to git, Mercurial performs significantly better (at \nleast it works\non Win and is easy to learn, although some GUI would be needed in most cases\nbefore it could be truly implemented).\n\nPS I am in related pos, long years ago I introduced CVS to my org - \nreplacing\nCMS on VMS, RCS on Unix and manual copies on Win, now I am sensing \npossibilities, but...\n\nPS2 I am not sure whether git aims to handle corporate cases, or even \nwhether it should,\nthose remarks are addressed rather to those who consider using it in \nsuch situation, than\nto those who wrote it.\n"},{"id":"39736","messageId":"46258BEC.7050603@vilain.net","threadId":"7712","inReplyTo":"8b65902a0704170841q64fe0828mdefe78963394a616@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-04-18T03:09:32Z","receivedAt":"2007-04-18T03:09:32Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Guilhem Bonnefille wrote:\n> I'm new to Git, but completly crazy of it.\n>\n> In my point of view, in corporate team, lot of people does not\n> want/need the power offered by Git.\n> So, my conclusion is the better model in a corporate is a centralyzed\n> repo with some users using Git as \"frontend\". Other people will simply\n> use the native tools for accessing the repo.\n>\n> I didn't try Git with CVS repo but seems less usable in day to day\n> work than a SVN repo with git-svn FANTASTIC tool.\n>\n> So the problem is simply now: how to convince people to migrate from\n> CVS to SVN. This will be really less difficult as CVS and SVN are\n> quite similar.\n> \n\nOnce git-svnserver is available, it should be possible to work the other\nway, too - use git as the repository format and support Subversion users\nthrough a subversion interface flavour. Then you don't lose the merge\ntracking and fast checkout performance for those who can use the native\nprotocol.\n\nSam.\n"},{"id":"39757","messageId":"Pine.LNX.4.64.0704181130150.12094@racer.site","threadId":"7712","inReplyTo":"462521C7.2050103@softax.com.pl","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-18T10:05:27Z","receivedAt":"2007-04-18T10:05:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Apr 2007, Marcin Kasperski wrote:\n\n> a) Windows are unsupported\n\nWrong.\n\n> b) Learning curve is too steep. Unclear relationship git-vs-cogito makes it\n> even worse.\n\nNot so wrong. But then, it is clear that git is git is git. If you find it \ntoo complicated, soon enough somebody says \"use cogito instead\" and you'll \nfind out about that.\n\n> c) Lack of reasonable subproject support (plus detailed permission \n> model).\n\nIt is just being introduced into Git.\n\nAnd we're back to Alex' point: if you want to make a feature a first class \ncitizen, you have to invest a little energy in it. But experience shows \nthat it _is_ possible to get something completely new into Git quite fast.\n\nBTW the most striking argument pro Git I can think of is showing people \nhow fast you can find out things. Like who wrote it, or more importantly \n_where_ the code is for a certain feature. Searching through `git log -p` \nis really fast, and it becomes even faster when you use \"-Sblub\".\n\nAnd I really blew my audience away when I imported some CVS tracked \nproject into Git, and showed all the features on that repository, \n_without_ much work.\n\nI mean, you can do with CVS, SVN, HG, etc. almost the same as with Git. \nBut with Git, I find it faster and easier. BTW much of that does come from \nthe scriptable nature of Git. It _is_ much easier to write a short and \nsimple script than to work on a plugin.\n\nCiao,\nDscho\n"},{"id":"39771","messageId":"8b65902a0704180540l721b9b1dj6f6e068f0d7e5119@mail.gmail.com","threadId":"7712","inReplyTo":"200704171818.28256.andyparkins@gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2007-04-18T12:40:18Z","receivedAt":"2007-04-18T12:40:18Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"On 4/17/07, Andy Parkins wrote:\n> On Tuesday 2007, April 17, Guilhem Bonnefille wrote:\n> > I'm new to Git, but completly crazy of it.\n> >\n> > In my point of view, in corporate team, lot of people does not\n> > want/need the power offered by Git.\n> > So, my conclusion is the better model in a corporate is a centralyzed\n> > repo with some users using Git as \"frontend\". Other people will\n> > simply use the native tools for accessing the repo.\n>\n> Git has you covered there - it works better than other version control\n> systems for that model too. I do it all the time; the only difference\n> is that with git it's not the tool doesn't force the choice on you.\n>\n> If you want a central repo, just make one - designate one repository as\n> central, put it in the .git/config file for each of the others and away\n> you go. Pretend it's centralised if you want; you and your colleagues\n> need never know otherwise.\n\nIn fact, the most important problem (in my case) is that there are\npeople that really don't want/need Git features. These people consider\nthat CVS/SVN are constraints and not usefull tools. They are not\ninterested in what a VCS can offer. I have success with CVS/SVN\nbecause we now use Eclipse which offers an easy to use GUI for CVS/SVN\nactions.\nAn other point is that CVS/SVN actions for our developers are\n\"trivial\": update or commit, nothing more (even tags are made by\n\"power\" users, so working with branches...). With Git, you have to\nALWAYS remember that you have a repo locally which is different than\nthe central repo. I think this point is quite confusing for people not\ninterested in the features offered by having a \"private\" repo.\n\nThis is why I think my corporate friends will brake if I try to\npropose Git for everybody.\n\nIn my mind, git-svn or even git-svnserve, are THE tools to introduce\nGit in teams not convinced by the power of DVCS. Or perhaps someone\nwill create a porcelain that offers the same simple interface of\nCVS/SVN and will integrate it in all the fantastic IDE ;-)\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"39772","messageId":"200704181426.29969.andyparkins@gmail.com","threadId":"7712","inReplyTo":"8b65902a0704180540l721b9b1dj6f6e068f0d7e5119@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-18T13:26:17Z","receivedAt":"2007-04-18T13:26:17Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 April 18 13:40, Guilhem Bonnefille wrote:\n\n> An other point is that CVS/SVN actions for our developers are\n> \"trivial\": update or commit, nothing more (even tags are made by\n\n> In my mind, git-svn or even git-svnserve, are THE tools to introduce\n> Git in teams not convinced by the power of DVCS. Or perhaps someone\n> will create a porcelain that offers the same simple interface of\n> CVS/SVN and will integrate it in all the fantastic IDE ;-)\n\nIt's already there. The git porcelain can do almost anything. If you were so \ninclined you could write a fake svn command that translated all those calls \nto git.\n\nsvn add = git add\nsvn update = git pull\nsvn commit = git commit -a && git push\n\nI'm fairly convinced that the reason everyone thinks git is hard is because \nthey're introduced to too much of it too quickly.\n\ngit /is/ easy. It's more powerful, so there are more knobs, but if you don't \nwant to use those knobs - don't.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"39783","messageId":"alpine.LFD.0.98.0704180851060.2828@woody.linux-foundation.org","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704181130150.12094@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-18T16:07:55Z","receivedAt":"2007-04-18T16:07:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Apr 2007, Johannes Schindelin wrote:\n> \n> On Tue, 17 Apr 2007, Marcin Kasperski wrote:\n> > \n> > a) Windows are unsupported\n> \n> Wrong.\n\nIt's a bit more work to set up though, and it has a lot less mindshare, \nand testing, obviously.\n\nSo yes, windows is a step-child. I'd love for it to not be one, and we'll \nget there, but it's clearly not as supported as the unix side. We still \nuse a fair number of shell scripts (which in turn use unix commands and \npipelines).\n\nWe'll get away from it. I think GSoC will help here.\n\n> > b) Learning curve is too steep. Unclear relationship git-vs-cogito makes it\n> > even worse.\n> \n> Not so wrong. But then, it is clear that git is git is git. If you find it \n> too complicated, soon enough somebody says \"use cogito instead\" and you'll \n> find out about that.\n\nActually, at this stage, I really think cogito just *complicates* git \nusage. It hasn't been well-supported lately, and asking for help with \ncogito means that a lot of people can't help you. And you still end up \nusing git commands for anything fancier.\n\nSo I don't think it's even true that new people should be pointed at cg \nany more.\n\nWhat _is_ true is that git is simply different from CVS. I don't think \nit's necessarily harder to understand or use (in fact, I would argue that \ngit is a lot _easier_ to understand), but it is *different*, and it has a \nton more capabilities.\n\nBut compare setting up a git repository with setting up a CVS repository.\nWith git, it's literally \"git init\", and you're done. No need to worry \nabout CVSROOT issues etc. Everything is self-contained. CVS is *hard* to \nget into, by comparison.\n\nBut being different means that *if* you already know CVS, you actually \nhave a lot of unlearning of idiotic and bad habits, _and_ you need to \nlearn that things that were so hard and scary under CVS that you either \nnever learnt them, or quickly learnt to avoid (\"branches\" and \"merging\") \nare just so _easy_ under git, that they are discussed in the very first \nchapters of \"getting started\".\n\nI can pretty much guarantee that 95% of all CVS users have never done a \nbranch or a merge, even if they have used it for *years*. And yet, in git, \nwe kind of take both of those for granted, and make them visible pretty \nmuch from day one. \n\nGit is just *easier*. But it is also different, and people are used to \nthings being so hard that you'd never use them.\n\nIn a CVS world, you never even *need* to learn about branches and merging, \nbecause no normal user is ever actually expected to use either. In \ncontrast, in the git world, pretty much every project uses multiple \nbranches, and you are introduced to them at a minimum as the \"origin\" \nbranches even for projects that just have one. So you're getting all these \nconcepts that were so hard in CVS that you never ever even learnt to do \nthem!\n\nSo people coming from CVS/SVN have a double shock: they are supposed to \nlearn things that they \"know\" are hard (because CVS/SVN made them so damn \nhard - don't tell me that SVN branching is easy, because it is *not* easy. \nIt may be cheaper to create a branch, but it has _all_ the same idiocies \nthat CVS has once it's created). And on top of that, they have to re-learn \nsomething new.\n\nSo I really don't think cogito is the answer any more. The answer simply \nis: you have to learn that branches are *simple*. That's a big hurdle for \nsome people. It's not the learning part that is hard, it's the \n*unlearning*. CVS/SVN has taught people that some things are complicated, \nand git uses those \"complicated\" things every day.\n\nPeople who come from a CVS background would be *shocked* to learn that I \ndo multiple merges a day. In fact, in the two years we've used git, we've \nhad 3300 merges - and that's just counting the *nontrivial* ones that \ndidn't just fast-forward. That's roughly an *average* of 4.5 merges a day. \nEVERY DAY. For two years.\n\nIn the CVS/SVN kind of mindset, a merge is something you do once a month, \nand you gird your loins for it. And it's usually just an expert, and only \nused for complex projects. A normal user would _never_ do a merge!\n\n\t\t\tLinus\n"},{"id":"39790","messageId":"alpine.LFD.0.98.0704181225550.4504@xanadu.home","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704180851060.2828@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-18T16:31:33Z","receivedAt":"2007-04-18T16:31:33Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 18 Apr 2007, Linus Torvalds wrote:\n\n> Actually, at this stage, I really think cogito just *complicates* git \n> usage. It hasn't been well-supported lately, and asking for help with \n> cogito means that a lot of people can't help you. And you still end up \n> using git commands for anything fancier.\n\nMaybe someone should nuke the prominent mention of Cogito at the top of \nhttp://www.kernel.org/git/ then, and replace it with the appropriate Git \nequivalent.\n\n\nNicolas\n"},{"id":"39792","messageId":"17958.19499.813637.324723@lisa.zopyra.com","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704180851060.2828@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-04-18T16:49:47Z","receivedAt":"2007-04-18T16:49:47Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, April 18, 2007 at 09:07:55 (-0700) Linus Torvalds writes:\n>...\n>Actually, at this stage, I really think cogito just *complicates* git \n>usage. ...\n\nAs a relative newbie to git, I agree. At our company, we did not even\nseriously consider using cogito. Just easier to jump right in to the\nfrosty waters.\n\n>What _is_ true is that git is simply different from CVS. I don't think \n>it's necessarily harder to understand or use (in fact, I would argue that \n>git is a lot _easier_ to understand), but it is *different*, and it has a \n>ton more capabilities.\n\nWell, differences can lead to difficulties.\n\nHere are a few of the differential difficulties we have faced:\n\n1) There seems to be an innate desire on our part to just \"update this\nbranch from that one on that repository\". We have been caught several\ntimes pulling onto the wrong branch, pushing onto the wrong one,\nbecause we assumed the behavior of push/pull was \"update this branch,\nthe one I am on right now, and ONLY this branch\", but what we got was\na cross-branch merge. Coming from a CVS background, and there not\nhaving \"undo\" very easy, this caused severe stress. Easy enough to\nundo, once we understood, but does not obviate the stress.\n\n2) Addressing of branches. When to use bare 'git pull/push', when to\nuse 'git pull/push branch' when to use 'git pull/push branch:branch',\nhave been continually confusing to us.\n\n3) Funkiness of non-bare repos ---- we really got stung trying to push\ninto one. Seemed like it took us days to figure out what was going\non.\n\n4) Near disaster using git with ssh to push to our company repo. In\nour company, we have a very loosy-goosy IT group. We started using\ngit with ssh and had serious permissions problems. If we had used the\ngit protocol from the start, that would have avoided this mess, but\nsupport for that came too late.\n\nGit has gotten much better than when we started with it just at the\nbeginning of this year. Remote support, branch tracking, lots of\nstuff has gotten much, much better.\n\nI could go on and on about the good things, but it is important to\ncaution --- not frighten --- newbies with tales from others who have\nbeen stung.\n\n\nBill\n"},{"id":"39793","messageId":"462650A7.5030404@midwinter.com","threadId":"7712","inReplyTo":"200704181426.29969.andyparkins@gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-04-18T17:08:55Z","receivedAt":"2007-04-18T17:08:55Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Andy Parkins wrote:\n> svn update = git pull\n> \n\nThat's not quite equivalent, and it's one of the biggest annoyances svn \nusers seem to have when starting up with git in my observation (having \ngone through it myself and watched a few other people at my company do \nso.) svn update will merge upstream changes into your locally edited but \nnot yet committed files. git pull will just complain if you have \nuncommitted local edits to files that changed upstream.\n\nTo avoid that problem, my workflow often looks like\n\ngit commit -a -m \"dummy revision\"\ngit fetch\ngit rebase origin/master\ngit reset --soft HEAD^\n\nwhich IMO is something the tool should be doing for me. Cogito's \ncg-update would do this for me, but Cogito hasn't kept up with recent \ngit changes so aside from cg-admin-rewritehist I never use it. Please \ntell me if the above is doable in fewer commands, by the way.\n\n-Steve\n"},{"id":"39796","messageId":"vpqejmhy3x2.fsf@bauges.imag.fr","threadId":"7712","inReplyTo":"17958.19499.813637.324723@lisa.zopyra.com","subject":"Re: GIT vs Other: Need argument","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-04-18T17:43:05Z","receivedAt":"2007-04-18T17:43:05Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Bill Lear writes:\n\n> On Wednesday, April 18, 2007 at 09:07:55 (-0700) Linus Torvalds writes:\n>>...\n>>Actually, at this stage, I really think cogito just *complicates* git \n>>usage. ...\n>\n> As a relative newbie to git, I agree. At our company, we did not even\n> seriously consider using cogito. Just easier to jump right in to the\n> frosty waters.\n\nSame for me.\n\nAs a beginner, I went to http://git.or.cz/, clicked \"crash courses\",\nand since I didn't find \"git from scratch\", I clicked \"git for CVS\nusers\" (I know CVS, but haven't used it for a long time, I'm mostly a\nbzr user converted from GNU Arch).\n\nThere, the commands are not \"git something\", but \"cg something\". Well,\nnot always, at least. Indeed, there's still a \"git blame\", a reference\nto \"git-rev-parse manpage\".\n\nThen, I can't even find it in the tutorial, but somewhere, it should\nbe mentionned to say who I am in ~/.gitconfig.\n\nSo, Cogito can not be seen as \"a revision control, using git as a\nback-end\". It's definitely an additional layer, not hiding all of git.\n\nAnd then, comming to the mailing list, and looking at other websites,\nI can see git commands here and there. I started to manage branches\nusing cogito, tried git commands related to branches, and realized\nthat they used a totally different interface.\n\nSo, cogito has probably been of a real use at the beginning, where git\nwas said to be almost unuseable without anything else (I didn't try\ngit at that time), but I don't think it's the case anymore.\n\n-- \nMatthieu\n"},{"id":"39799","messageId":"alpine.LFD.0.98.0704181346440.4504@xanadu.home","threadId":"7712","inReplyTo":"vpqejmhy3x2.fsf@bauges.imag.fr","subject":"Re: GIT vs Other: Need argument","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-18T17:50:03Z","receivedAt":"2007-04-18T17:50:03Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 18 Apr 2007, Matthieu Moy wrote:\n\n> Then, I can't even find it in the tutorial, but somewhere, it should\n> be mentionned to say who I am in ~/.gitconfig.\n\nOne of the very first thing you can find in Documentation/tutorial.txt \nis:\n\n\tIt is a good idea to introduce yourself to git with your name and\n\tpublic email address before doing any operation. The easiest\n\tway to do so is:\n\n\t------------------------------------------------\n\t$ git config --global user.name \"Your Name Comes Here\"\n\t$ git config --global user.email you@yourdomain.example.com\n\t------------------------------------------------\n\n\nNicolas\n"},{"id":"39815","messageId":"8b65902a0704181308i41c878ebi88c03a929769ba39@mail.gmail.com","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704180851060.2828@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2007-04-18T20:08:07Z","receivedAt":"2007-04-18T20:08:07Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"On 4/18/07, Linus Torvalds wrote:\n> What _is_ true is that git is simply different from CVS. I don't think\n> it's necessarily harder to understand or use (in fact, I would argue that\n> git is a lot _easier_ to understand), but it is *different*, and it has a\n> ton more capabilities.\n\nYes, but I think that, as Git has ton more capabilities, user has to\nunderstand more things than with CVS.\n\nI don't know lot of corporate teams, but here, our developers are\nREALLY not motivated by VCS. It's only a way to share work. And I'm\nnot talking about concurrent modification: lot of people in my office\nreally think that the better model is the locked one.\nThese people won't be the guy who set up the repo. These people only\nexpect a system to:\n- retrieve and merge the job done by other people\n- archive their job for other people.\nNothing more. No interest for topic branches (they are simple minded\n;-)), no interest for data integrity (it's \"not their job\"),\ninterested in problem with connected system (\"hey, CVS server is down,\nwould you like a coffee while waiting IT detects that ?\")...\n\nSo for such people, I really think raw Git is much more complicated\nthan CVS/SVN.\n\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"39818","messageId":"alpine.LFD.0.98.0704181312060.2828@woody.linux-foundation.org","threadId":"7712","inReplyTo":"8b65902a0704181308i41c878ebi88c03a929769ba39@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-18T20:19:07Z","receivedAt":"2007-04-18T20:19:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Apr 2007, Guilhem Bonnefille wrote:\n> \n> Yes, but I think that, as Git has ton more capabilities, user has to\n> understand more things than with CVS.\n\nI do agree.\n\nThe whole \"branch\" thing is something you can ignore in CVS, but it's \nsimply very hard to ignore in git, because even *if* you just follow \nanother repository, git kind of forces you to be aware of the difference \nbetween \"local branch\" and \"remote tracking branch\".\n\nI think that's fairly fundamental to being distributed, though. \n\n> I don't know lot of corporate teams, but here, our developers are\n> REALLY not motivated by VCS. It's only a way to share work. And I'm\n> not talking about concurrent modification: lot of people in my office\n> really think that the better model is the locked one.\n\nSure. At one level they may even be right. It's just that the locked model \nobviously doesn't work past a certain scenario. But explaining that to \nsomebody who doesn't even think outside his own scenario is pointless.\n\nSo no question: git has a level of abstraction and perhaps requires a \nhigher-level view than RCS and CVS do. And I can well imagine that it is \nseen as more \"difficult\" because of that.\n\nI just haev to say that I worked with CVS at a commercial company for \nseven years, and I *did* do things like branches and merges etc, and \ndespite workign with it at that level (not that I was the expert by any \nmeans: we had a person who came in with the main job literally being the \ntools around CVS to make branching more convenient etc), I seriously feel \nthat CVS was a *lot* harder to get into than it is to get into git.\n\n> So for such people, I really think raw Git is much more complicated\n> than CVS/SVN.\n\nI do wonder what we could do about that. I think you can use git in the \n\"SVN tracker only\" model, and I really thought it was pretty damn simple, \nbut ...\n\n\t\tLinus\n"},{"id":"39822","messageId":"20070418204948.GB8524@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"7712","inReplyTo":"20070417104520.GB4946@moonlight.home","subject":"Re: GIT vs Other: Need argument","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-04-18T20:49:48Z","receivedAt":"2007-04-18T20:49:48Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Apr 17, 2007 at 02:45:20PM +0400, Tomash Brechko wrote:\n> I think you are not talking about choosing SCM for a new project, as\n> it is even _hard to imagine_ that one would consider CVS nowadays :).\n\nDon't think that. Some people used to CVS still say \"it does the job,\nand I know the tool\", and look suspciously on those youngsters trying\npush anything they did not even heard of (I'd push for git today, but\n18 months ago all I had to push for was svn). And only after months\nof \"here svn/git would have done better\", and regularly showing off\ngitk (git-cvsimport is not a panacea, but it helps), can they be ready\nto hear.\n\nBut by then more people have been made to meet CVS because of a new\nproject using it, and it will take more time that we would like to see\nit retire from the scene...\n"},{"id":"39824","messageId":"20070418205420.GC8524@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"7712","inReplyTo":"200704181426.29969.andyparkins@gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-04-18T20:54:21Z","receivedAt":"2007-04-18T20:54:21Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Wed, Apr 18, 2007 at 02:26:17PM +0100, Andy Parkins wrote:\n> On Wednesday 2007 April 18 13:40, Guilhem Bonnefille wrote:\n> \n> > An other point is that CVS/SVN actions for our developers are\n> > \"trivial\": update or commit, nothing more (even tags are made by\n> \n> > In my mind, git-svn or even git-svnserve, are THE tools to introduce\n> > Git in teams not convinced by the power of DVCS. Or perhaps someone\n> > will create a porcelain that offers the same simple interface of\n> > CVS/SVN and will integrate it in all the fantastic IDE ;-)\n> \n> It's already there. The git porcelain can do almost anything. If you were so \n> inclined you could write a fake svn command that translated all those calls \n> to git.\n> \n> svn add = git add\n> svn update = git pull\n> svn commit = git commit -a && git push\n\nIt's even possible to write those as git aliases, so you can have \"git\nupdate\" and \"git ci\" behave as cvs/svn users would expect.\n"},{"id":"39825","messageId":"20070418205706.GH24963@thunk.org","threadId":"7712","inReplyTo":"vpqejmhy3x2.fsf@bauges.imag.fr","subject":"Re: GIT vs Other: Need argument","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-04-18T20:57:06Z","receivedAt":"2007-04-18T20:57:06Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Apr 18, 2007 at 07:43:05PM +0200, Matthieu Moy wrote:\n> As a beginner, I went to http://git.or.cz/, clicked \"crash courses\",\n> and since I didn't find \"git from scratch\", I clicked \"git for CVS\n> users\" (I know CVS, but haven't used it for a long time, I'm mostly a\n> bzr user converted from GNU Arch).\n> \n> There, the commands are not \"git something\", but \"cg something\". Well,\n> not always, at least. Indeed, there's still a \"git blame\", a reference\n> to \"git-rev-parse manpage\".\n> \n> Then, I can't even find it in the tutorial, but somewhere, it should\n> be mentionned to say who I am in ~/.gitconfig.\n\nYeah, one of the biggest source of confusion is that a lot of the\nresources available on http://git.or.cz refers very heavily to cg, but\nmost of the discussion on the git mailing list doesn't involve using\ncg, and as some have argued, it's not clear cg is very useful; at this\npoint, given the advances in git's usability in the 1.5 series.\n\nSo what I normally tell new users is to *not* look at\nhttp://git.or.cz, since more than once people have taken off points on\ngit's usability because of the fact that some of the tutorials (in\nparticular the \"git for CVS users\") are really talkinga about cogito,\nnot git, and this gets highly confusing for many new users.\n\nInstead, I tell people they should look at this:\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/\n\n... and reference the tutorials off of this site. It seems to me that\nthe documentation and tutorials on this site tends to get update much\nmore frequently and religiously than the resources on http://git.or.cz\n--- although there is still some good stuff there that isn't\nelsewhere. But unfortunately, for a new user, the fact that they have\nto filter out information that might be out of date, or\ncogito-specific, from what is relevant, makes it such that I can't\nreally recommend that site to new users.\n\n> So, cogito has probably been of a real use at the beginning, where git\n> was said to be almost unuseable without anything else (I didn't try\n> git at that time), but I don't think it's the case anymore.\n\nYep; and unfortunately, at this point, using cg probably is more\nconfusing compared to just simply using raw git all by itself.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"39829","messageId":"f2b55d220704181421o3376d69fh8d0217de3c8242bf@mail.gmail.com","threadId":"7712","inReplyTo":"8b65902a0704181308i41c878ebi88c03a929769ba39@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2007-04-18T21:21:37Z","receivedAt":"2007-04-18T21:21:37Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"Suppose I were dealing with career software developers, backed by real\nmoney, who also happened to be intelligent, thoughtful people, and I\nwanted to make the case for git vs. CVS/SVN. I'd start by handing\nthem copies of the O'Reilly Perforce book and suggesting that they\nread it cover to cover. Focus on the chapters on how well organized\ndevelopment and release branches, and good tracking of feature/fix\npropagation among them, can help you cope with the vagaries of\nreal-life software development.\n\nThen I'd explain the relative merits of Perforce and git -- on one\nhand, availability and quality of documentation, training, tech\nsupport, and Windows versions; on the other hand, a genuinely\ndistributed design, which means that you don't need psychic powers to\narrive at a sane branch structure. Specifically, git's design makes\nprivate branches ultra-cheap for the developers that use them and\nzero-impact on the release infrastructure, and the integrity of\n_content_ and _history_ doesn't rely on any resemblance between my\nbranch layout and yours. Speed, scalability, zero license cost, and\nthe hypothetical ability to hack on it yourself are nice too, but\nthey're basically fringe issues unless you're so big that you can't\njust throw money at the problem -- in which case they're still fringe\nissues because you're the enterprise-customer tail that wags the\nvendor dog. (If you're big _and_ cash-poor, or if you're stuck on a\nVC system so badly designed that no amount of money thrown at the\nproblem will help, you have a different problem.)\n\nIf you do this right, it should be clear that CVS is in the dust on\nall fronts and SVN doesn't (AFAICT) have any advantage over Perforce\nthat git doesn't have more of. You might also mention that git was\ndesigned by Linus to systematically not suck, and has been\nsuccessfully handed over to a strong maintenance/enhancement team that\nworks in public view. And Linus is still here policing to keep\nsuckage from creeping in. ;-) The hypothetical smart developers will\nthen agree to go with either Perforce or git, depending on which the\npeople who have to do the hard work -- release managers and the IT\nMorlocks -- are most comfortable with.\n\nIf you take this route, be prepared to wind up with Perforce. It's\ngot its weaknesses, and I prefer git myself, but you could certainly\ndo a lot worse. I'm not as anti-SVN as Linus, but there aren't many\nworkflows for which I would recommend it over Perforce. Personally, I\nwouldn't voluntarily introduce any other version control system into\nthe discussion, because the others that I've used in the course of one\nday job or another suck massively by comparison, and the ones I\nhaven't used (or have only toyed with) don't appear to have any\ncompelling advantage over git. (Having _marginally_ better\ndocumentation isn't much to brag about).\n\nUntil someone writes a good book on git and sets up shop as a\ncommercial support organization, presenting Perforce vs. git as a\nclassic buy/build decision is probably the best you can do. (You\ndon't have to \"build\" git, of course, but you'd have to build your own\nin-house training and tech support capability.) I say this as someone\nwho routinely sits in the \"release manager\" chair, uses git by choice,\nand is currently suffering the pain and agony of migrating a perfectly\ngood git-based integration process to Perforce, simply because it\nappears to be the right thing for this developer organization.\n(Doubtless this colors my opinion du jour.)\n\nCheers,\n- Michael\n"},{"id":"39832","messageId":"Pine.LNX.4.64.0704181657190.27922@iabervon.org","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704181312060.2828@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-18T21:45:37Z","receivedAt":"2007-04-18T21:45:37Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 18 Apr 2007, Linus Torvalds wrote:\n\n> On Wed, 18 Apr 2007, Guilhem Bonnefille wrote:\n> > \n> > Yes, but I think that, as Git has ton more capabilities, user has to\n> > understand more things than with CVS.\n> \n> I do agree.\n> \n> The whole \"branch\" thing is something you can ignore in CVS, but it's \n> simply very hard to ignore in git, because even *if* you just follow \n> another repository, git kind of forces you to be aware of the difference \n> between \"local branch\" and \"remote tracking branch\".\n> \n> I think that's fairly fundamental to being distributed, though. \n\nI actually disagree here. CVS users are obviously familiar with \"how far \nhave I updated from the server\". With CVS the \"local branch\" and \"remote \ntracking branch\" are qualitatively different, and with git they're \nqualitatively the same, but the user doesn't have to care. Particularly \nwith the new refs layout, it's pretty easy to ignore, as long as the \nupstream repository isn't using branches for anything this particular user \ncares about.\n\nYou can just tell people, \"Before you merge upstream changes, you have to \ncommit, so that if the merge gets screwed up you don't lose your work.\" \nAnd they say, \"Oh. That's useful.\" And they don't need to know the \ntechnical reasons this is both possible and necessary.\n\n(Of course, branches are really helpful once you have a need for them, but \nthere's no reason to learn about them before that point.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"39850","messageId":"f06d4m$3rs$1@sea.gmane.org","threadId":"7712","inReplyTo":"462650A7.5030404@midwinter.com","subject":"Re: GIT vs Other: Need argument","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-04-19T00:33:04Z","receivedAt":"2007-04-19T00:33:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Steven Grimm wrote:\n\n> Andy Parkins wrote:\n>> svn update = git pull\n>> \n> \n> That's not quite equivalent, and it's one of the biggest annoyances svn \n> users seem to have when starting up with git in my observation (having \n> gone through it myself and watched a few other people at my company do \n> so.) svn update will merge upstream changes into your locally edited but \n> not yet committed files. git pull will just complain if you have \n> uncommitted local edits to files that changed upstream.\n\nIn my opinion the update-then-commit workflow CVS and SVN forces on users\nis one of the more annoying features, forcing the user to resolve conflicts\nif he/she wants to be up-to-date.\n\nThe update-then-commit assumes that you merge on update local modifications\nwith current server version, assuming that ancestor is current local\ncommitted version. This makes off-line committing impossible, and makes\nrare updates (server version advanced by more than one commit) unnecessary\nhard.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"39851","messageId":"4626C4B9.1040707@midwinter.com","threadId":"7712","inReplyTo":"f06d4m$3rs$1@sea.gmane.org","subject":"Re: GIT vs Other: Need argument","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-04-19T01:24:09Z","receivedAt":"2007-04-19T01:24:09Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> In my opinion the update-then-commit workflow CVS and SVN forces on users\n> is one of the more annoying features, forcing the user to resolve conflicts\n> if he/she wants to be up-to-date.\n> \n\nI'm not eager to jump to svn's defense -- there's a reason I'm using git \nand trying to get my coworkers to do the same -- but how does git allow \nyou to stay up to date without resolving conflicts? Granted that git is \nsmarter about resolving certain kinds of conflicts automatically, but \nfundamentally if the latest revision you've pulled down (from any kind \nof version control system) makes a change that conflicts with a local \nchange (whether or not you've committed it locally first) you're going \nto have to resolve it by hand, yes?\n\nAlso, last I checked, git wouldn't let me push into a branch that had \nrevisions I hadn't yet pulled down. Isn't that just another way of \nenforcing an update-then-commit workflow? If anything, svn wins in that \narea -- it allows me to commit without updating as long as my change \ndoesn't touch any files that have changed upstream.\n\nOne can argue about whether allowing partial commits like that is a good \nidea, but it's just not true that svn forces you to always update before \nyou commit, and if you're pushing into a branch that other people are \nalso updating, the ability to commit files that didn't change upstream \nmeans it is actually *less* insistent on update-then-commit than git is \n(if you take \"commit\" to mean \"commit-and-push\" on the git side as was \nsuggested in the message I replied to originally.)\n\nUnless, of course, I'm misinterpreting you here.\n\n> The update-then-commit assumes that you merge on update local modifications\n> with current server version, assuming that ancestor is current local\n> committed version. This makes off-line committing impossible, and makes\n> rare updates (server version advanced by more than one commit) unnecessary\n> hard.\n\nThat last point is completely counter to my experience. At my company \n(where the svn repository is still the official code base) the \nrepository is constantly changing. I'll sometimes let hundreds or even \nthousands of revisions go by between updates of my svn client. When I'm \nat a good point to do integration testing and I'm using an svn client \ninstead of a git-svn one, I type \"svn up\", do roughly the same manual \nconflict resolution I'd do after a \"git pull\" that brought down a \nsimilar number of new revisions -- often none at all if I'm the only one \nworking on a particular corner of the code base -- and I'm good to go. \nWhat's unnecessarily hard about that? How would it be any better in git?\n\nLocal commit capability is absolutely a huge win in git, though, and is \none of the main features I use to sell people on it internally. No \nargument there. I just don't like being *forced* to do a local commit \nwhen I have no reason to do so other than to satisfy the version control \ntool. I end up either cluttering my history with dummy revisions or \nhaving to type extra commands to get rid of them.\n\nAnd in particular -- this being the original topic of the thread -- when \nan svn user sees me doing that, they do not immediately think of the \nfact that merging between immutable revisions may have some benefits. \nThey see me typing four commands (commit, fetch, rebase, reset) to do \nthe same thing they can do in one command with svn, and conclude that \ngit is harder to use. That some of them choose to use it anyway is a \ntestament to how great git is in other areas.\n\n-Steve\n"},{"id":"39852","messageId":"200704190408.59595.jnareb@gmail.com","threadId":"7712","inReplyTo":"4626C4B9.1040707@midwinter.com","subject":"Re: GIT vs Other: Need argument","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-04-19T02:08:58Z","receivedAt":"2007-04-19T02:08:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Steven Grimm wrote:\n> Jakub Narebski wrote:\n\n>> In my opinion the update-then-commit workflow CVS and SVN forces on users\n>> is one of the more annoying features, forcing the user to resolve conflicts\n>> if he/she wants to be up-to-date.\n>> \n> \n> I'm not eager to jump to svn's defense -- there's a reason I'm using git \n> and trying to get my coworkers to do the same -- but how does git allow \n> you to stay up to date without resolving conflicts? Granted that git is \n> smarter about resolving certain kinds of conflicts automatically, but \n> fundamentally if the latest revision you've pulled down (from any kind \n> of version control system) makes a change that conflicts with a local \n> change (whether or not you've committed it locally first) you're going \n> to have to resolve it by hand, yes?\n\nThe answer is that in git you can separate _having_ most current version\nfrom the server (git fetch) and _merging_ your work with current version\nfrom the server (git pull).\n\n> Also, last I checked, git wouldn't let me push into a branch that had \n> revisions I hadn't yet pulled down. Isn't that just another way of \n> enforcing an update-then-commit workflow? If anything, svn wins in that \n> area -- it allows me to commit without updating as long as my change \n> doesn't touch any files that have changed upstream.\n> \n> One can argue about whether allowing partial commits like that is a good \n> idea, but it's just not true that svn forces you to always update before \n> you commit, and if you're pushing into a branch that other people are \n> also updating, the ability to commit files that didn't change upstream \n> means it is actually *less* insistent on update-then-commit than git is \n> (if you take \"commit\" to mean \"commit-and-push\" on the git side as was \n> suggested in the message I replied to originally.)\n> \n> Unless, of course, I'm misinterpreting you here.\n\nI just think the commit _then_ merge (or commit-then-update) workflow is\nmuch, much better than update-then-commit one.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"39853","messageId":"7vy7kpaz9s.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"4626C4B9.1040707@midwinter.com","subject":"Re: GIT vs Other: Need argument","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-19T02:11:59Z","receivedAt":"2007-04-19T02:11:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> And in particular -- this being the original topic of the thread --\n> when an svn user sees me doing that, they do not immediately think of\n> the fact that merging between immutable revisions may have some\n> benefits. They see me typing four commands (commit, fetch, rebase,\n> reset) to do the same thing they can do in one command with svn, and\n> conclude that git is harder to use.\n\nNo arguments there. While I know I will never use such a\nworkflow myself, I think it makes sense to _allow_ local\nchanges to be merged to the new revision if the user chooses to\nuse such a workflow.\n\nThe necessary places to change are limited to the Porcelain-ish\nlayer, and adding '-m' option to \"git pull\", just like \"git\ncheckout\" has the corresponding option to allow merging local\nchanges, should not be a rocket science. In fact, I vaguely\nrecall keeping a couple of patches to do so in 'pu' several\nmonths ago, perhaps for a few weeks.\n\nMaybe git has matured too much. In earlier days, people\ncomplained about lack of features and existence of misfeatures,\nand bashed the maintainer with patches. These days, the bashing\nis done with more words and less patches.\n"},{"id":"39864","messageId":"7vejmg9a1z.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"7vy7kpaz9s.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT vs Other: Need argument","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-19T06:02:00Z","receivedAt":"2007-04-19T06:02:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Steven Grimm writes:\n>\n>> And in particular -- this being the original topic of the thread --\n>> when an svn user sees me doing that, they do not immediately think of\n>> the fact that merging between immutable revisions may have some\n>> benefits. They see me typing four commands (commit, fetch, rebase,\n>> reset) to do the same thing they can do in one command with svn, and\n>> conclude that git is harder to use.\n>\n> No arguments there. While I know I will never use such a\n> workflow myself, I think it makes sense to _allow_ local\n> changes to be merged to the new revision if the user chooses to\n> use such a workflow.\n\nActually, there is one thing that makes this much easier to do\nin SVN. It is its centralized nature.\n\nIf you have this sequence:\n\n\t(1) update and sync with the repository\n (2) you work alone, without committing\n (3) while you do (2), other people make commits\n (4) you update from the repository\n\nBecause of its central nature, the commits made in (3) are\nalways proper descendant of the commit you are basing your work\non in (2). So at point (4), the resolution you would need to\nperform is this \"merge\".\n\n (2).............M?\n / . \n\t1-----3a-3b-3c-3d\n\n Notational convention: Solid lines and unparenthesized\n letters are actual commits and ancestry in these pictures.\n Letters in parentheses and dotted lines are locally modified\n states and derivations of these states from commits.\n\nBut because there is no \"commit\" that records the work you did\nin (2) alone, you can afford to 3-way merge whatever conflict\nyou get at M and you do not even record M as a merge. The\nresult simply becomes a proper descendant of 3, which is still\nuncommitted local change.\n\n (2')\n .\n\t1-----3a-3b-3c-3d\n\n\nThe patch series I \"vaguely recalled\" in my previous message\nhandled this special case where the branch being merged\n(i.e. 3d) was a fast-forward of the current commit (i.e. 1).\n\nHowever, in git, you do not necessarily work that way. As you\nadmitted, the ability to commit locally is what's different.\n\n\n 2a---2b..(2c)...M?\n / .\n\t1-----3a-3b-3c-3d\n\nIf (4) happened after you've accmulated local commits 2a, and\n2b, and you have local changes (your state 2c is different from\nyour tip, 2b, but is uncommitted, and kept in the working tree\nalone), you usually do not want to resolve the mess to make a\ncommit M, pretend M is a proper descendant of 3d, depending on\nthe final structure you are trying to achieve (the mess may come\nfrom interactions between 3's and 2a or 2b, or interactions\nbetween 3's and 2c).\n\nThere are three possible commit ancestry structures you would\nwant to eventually reach, and three distinct sets of steps to\nreach those structures.\n\n 1. Perfect what you were in the middle of, and then perform a\n merge. IOW, you don't have to update from remote when you\n are not ready.\n\n 2a---2b---2c----M\n / / \n\t1-----3a-3b-3c-3d\n\n 2. Merge what has already been committed, excluding your\n unproven WIP that is in the working tree, and roll forward\n your local changes on top of it.\n\n 2a---2b---------M..(2c')\n / / \n\t1-----3a-3b-3c-3d\n\n 3. Always serialize by rebasing. The structure you would want\n to end up with is like this:\n\n 2a'-2b'.(2c')\n /\n\t1-----3a-3b-3c-3d\n\nAmong these three workflows, what is most natural in git is the\nfirst one. The tool natively supports it well.\n\nFor the second workflow, you would:\n\n 2-a. first make a tentative commit 2c\n\n\t$ git commit\n\n --2c\n /\n 2a---2b\n /\n\t1-----3a-3b-3c-3d\n\n 2-b. merge what was ready on your end and the other side:\n\n\t$ git checkout HEAD^ && git merge origin\n\n --2c\n /\n 2a---2b---------M\n / / \n\t1-----3a-3b-3c-3d\n\n 2-c. roll forward the local change you have in 2c:\n\n\t$ git rebase --onto HEAD master\n $ git reset HEAD^\n\n 2a---2b---------M...(2c')\n / / \n\t1-----3a-3b-3c-3d\n\n\nThis probably is the next best organization. But you have to\nrealize that this requires you to resolve potential conflict\nwhen creating M and then another conflict when rolling forward\nyour local changes.\n\n We probably could help automating this, but your \"git pull\"\n session transcript need to look like this:\n\n\t$ git pull origin\n First stashing away of your local changes...\n\tResolving conflicts between 2b and 3d.\n\tConflicted merge. Please resolve and commit.\n\t$ edit ; test\n $ git commit ;# to record M\n\tCommitted the merge result.\n You have stashed local changes further to roll forward.\n $ git unstash local-changes\n Resolving conflicts between M and 2c.\n\tLocal changes conflicted during roll-forward.\n Leaving resulting mess in the working tree for you to sort out.\n\t$ \n\n\nTo end up with the third graph, you would:\n\n 3-a. first make a tentative commit 2c\n\n\t$ git commit\n\n --2c\n /\n 2a---2b\n /\n\t1-----3a-3b-3c-3d\n\n 3-b. rebase\n\n\t$ git rebase origin\n\n 2a'--2b'--2c\n /\n\t1-----3a-3b-3c-3d\n\n 3-c. reset\n\n\t$ git reset HEAD^\n\n 2a'--2b'..(2c')\n /\n\t1-----3a-3b-3c-3d\n\n\nand I think that is what you have been doing. Both the final\nstructure and the workflow are least \"git-like\" among these\nthree.\n\n If you want to automate this, you can use this four-liner\n shell script:\n\n\t#!/bin/sh\n git commit || exit\n\tgit fetch origin || exit\n git rebase origin || exit\n\tgit reset HEAD^\n\n Store this in $HOME/bin/git-sgpull, if you may, and you can\n even say \"git sgpull\" to invoke it.\n\n When 'rebase' does not get conflict, which is the bast case\n you are primarily complaining about, having to type three\n commands, this will run to the end with this single command\n and you will feel happier.\n\n When 'rebase' gets conflict, however, you would need to\n resolve and have it keep going, but that is something you\n cannot avoid. You would need to remember that the final\n \"reset HEAD^\" needs to be issued from your shell, but that\n should be obvious.\n"},{"id":"39872","messageId":"Pine.LNX.4.64.0704191033290.8822@racer.site","threadId":"7712","inReplyTo":"8b65902a0704181308i41c878ebi88c03a929769ba39@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T08:37:49Z","receivedAt":"2007-04-19T08:37:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Apr 2007, Guilhem Bonnefille wrote:\n\n> I don't know lot of corporate teams, but here, our developers are\n> REALLY not motivated by VCS. It's only a way to share work. And I'm\n> not talking about concurrent modification: lot of people in my office\n> really think that the better model is the locked one.\n> These people won't be the guy who set up the repo. These people only\n> expect a system to:\n> - retrieve and merge the job done by other people\n> - archive their job for other people.\n\nHow is that not concurrent? If it really was not, there would be no need \nto merge.\n\nAnd let's face it: merging with CVS is cumbersome. Why? Exactly because \nCVS pretends (and tries to make you, too!) that there is just one branch.\n\nGuess what. There are two branches. And they are conflicting. So, once you \nreally looked at the problem you really should agree that branches are the \nnatural mental model to deal with conflicts.\n\n> So for such people, I really think raw Git is much more complicated than \n> CVS/SVN.\n\nI imagine that somebody dedicated enough -- i.e. not me -- could set up \nsome standard aliases which do the CVS/SVN equivalent; we'd probably need \nto support something like\n\n\t[alias]\n\t\tci = commit -a && push origin\n\nwhich should not be all that hard.\n\nCiao,\nDscho\n"},{"id":"39873","messageId":"Pine.LNX.4.64.0704191043140.8822@racer.site","threadId":"7712","inReplyTo":"200704190408.59595.jnareb@gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T08:48:27Z","receivedAt":"2007-04-19T08:48:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Apr 2007, Jakub Narebski wrote:\n\n> Steven Grimm wrote:\n>\n> > One can argue about whether allowing partial commits like that is a \n> > good idea, but it's just not true that svn forces you to always update \n> > before you commit, and if you're pushing into a branch that other \n> > people are also updating, the ability to commit files that didn't \n> > change upstream means it is actually *less* insistent on \n> > update-then-commit than git is (if you take \"commit\" to mean \n> > \"commit-and-push\" on the git side as was suggested in the message I \n> > replied to originally.)\n> > \n> > Unless, of course, I'm misinterpreting you here.\n> \n> I just think the commit _then_ merge (or commit-then-update) workflow is \n> much, much better than update-then-commit one.\n\nLet me pick up the ball here. Once you did your share of conflicting \nmerges, you _will_ realize how much better it is to merge when you are at \na relatively stable state, i.e. you can test things (if only to make sure \nthat the merge did not introduce strange side effects). And guess what, at \nsuch a stage I would commit anyway.\n\nIt is so much easier to resolve conflicts if you can look at both sides, \nand can actually go to both sides to test things out, or even just \ngenerate the diff to one side. This is just not possible with a dirty \nmerge. Exactly because you knowingly lost the current state, you cannot do \ndiffs with it.\n\nNeedless to say (but I do it nevertheless, since I am in a chatty mood), I \n_never_ can be seen doing the 4-command equivalent of `svn up`. I only \npull when I have a clean state. (Note: this also leads to a more \nstructured way of working, which does prevent errors.)\n\nCiao,\nDscho\n"},{"id":"39875","messageId":"Pine.LNX.4.64.0704190954540.23289@reaper.quantumfyre.co.uk","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191043140.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-04-19T08:57:10Z","receivedAt":"2007-04-19T08:57:10Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Thu, 19 Apr 2007, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Thu, 19 Apr 2007, Jakub Narebski wrote:\n>\n>> Steven Grimm wrote:\n>>\n>>> One can argue about whether allowing partial commits like that is a\n>>> good idea, but it's just not true that svn forces you to always update\n>>> before you commit, and if you're pushing into a branch that other\n>>> people are also updating, the ability to commit files that didn't\n>>> change upstream means it is actually *less* insistent on\n>>> update-then-commit than git is (if you take \"commit\" to mean\n>>> \"commit-and-push\" on the git side as was suggested in the message I\n>>> replied to originally.)\n>>>\n>>> Unless, of course, I'm misinterpreting you here.\n>>\n>> I just think the commit _then_ merge (or commit-then-update) workflow is\n>> much, much better than update-then-commit one.\n>\n> Let me pick up the ball here. Once you did your share of conflicting\n> merges, you _will_ realize how much better it is to merge when you are at\n> a relatively stable state, i.e. you can test things (if only to make sure\n> that the merge did not introduce strange side effects). And guess what, at\n> such a stage I would commit anyway.\n>\n> It is so much easier to resolve conflicts if you can look at both sides,\n> and can actually go to both sides to test things out, or even just\n> generate the diff to one side. This is just not possible with a dirty\n> merge. Exactly because you knowingly lost the current state, you cannot do\n> diffs with it.\n\nNot only that, but there is then a _record_ that Joe Developer had to \nmerge your work into his (or vice versa) ...\n\n-- \nJulian\n\n ---\n\"MacDonald has the gift on compressing the largest amount of words into\nthe smallest amount of thoughts.\"\n \t\t-- Winston Churchill\n"},{"id":"298366","messageId":"Pine.LNX.4.64.0704191118050.8822@racer.site","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704180851060.2828@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T09:24:42Z","receivedAt":"2007-04-19T09:24:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Apr 2007, Linus Torvalds wrote:\n\n> On Wed, 18 Apr 2007, Johannes Schindelin wrote:\n> > \n> > On Tue, 17 Apr 2007, Marcin Kasperski wrote:\n> > > \n> > > a) Windows are unsupported\n> > \n> > Wrong.\n> \n> It's a bit more work to set up though, and it has a lot less mindshare, \n> and testing, obviously.\n\nGiven the fact that Hannes is working not only _on_, but _with_ it, tells \nme that it works well enough for any Windows user (remember, they are used \nto rebooting their machines several times a day, just to keep them \nrunning).\n\n> So yes, windows is a step-child. I'd love for it to not be one, and \n> we'll get there, but it's clearly not as supported as the unix side. We \n> still use a fair number of shell scripts (which in turn use unix \n> commands and pipelines).\n\nOf course, the Windows users' \"I want, but I don't contribute\" mindset \ndoes not help either.\n\n> We'll get away from it. I think GSoC will help here.\n\nUnfortunately not as much as I hoped for. Since Google slashed our number \nof projects, we could not get funding for a developer who promised to make \na Windows installer, and to work on the user experience on Windows.\n\nPity.\n\n> Actually, at this stage, I really think cogito just *complicates* git \n> usage.\n\nHmm. However, I have to say that cogito serves/d another purpose quite \nwell: Look at what came from cogito into git. Loads of useful \nenhancements. So, I really have to point to \"at this stage\", because that \nsure was not true 18 months ago.\n\n> What _is_ true is that git is simply different from CVS. I don't think \n> it's necessarily harder to understand or use (in fact, I would argue \n> that git is a lot _easier_ to understand), but it is *different*, and it \n> has a ton more capabilities.\n\nI guess that we should not say that Git is complicated. People tend to \nbelieve that, but it is simply not true. The basic steps are easy. Really \neasy.\n\nBut Git does not keep you there.\n\n> So people coming from CVS/SVN have a double shock: they are supposed to \n> learn things that they \"know\" are hard (because CVS/SVN made them so damn \n> hard - don't tell me that SVN branching is easy, because it is *not* easy. \n> It may be cheaper to create a branch, but it has _all_ the same idiocies \n> that CVS has once it's created).\n\nIt is also dog slow.\n\nCiao,\nDscho\n"},{"id":"39882","messageId":"1176983993.30690.13.camel@cauchy.softax.local","threadId":"7712","inReplyTo":"200704172239.20124.andyparkins@gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Marcin Kasperski","fromEmail":"marcin.kasperski@softax.pl","sentAt":"2007-04-19T11:59:53Z","receivedAt":"2007-04-19T11:59:53Z","isPatch":false,"sender":{"key":"marcin.kasperski@softax.pl","avatar":"https://gravatar.com/avatar/3af6bee834e2974bcbbf9464ba276ecb0b3037b82f9046a1d0e0a0cc339b52ac?d=mp&s=160"},"body":"> but git is definitely no harder to learn \n> than anything else. I browsed through the mecurial tutorial \n> yesterday - and as well as being significantly less powerful than git, \n> it's no easier.\n\nMercurial is easier to learn, because it has better docs and slightly\nsimpler command line (all those -a, -p, ... options which one always\nforgets to add). I tried it.\nIn fact, I did the experiment about month ago. I wanted to give a try\nto distributed vc tool. I started from GIT, played a bit with it, and\nabandoned it because a) I did not know whether I am expected to use git,\nor cg, b) While reading docs many times I had the feeling that something\nstrange and unclear is going behind the hood.\n\nThen I took mercurial and in a few hours I felt I know all the important\nthings.\n\n> (I can't believe this one - if you want to branch a mercurial repository \n> you have to have another complete checkout. Erm... the checkout takes \n> up more space than the repository - why do I need another copy? Anyway, \n> git is no harder than Mercurial here)\n\nAFAIK you are wrong, they are able to link some files while cloning, so\nyou loose space only if you switch machine or filesystem. Also, recent\nmercurial has initial within-repo branches support. But I am not really\nthe best person to conduct git-vs-hg discussion.\n\n> \"(Note for Windows users: Mercurial is missing a merge program\" - that \n> Windows support isn't looking quite so hot now.\n\nMercurial on windows works well with kdiff3 or tortoisemerge, you must\nonly install one of them. \n\n> > c) Lack of reasonable subproject support (plus detailed permission\n> > model).\n> \n> Mercurial has no native subproject support either - it requires a \n> plugin, git's is in development.\n\nAs I said, I am not conducting hg-vs-git discussion. I just happened \nto introduce and manage VC system in corporate environment, so I am able\nto point that this is important feature.\n\n> As for permissions, well Shawn has often spoken of his hook scripts that \n> implement very strong permissions (and he has done so again in this \n> thread).\n\nI am not quite sure how can you forbid johny to see the code\nin ./secret, while johny must checkout whole repo...\n\nPermissions are not only about writing.\n\n> Depends what you want - I installed cygwin \n\nThis is really not an option for typical windows user. Believe me.\nMaybe it could be, if cygwin managed to create normal setup program\none day...\n\nLet me retype it: I am not complaining. GIT developers are not forced to\nthink about win users, or about corporate needs. But if they are, it is\nreasonable to know the problems.\n"},{"id":"39881","messageId":"1176984945.30690.30.camel@cauchy.softax.local","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704180851060.2828@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Marcin Kasperski","fromEmail":"marcin.kasperski@softax.pl","sentAt":"2007-04-19T12:15:45Z","receivedAt":"2007-04-19T12:15:45Z","isPatch":false,"sender":{"key":"marcin.kasperski@softax.pl","avatar":"https://gravatar.com/avatar/3af6bee834e2974bcbbf9464ba276ecb0b3037b82f9046a1d0e0a0cc339b52ac?d=mp&s=160"},"body":"\n> Actually, at this stage, I really think cogito just *complicates* git \n> usage. \n\nAgreed.\n\n> So I don't think it's even true that new people should be pointed at cg \n> any more.\n\nGoogle points to git.or.cz ;-)\n\n> But compare setting up a git repository with setting up a CVS repository.\n> With git, it's literally \"git init\", and you're done. No need to worry \n> about CVSROOT issues etc. Everything is self-contained. CVS is *hard* to \n> get into, by comparison.\n\nI am in no way advocating CVS, but to be fair in such comparison, one\nshould mention also effort of *publishing* git repository and making it\navailable to remote clients. Initialized and configured CVS (or\nsubversion, or perforce, or ...) repo is something ready to be used by\nremote clients.\n\nGetting correct ssh keys in correct places is - for instance -\nnoticeable problem for many people. Especially if they use clients\n(like plink) which natively use alternative key save format. Etc...\n\n> So people coming from CVS/SVN have a double shock: they are supposed to \n> learn things that they \"know\" are hard (because CVS/SVN made them so damn \n> hard - don't tell me that SVN branching is easy, because it is *not* easy. \n\nThe way SVN implemented branching (and tagging!) simply killed the idea\nof using this tool seriously. IMO. Let's leave it.\n\nI agree that git introduces plenty of excellent concepts. What it needs\nis better docs (also, clearly known **SINGLE** master doc, just sth like\nsubversion book), cleaned command line interface (I feel that there are\njust too many lowlevel commands visible for beginning user, maybe at\nleast one could split them into git-* for mere mortals and gitadm-* for\nrepository hackers), portability, and finally GUI.\n\n\t\t\t\tBest regards\n"},{"id":"39883","messageId":"81b0412b0704190521t7dd59f32j84aefedc4aaf1bf0@mail.gmail.com","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191118050.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-19T12:21:09Z","receivedAt":"2007-04-19T12:21:09Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/19/07, Johannes Schindelin wrote:\n> to rebooting their machines several times a day, just to keep them\n> running).\n\nThat's not true! We only need to reboot them once a week to defragment\nVFAT and NTFS volumes and cleanup the registry. Well, sometime the\nantivirus software hangs up our machines and there of course always\nare some malicious programs around. But we do not reboot them several\ntimes a day. On a good day, at leas#$^%$#%^$#!!!!\n"},{"id":"39884","messageId":"46d6db660704190522k29bc65e2x9f8d00707dc381a3@mail.gmail.com","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191118050.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-04-19T12:22:34Z","receivedAt":"2007-04-19T12:22:34Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 4/19/07, Johannes Schindelin wrote:\n> Given the fact that Hannes is working not only _on_, but _with_ it, tells\n> me that it works well enough for any Windows user (remember, they are used\n> to rebooting their machines several times a day, just to keep them\n> running).\n\nuntrue, but very funny :)\n\nMy experience (offtopic, I know):\n\nIn one day, I actually reboot more often my qemu instances with my linux\ntest kernels than the current XP host crashes in a year.\n\n-- \nChristian\n"},{"id":"39885","messageId":"Pine.LNX.4.64.0704191423130.8822@racer.site","threadId":"7712","inReplyTo":"1176984208.30690.18.camel@cauchy.softax.local","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T12:28:27Z","receivedAt":"2007-04-19T12:28:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Marcin,\n\n[re-Cc:ing list]\n\nOn Thu, 19 Apr 2007, Marcin Kasperski wrote:\n\n> \n> > > a) Windows are unsupported\n> > \n> > Wrong.\n> \n> He he, I even downloaded minGW version, just to find that git-pull is \n> bash script...\n\nSo what? Do you think a Python program is a native Windows application?\n\n> > > b) Learning curve is too steep. Unclear relationship git-vs-cogito \n> > > makes it even worse.\n> > \n> > Not so wrong. But then, it is clear that git is git is git. If you \n> > find it too complicated, soon enough somebody says \"use cogito \n> > instead\" and you'll find out about that.\n> \n> As I already said: cogito at the moment does not make life easier, but \n> only confuses. Also, we talked about windows in previous sentence, \n> cogito is a bunch of shell scripts...\n\nAgain, so what?\n\n> > I mean, you can do with CVS, SVN, HG, etc. almost the same as with \n> > Git. But with Git, I find it faster and easier. BTW much of that does \n> > come from the scriptable nature of Git. It _is_ much easier to write a \n> > short and simple script than to work on a plugin.\n> \n> That's double edged sword. The more useful shell scripts, the more \n> unportable tool.\n\nWrong.\n\nWrong, wrong, wrong. Shell runs on more machines than Python, for example. \nAnd if you do not use things like bash arrays, scripts are _perfectly_ \nportable.\n\nIt's the same as with HTML. If you really want to make life hard on users, \nyou can make it unportable. Alas, that's what most web designers in their \ninfinite wisdom do.\n\nBesides, it is not the length of a shell script which makes it unportable. \nFor example, some aspects of cogito scripts prevented me from using it. So \nmuch that I gave up on it.\n\nThere are other reasons to prefer C over shell, performance comes to mind.\n\nCiao,\nDscho\n"},{"id":"39886","messageId":"Pine.LNX.4.64.0704191428360.8822@racer.site","threadId":"7712","inReplyTo":"1176984945.30690.30.camel@cauchy.softax.local","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T12:33:31Z","receivedAt":"2007-04-19T12:33:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Apr 2007, Marcin Kasperski wrote:\n\n[BTW: who said the following? You skipped that information.]\n\n> > So I don't think it's even true that new people should be pointed at cg \n> > any more.\n> \n> Google points to git.or.cz ;-)\n\nHow does Google point to something? You mean the last time you ran the \nsearch, the top find _for you_ was git.or.cz?\n\n> > But compare setting up a git repository with setting up a CVS \n> > repository. With git, it's literally \"git init\", and you're done. No \n> > need to worry about CVSROOT issues etc. Everything is self-contained. \n> > CVS is *hard* to get into, by comparison.\n> \n> I am in no way advocating CVS, but to be fair in such comparison, one\n> should mention also effort of *publishing* git repository and making it\n> available to remote clients. Initialized and configured CVS (or\n> subversion, or perforce, or ...) repo is something ready to be used by\n> remote clients.\n\nNo. Not at all. It took me _one day_ to publish my first CVS repository. \nIt took me exactly 10 seconds to do that with Git.\n\nIf you are referring to readily-usable CVS services like sourceforge's, \nyou are comparing apples with sentences.\n\n> Getting correct ssh keys in correct places is - for instance -\n> noticeable problem for many people. Especially if they use clients\n> (like plink) which natively use alternative key save format. Etc...\n\nI fail to see how you need ssh keys in order to publish a Git repository.\n\n> I agree that git introduces plenty of excellent concepts. What it needs\n> is better docs (also, clearly known **SINGLE** master doc, just sth like\n> subversion book),\n\nDoes that mean you are volunteering?\n\n> cleaned command line interface (I feel that there are\n> just too many lowlevel commands visible for beginning user, maybe at\n> least one could split them into git-* for mere mortals and gitadm-* for\n> repository hackers),\n\nDoes that mean we can expect patches from you?\n\n> portability,\n\nWhich platform are you having in mind?\n\n> and finally GUI.\n\nDoes that mean you will provide patches? A good starting point is git-gui, \nIMHO.\n\nCiao,\nDscho\n"},{"id":"39887","messageId":"Pine.LNX.4.64.0704191434240.8822@racer.site","threadId":"7712","inReplyTo":"46d6db660704190522k29bc65e2x9f8d00707dc381a3@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T12:37:01Z","receivedAt":"2007-04-19T12:37:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Apr 2007, Christian MICHON wrote:\n\n> On 4/19/07, Johannes Schindelin wrote:\n>\n> > Given the fact that Hannes is working not only _on_, but _with_ it, \n> > tells me that it works well enough for any Windows user (remember, \n> > they are used to rebooting their machines several times a day, just to \n> > keep them running).\n> \n> untrue, but very funny :)\n\nOh, but it is true! That's personal experience. My typical answer: \"You \nneeded to reboot? What is a 'reboot'?\"\n\n> My experience (offtopic, I know):\n> \n> In one day, I actually reboot more often my qemu instances with my linux \n> test kernels than the current XP host crashes in a year.\n\nWith a linux test kernel. Yeah, right. So, you compare an experimental \ntest kernel -- which I gather you stress test? -- with an XP kernel where \nyou probably do not even check mails while running QEmu, for fear that it \ncrashes? *lol*!\n\nCiao,\nDscho\n"},{"id":"39888","messageId":"1176986247.30690.37.camel@cauchy.softax.local","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191423130.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Marcin Kasperski","fromEmail":"marcin.kasperski@softax.pl","sentAt":"2007-04-19T12:37:27Z","receivedAt":"2007-04-19T12:37:27Z","isPatch":false,"sender":{"key":"marcin.kasperski@softax.pl","avatar":"https://gravatar.com/avatar/3af6bee834e2974bcbbf9464ba276ecb0b3037b82f9046a1d0e0a0cc339b52ac?d=mp&s=160"},"body":"(I am not trying to make flame-war, so I restrict to \n\n> > He he, I even downloaded minGW version, just to find that git-pull is \n> > bash script...\n> \n> So what? Do you think a Python program is a native Windows application?\n\nWho cares... Mercurial binary build distributes hg as .exe (made by\npy2exe or some other converter). The net point is that when I type 'hg'\nin windows console, I get running mercurial. When I type 'git-pull' I\nget error.\n\n> > That's double edged sword. The more useful shell scripts, the more \n> > unportable tool.\n> \n> Wrong.\n> \n> Wrong, wrong, wrong. Shell runs on more machines than Python, for example. \n> And if you do not use things like bash arrays, scripts are _perfectly_ \n> portable.\n\nHmm. At the moment I am using more or less frequently: Debian Linux,\nTru64 Unix, OpenVMS, Windows XP. Python works well on all of those.\nShell scripts work on the first one and partially on the second one.\n\n(yesss, I tried using Cygwin, this is NOT the way to go)\n"},{"id":"39889","messageId":"1176986559.30690.43.camel@cauchy.softax.local","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191428360.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Marcin Kasperski","fromEmail":"marcin.kasperski@softax.pl","sentAt":"2007-04-19T12:42:39Z","receivedAt":"2007-04-19T12:42:39Z","isPatch":false,"sender":{"key":"marcin.kasperski@softax.pl","avatar":"https://gravatar.com/avatar/3af6bee834e2974bcbbf9464ba276ecb0b3037b82f9046a1d0e0a0cc339b52ac?d=mp&s=160"},"body":"> > Google points to git.or.cz ;-)\n> \n> How does Google point to something? You mean the last time you ran the \n> search, the top find _for you_ was git.or.cz?\n\nExactly. Searches for git documentation, git tutorial, git version\ncontrol pointed there.\n\n\n> > I agree that git introduces plenty of excellent concepts. What it needs\n> > is better docs (also, clearly known **SINGLE** master doc, just sth like\n> > subversion book),\n> \n> Does that mean you are volunteering?\n\nNo, as I do not have necessary knowledge. But I can volunteer to review\none.\n\n> > cleaned command line interface (I feel that there are\n> > just too many lowlevel commands visible for beginning user, maybe at\n> > least one could split them into git-* for mere mortals and gitadm-* for\n> > repository hackers),\n> \n> Does that mean we can expect patches from you?\n\nNot sure what is your point Johannes, but if you wanted to say that if\nsomebody is not actively developing git, he should not make any comments\nregarding this, you could try doing this in a more straightforward\nmanner.\n"},{"id":"39890","messageId":"20070419124536.GD3513@thunk.org","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191428360.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-04-19T12:45:36Z","receivedAt":"2007-04-19T12:45:36Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Apr 19, 2007 at 02:33:31PM +0200, Johannes Schindelin wrote:\n> > > So I don't think it's even true that new people should be pointed at cg \n> > > any more.\n> > \n> > Google points to git.or.cz ;-)\n> \n> How does Google point to something? You mean the last time you ran the \n> search, the top find _for you_ was git.or.cz?\n\nI just checked today. If you go to http://www.google.com, and enter\n\"git\", and then click on \"I'm feeling lucky\", you will go to\nhttp://git.or.cz. One of the first links you will then see,\nmisleading titled in a box labelled, \"Git crash courses\", are \"Git for\nCVS users\", and \"Git for SVN users\", and both of these getting started\ndocuments reference cg commands and only cg commands.\n\nSo when projects downgrade git as having confusing documentation, and\ntutorials that contradict each other about how to do things, this is\nvery likely one of the reasons why.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"39891","messageId":"20070419124648.GL4489@pasky.or.cz","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704180851060.2828@woody.linux-foundation.org","subject":"[ANNOUNCE] Cogito is for sale","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-04-19T12:46:48Z","receivedAt":"2007-04-19T12:46:48Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Apr 18, 2007 at 06:07:55PM CEST, Linus Torvalds wrote:\n> Actually, at this stage, I really think cogito just *complicates* git \n> usage. It hasn't been well-supported lately, and asking for help with \n> cogito means that a lot of people can't help you. And you still end up \n> using git commands for anything fancier.\n\nAnd at this stage, I actually rather agree.\n\nI've been torn apart about this for few weeks now, struggling to get\nsome time (and strong motivation) to dive through the dusty cogito\npatchqueues etc., and wondering what to actually *do* about Cogito.\nI have been actually inclined to, hmm, \"phase out\" Cogito for some time\nalready, but then always some very nice mail from a Cogito user comes\nand throws me in doubts. But this thread pushed me over the edge. ;-)\n\nI agree that by now, the situation is too confusing and while I'm not\nhappy with everything in Git, I believe that by now the best way is to\njust fix Git. Therefore, I'm announcing that I don't plan to add any (at\nleast any significant) new features to Cogito. Sorry to all the Cogito\nusers, it is a hard decision for me, but by now I believe that it is\nmuch more effective to just focus on Git.\n\nIf anyone else wants to take over Cogito maintainership, you're most\nwelcome: let me know, please! The \"patch queue\" means just filtering\n=git mailbox, but I have some WIP code to add the .git/config \"remotes\"\nsupport to Cogito, if you are interested.\n\nUntil someone else steps out to maintain Cogito, I'm not going to\nabandon Cogito absolutely. I still plan to dive through the patch queue\nas soon as possible and then continue integrating bugfixes and/or\nsmaller-scale changes necessary for newer Git versions. I'll maybe also\nwrite a trivial more-or-less 1:1 cg->git porcelain wrapper for those\nwho trained their fingers to 'cg' instead of 'git'; but maybe it's best\njust to retrain. ;-)\n\n\nAbout git homepage:\n\nThe very least I wanted to do at any rate with git.or.cz ASAP is to\nswitch the crash courses to git-oriented ones too. I think git more or\nless got to a reasonable point when this is a sane idea. Do you have any\ntips on exactly what zero-level introductory material I should put there\ninstead of the Cogito crash courses, or should we write new ones\n(perhaps based on the current ones)? I probably won't have much time to\nwrite a lot of stuff, but I'll gladly use whatever reasonable anyone\nsuggests/writes, and I have no qualms to just give well-known people\npush access to the homepage repository.\n\nLive and prosper,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"39892","messageId":"81b0412b0704190548x5a26395elc0f42abd17c48100@mail.gmail.com","threadId":"7712","inReplyTo":"1176983993.30690.13.camel@cauchy.softax.local","subject":"Re: GIT vs Other: Need argument","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-19T12:48:42Z","receivedAt":"2007-04-19T12:48:42Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/19/07, Marcin Kasperski wrote:\n>\n> Let me retype it: I am not complaining. GIT developers are not forced to\n> think about win users, or about corporate needs. But if they are, it is\n> reasonable to know the problems.\n>\n\nWindows (and, by extension, most corporate) users are used to both:\ncomplain and suffer. What they cannot imagine is _doing_ something.\nIt just does not fit in their heads.\n\nA user feels the need to restrict access to some trees in a git repository?\nHe'll start looking, asking, and maybe even raving about the missing\nfeature on some official channel. What never occurs to him is just\nimplementing it. And he'll be outraged if you suggest it (and, yes, it was\ntried. The person felt insulted and is sulking till this day)\n\nBesides, it looks like we need them: the stupid, lazy and numerous\nwindows users. I sometimes ask myself what for did I try to explain\nmerging and distributed workflow to my peers? The most reasonable\nanswer so far: so they don't bother me with their stupid work flow.\nDon't like it though: people don't like to be called stupid (or anything\nthey do), and I happen to like most of them anyway.\nAnd I start coding workarounds (the recent is git-remote, why the\nhell must it be coded in perl?)\n"},{"id":"39893","messageId":"46d6db660704190554l42ccae4ds861787939903ecb3@mail.gmail.com","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191434240.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-04-19T12:54:17Z","receivedAt":"2007-04-19T12:54:17Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 4/19/07, Johannes Schindelin wrote:\n> Oh, but it is true! That's personal experience. My typical answer: \"You\n> needed to reboot? What is a 'reboot'?\"\n\nI agree it was the case in the past.\n\n> > My experience (offtopic, I know):\n> >\n> > In one day, I actually reboot more often my qemu instances with my linux\n> > test kernels than the current XP host crashes in a year.\n>\n> With a linux test kernel. Yeah, right. So, you compare an experimental\n> test kernel -- which I gather you stress test? -- with an XP kernel where\n> you probably do not even check mails while running QEmu, for fear that it\n> crashes? *lol*!\n\nlet me rephrase:\n- I run some test on about a kernel I regenerate about > 20 times\na day [I'm making a distro right now...]\n- my host XP crashes less than 20 times in a year\n\nI was not comparing both kernels: I would not be spending time on\nbuilding a linux distro if I was not convinced linux is far superior :)\n\n-- \nChristian\n"},{"id":"39894","messageId":"200704191357.48816.andyparkins@gmail.com","threadId":"7712","inReplyTo":"1176983993.30690.13.camel@cauchy.softax.local","subject":"Re: GIT vs Other: Need argument","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-19T12:57:47Z","receivedAt":"2007-04-19T12:57:47Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 April 19 12:59, Marcin Kasperski wrote:\n> > but git is definitely no harder to learn\n> > than anything else. I browsed through the mecurial tutorial\n> > yesterday - and as well as being significantly less powerful than git,\n> > it's no easier.\n>\n> Mercurial is easier to learn, because it has better docs and slightly\n> simpler command line (all those -a, -p, ... options which one always\n> forgets to add). I tried it.\n> In fact, I did the experiment about month ago. I wanted to give a try\n> to distributed vc tool. I started from GIT, played a bit with it, and\n> abandoned it because a) I did not know whether I am expected to use git,\n> or cg, b) While reading docs many times I had the feeling that something\n> strange and unclear is going behind the hood.\n\nIn terms of normal operation, there aren't many switches one actually needs to \nremember. The only one I can think of is \"-a\" for commit - however, that's \njust to make it work like mercurial - a seasoned git user won't use many \nswitches. My daily grind consists of\n\n git add file.c\n git commit\n git add file.c\n git commit\n git add -i\n git commit\n\n(Interactive mode for git-add is a joy to use - I don't know if Mercurial has \nanything similar).\n\nNow, to your point. I think you're right. What I said was that git actually \nis easier; however if you looked at some of the documentation you would \nincorrectly assume that that was not the case.\n\n> > (I can't believe this one - if you want to branch a mercurial repository\n> > you have to have another complete checkout. Erm... the checkout takes\n> > up more space than the repository - why do I need another copy? Anyway,\n> > git is no harder than Mercurial here)\n>\n> AFAIK you are wrong, they are able to link some files while cloning, so\n\nCan't be. I'm talking about the working directory not the repository - if the \nfiles are linked back to the originals, then it's not a separately editable \nset of files is it?\n\n> you loose space only if you switch machine or filesystem. Also, recent\n> mercurial has initial within-repo branches support. But I am not really\n> the best person to conduct git-vs-hg discussion.\n\nI'm glad that Mercurial is getting in-repo branches, they're great. I really \nwouldn't want to live without them now I have them.\n\n> > \"(Note for Windows users: Mercurial is missing a merge program\" - that\n> > Windows support isn't looking quite so hot now.\n>\n> Mercurial on windows works well with kdiff3 or tortoisemerge, you must\n> only install one of them.\n\nAren't they manual merge tools? I think \"merge\" is for merging automatically, \nand moaning about conflicts if they turn up - /then/ you go to tortoisemerge.\n\n> As I said, I am not conducting hg-vs-git discussion. I just happened\n> to introduce and manage VC system in corporate environment, so I am able\n> to point that this is important feature.\n\nI appreciate that - I don't want to start a fight. My point should probably \nhave been more directly focussed on git (which was what I wanted to do) - \nit's my opinion that git is in fact easier than Mercurial; however, it's \npublic face is not letting people see that.\n\n> > As for permissions, well Shawn has often spoken of his hook scripts that\n> > implement very strong permissions (and he has done so again in this\n> > thread).\n>\n> I am not quite sure how can you forbid johny to see the code\n> in ./secret, while johny must checkout whole repo...\n\nMe either - the only permissions that could have been relevant are those \nneeded to push to the central repository. As I said, git can cope there \nwithout trouble.\n\n> Permissions are not only about writing.\n\nThat one is true - perhaps one day git will get partial clone support to match \nit's shallow clones - then it would be possible to put permissions on the \nread of a central repository. Can Mercurial do that?\n\n> > Depends what you want - I installed cygwin\n>\n> This is really not an option for typical windows user. Believe me.\n> Maybe it could be, if cygwin managed to create normal setup program\n> one day...\n\nI'm not an expert in Windows by any means - all I did was run setup.exe and \npicked git and ssh from the list. It doesn't get much easier.\n\n> Let me retype it: I am not complaining. GIT developers are not forced to\n> think about win users, or about corporate needs. But if they are, it is\n> reasonable to know the problems.\n\nAbsolutely - I certainly haven't taken anything you've written as a complaint. \nIf anything I find it interesting because I think it confirms what I \nthought - git is not short on features or usability, it's just got a PR \nproblem.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"39896","messageId":"vpqlkgoec7j.fsf@bauges.imag.fr","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704181346440.4504@xanadu.home","subject":"Re: GIT vs Other: Need argument","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-04-19T13:16:32Z","receivedAt":"2007-04-19T13:16:32Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 18 Apr 2007, Matthieu Moy wrote:\n>\n>> Then, I can't even find it in the tutorial, but somewhere, it should\n>> be mentionned to say who I am in ~/.gitconfig.\n\nI was talking about the \"Git for CVS users\" crash course, which is the\none I was naturally pointed to looking for documentation.\n\n> One of the very first thing you can find in Documentation/tutorial.txt \n> is:\n\nThis tutorial should _really_ be advertized better on\nhttp://git.or.cz/. Probably in the frame \"crash courses\", and on\nhttp://git.or.cz/course/index.html\n\nIndeed, most of the content of http://git.or.cz/#documentation should\nalso appear on http://git.or.cz/course/index.html IMHO.\n\nThat's a detail, but once you've clicked \"Git crash course\", the\ntutorial is not reachable anymore.\n\n(all that said, I think the documentation has already greatly improved\nsince I started a few weeks ago. Continue the good job!)\n\n-- \nMatthieu\n"},{"id":"39897","messageId":"vpqhcrcebmp.fsf@bauges.imag.fr","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191033290.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-04-19T13:29:02Z","receivedAt":"2007-04-19T13:29:02Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> How is that not concurrent? If it really was not, there would be no need \n> to merge.\n\nIt can be concurrent, but on different files. Concurrency and merge at\nthe filetree level, but never within a file. I've worked in a team\nwhere the \"corporate\" use of a VCS was following this model. Not\nlocking a file before editing it was considered a mistake.\n\n>> So for such people, I really think raw Git is much more complicated than \n>> CVS/SVN.\n>\n> I imagine that somebody dedicated enough -- i.e. not me -- could set up \n> some standard aliases which do the CVS/SVN equivalent; we'd probably need \n> to support something like\n>\n> \t[alias]\n> \t\tci = commit -a && push origin\n>\n> which should not be all that hard.\n\nIt depends on how you implement that.\n\nThere have been a discussion crossposted here and on the bzr ML. The\nauthor of cogito added a similar feature to cogito.\n\nBut to emulate the centralized model, you need more than that, you\nhave to\n\n1) make sure you're up to date with upstream\n2) commit\n3) push\n\nand to do it correctly, 1) must be checked during all the procedure,\nand doing it in a transactional way is not trivial.\n\nbzr has a notion of \"bound branches\". That is, when you commit to a\nbound branch, you also commit to the master branch. And the UI for\nthat is to use \"bzr checkout master-branch\". I agree the centralized\nmodel is inferior in general, but there are several cases where this\nis handy. One of them being to teach a newbie: \"see, learn checkout,\nupdate, commit, add, mv, remove and you know how to use it\". Another,\nfor me, is to avoid forgetting to push ;-).\n\n-- \nMatthieu\n"},{"id":"39898","messageId":"vpq4pncebh2.fsf@bauges.imag.fr","threadId":"7712","inReplyTo":"20070419124648.GL4489@pasky.or.cz","subject":"Re: [ANNOUNCE] Cogito is for sale","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-04-19T13:32:25Z","receivedAt":"2007-04-19T13:32:25Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Petr Baudis writes:\n\n> Therefore, I'm announcing that I don't plan to add any (at least any\n> significant) new features to Cogito.\n\nI believe this is the right decision, but anyway, thanks for your work\non cogito!\n\n-- \nMatthieu\n"},{"id":"39899","messageId":"Pine.LNX.4.64.0704191528360.8822@racer.site","threadId":"7712","inReplyTo":"1176986247.30690.37.camel@cauchy.softax.local","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T13:32:49Z","receivedAt":"2007-04-19T13:32:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Apr 2007, Marcin Kasperski wrote:\n\n> > And if you do not use things like bash arrays, scripts are _perfectly_ \n> > portable.\n> \n> Hmm. At the moment I am using more or less frequently: Debian Linux,\n> Tru64 Unix, OpenVMS, Windows XP. Python works well on all of those.\n> Shell scripts work on the first one and partially on the second one.\n> \n> (yesss, I tried using Cygwin, this is NOT the way to go)\n\nHeh, without an explanation as to why, this sure sounds like an invitation \nto a very flamy war.\n\nCiao,\nDscho\n"},{"id":"39900","messageId":"Pine.LNX.4.64.0704191533200.8822@racer.site","threadId":"7712","inReplyTo":"1176986559.30690.43.camel@cauchy.softax.local","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T13:36:06Z","receivedAt":"2007-04-19T13:36:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Apr 2007, Marcin Kasperski wrote:\n\n> > > cleaned command line interface (I feel that there are just too many \n> > > lowlevel commands visible for beginning user, maybe at least one \n> > > could split them into git-* for mere mortals and gitadm-* for \n> > > repository hackers),\n> > \n> > Does that mean we can expect patches from you?\n> \n> Not sure what is your point Johannes, but if you wanted to say that if \n> somebody is not actively developing git, he should not make any comments \n> regarding this, you could try doing this in a more straightforward \n> manner.\n\nNo. I said that tongue-in-cheek.\n\nBut my point was: Since the current developers evidently are comfortable \nwith the current set of command line options, and the consistency thereof, \nit needs more than some hand waving comments about what you want changed, \nand how.\n\nTo state it clearly: if you have any concrete wishes as to the \nclarification of Git, and to make it easier for beginners (at the same \ntime not making it harder on others), I will be very glad to know them. \nAnd I think that the list will welcome these equally eagerly.\n\nCiao,\nDscho\n"},{"id":"39901","messageId":"20070419142733.GC4586@fieldses.org","threadId":"7712","inReplyTo":"1176986559.30690.43.camel@cauchy.softax.local","subject":"Re: GIT vs Other: Need argument","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-04-19T14:27:33Z","receivedAt":"2007-04-19T14:27:33Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Apr 19, 2007 at 02:42:39PM +0200, Marcin Kasperski wrote:\n> > > I agree that git introduces plenty of excellent concepts. What it needs\n> > > is better docs (also, clearly known **SINGLE** master doc, just sth like\n> > > subversion book),\n> > \n> > Does that mean you are volunteering?\n> \n> No, as I do not have necessary knowledge. But I can volunteer to review\n> one.\n\nThat would be great--see Documentation/user-manual.txt. (Or\nhttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html.)\n\nPatches welcomed, but so is general review. It's not my highest\npriority, unfortunately, so I may be a little slow to address comments,\nbut I'll get to them eventually.\n\nI don't expect it to ever be a *single* master doc--I still want to\nleave a lot of the details to the man pages, for example, and I expect\nthere'll always be a need for some shortcut howto's and tutorials. I\nsuppose we could include much of that into appendices some day if it\nhelped findability.\n\n--b.\n"},{"id":"39906","messageId":"alpine.LFD.0.98.0704190940330.9964@woody.linux-foundation.org","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191118050.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-19T16:43:50Z","receivedAt":"2007-04-19T16:43:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Apr 2007, Johannes Schindelin wrote:\n> \n> > Actually, at this stage, I really think cogito just *complicates* git \n> > usage.\n> \n> Hmm. However, I have to say that cogito serves/d another purpose quite \n> well: Look at what came from cogito into git. Loads of useful \n> enhancements. So, I really have to point to \"at this stage\", because that \n> sure was not true 18 months ago.\n\nAbsolutely. I think there are still some pieces of cogito that we might \nwant to migrate into git too, although they're fairly esoteric (ie the \nwhole history rewriting thing). And I think we still have some places \nwhere git is influenced by cogito doing things differently (ie the whole \nbranch tracking stuff) where we may want to change our default behaviour \nor extend on things.\n\nSo yes, \"at this stage\" was the operative word.\n\n> I guess that we should not say that Git is complicated. People tend to \n> believe that, but it is simply not true. The basic steps are easy. Really \n> easy.\n> \n> But Git does not keep you there.\n\nI agree. And to some degree I suspect that the documentation pushes some \nof the advanced things a bit *too* eagerly.\n\nOf course, with many of the projects that use git being very \nbranch-oriented, I guess some of that is inevitable. You can't *not* \nmention branches, simply because even people who only track other peoples \nwork do end up often needing to know about it, or at least hearing about \nthem..\n\n\t\tLinus\n"},{"id":"39909","messageId":"4627ABBB.8060709@softax.com.pl","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704190940330.9964@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Marcin Kasperski","fromEmail":"marcin.kasperski@softax.com.pl","sentAt":"2007-04-19T17:49:47Z","receivedAt":"2007-04-19T17:49:47Z","isPatch":false,"sender":{"key":"marcin.kasperski@softax.com.pl","avatar":"https://gravatar.com/avatar/876c331bb177f09eaebc1447c2c890dc36d7c46b3ac09754003b8da1633eb20b?d=mp&s=160"},"body":"\n>> I guess that we should not say that Git is complicated. People tend to \n>> believe that, but it is simply not true. (...)\n>\n> I agree. And to some degree I suspect that the documentation pushes some \n> of the advanced things a bit *too* eagerly. (...)\nAs I am among those, who think that git *is* complicated, I decided to \nsit down, and find out why\nexactly I think so. Here are the top words/options/concepts, which I \nfaced almost immediately while\ntrying GIT, and which I find confusing:\n\nrebase\nindex\nrevtree\nreset\nref / refs\nrev-list\nrev-parse\n\nAt the same time, concepts like add, rm, commit, push, pull, merge are \nnatural and easily understandable.\n"},{"id":"39910","messageId":"4627B292.6080202@midwinter.com","threadId":"7712","inReplyTo":"7vejmg9a1z.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT vs Other: Need argument","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-04-19T18:18:58Z","receivedAt":"2007-04-19T18:18:58Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Thanks for that detailed writeup. It squares pretty well with my \nunderstanding.\n\n\nJunio C Hamano wrote:\n> (2).............M?\n> / . \n> \t1-----3a-3b-3c-3d\n>\n> [...]\n> (2')\n> .\n> \t1-----3a-3b-3c-3d\n>\n>\n> The patch series I \"vaguely recalled\" in my previous message\n> handled this special case where the branch being merged\n> (i.e. 3d) was a fast-forward of the current commit (i.e. 1).\n> \n\nI think this is actually the case I'd be most concerned about getting \nright for those people who are coming from svn and want to change their \nworkflow as little as possible at first. The class of people who would \nexclusively use an \"svnish-commit\" alias that did \"git commit;git push\" \n-- that is, who never do local commits -- would always find themselves \nwith this setup.\n\n> 3. Always serialize by rebasing. The structure you would want\n> to end up with is like this:\n>\n> 2a'-2b'.(2c')\n> /\n> \t1-----3a-3b-3c-3d\n> \n\nYou are correct in pointing out later on that my fetch+rebase workflow \nfits this structure. And for my particular environment it's actually the \nonly one I can use a lot of the time, because I'm usually pushing to a \nshared git-svn repository (or working in a git-svn repo of my own), from \nwhich the changes will get committed back to svn. Eric Wong has warned \nthat git-svn doesn't deal well with merges; it expects linear history. \nSo for now this is the structure I need to end up with, at least until \ngit-svn learns how to deal with nonlinear ancestry, if that's even \npossible at all given svn's inherent limitations.\n\nI look forward to the day when git has built up enough critical mass \nhere that we can just switch over to it completely and ditch that kind \nof restriction. With that happy day in mind, I'd still love to see the \nother workflows made as painless as possible, so more comments below.\n\n> For the second workflow, you would:\n>\n> 2-a. first make a tentative commit 2c\n> 2-b. merge what was ready on your end and the other side:\n> 2-c. roll forward the local change you have in 2c:\n>\n> We probably could help automating this, but your \"git pull\"\n> session transcript need to look like this:\n>\n> \t$ git pull origin\n> First stashing away of your local changes...\n> \tResolving conflicts between 2b and 3d.\n> \tConflicted merge. Please resolve and commit.\n> \t$ edit ; test\n> $ git commit ;# to record M\n> \tCommitted the merge result.\n> You have stashed local changes further to roll forward.\n> $ git unstash local-changes\n> Resolving conflicts between M and 2c.\n> \tLocal changes conflicted during roll-forward.\n> Leaving resulting mess in the working tree for you to sort out.\n> \n\nI wonder if it makes sense to automate that even more and make git pull \nbehave a bit statefully like rebase does:\n\n $ git pull origin\n Stashing local changes.\n Resolving conflicts, pass 1.\n Conflicts! Please resolve.\n $ edit ; test\n $ git pull --continue\n Committing revision M.\n Unstashing your local changes.\n Resolving conflicts, pass 2.\n Local changes conflicted during roll-forward. Sort it out.\n $\n\nWhen git pull --continue does the commit, it *might* be nice for it to \ndo a variant of commit -a: if the user has modified all the conflicting \nfiles, *and* not done an update-index on any of them manually, then do \nthe update-index implicitly. (That \"and\" part would be to prevent it \nfrom tripping up experienced git users who want to manually mark the \nconflicting files as resolved by running update-index.) I'm not sure \nthat's actually a good idea, though it'd save some commands most of the \ntime; the danger, of course, is that you could end up committing a \nhalf-resolved file by accident. But then I guess there's nothing \npreventing you from doing that with update-index today.\n\nBut that's attractive because it's exactly two git commands in the most \ncomplex case (conflicts in the merge of committed revisions) and only \none git command in the simplest cases (no conflicts or conflicts only in \nthe working copy edits.) In the case of no working copy edits, \n--continue would just do the commit for you.\n\nTo make pull and rebase even more consistent, one could also allow git \npull --abort to roll back the pull during a conflict resolution, whether \nor not it's a working-copy-edits one. People might find that a handy \nshortcut in other workflows too; it would probably just do a hard reset \nback to the pre-merge revision in the no-working-copy-edits case. \nObviously that wouldn't be new functionality, just an arguably slightly \nmore intuitive way to do it than what exists now.\n\n> If you want to automate this, you can use this four-liner\n> shell script:\n>\n> \t#!/bin/sh\n> git commit || exit\n> \tgit fetch origin || exit\n> git rebase origin || exit\n> \tgit reset HEAD^\n> \n\nActually I think I like the idea of making that a little more robust and \nhaving it take a --continue option like I described above. No reason it \ncan't keep track of its current state. I will spend some time this \nweekend doing that.\n\n-Steve\n"},{"id":"39912","messageId":"20070419184420.GM4489@pasky.or.cz","threadId":"7712","inReplyTo":"vpqlkgoec7j.fsf@bauges.imag.fr","subject":"Re: GIT vs Other: Need argument","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-04-19T18:44:20Z","receivedAt":"2007-04-19T18:44:20Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Apr 19, 2007 at 03:16:32PM CEST, Matthieu Moy wrote:\n> Nicolas Pitre writes:\n> > One of the very first thing you can find in Documentation/tutorial.txt \n> > is:\n> \n> This tutorial should _really_ be advertized better on\n> http://git.or.cz/. Probably in the frame \"crash courses\", and on\n> http://git.or.cz/course/index.html\n> \n> Indeed, most of the content of http://git.or.cz/#documentation should\n> also appear on http://git.or.cz/course/index.html IMHO.\n> \n> That's a detail, but once you've clicked \"Git crash course\", the\n> tutorial is not reachable anymore.\n\nI have added the tutorial to the crash course section, but it should\nsomehow integrated to the website... I wonder if that's easily possible\nwithout getting out of sync. I've also clearly labelled the CVS/SVN\ncrash courses to be Cogito-focused. I'll wait for list feedback in order\nto decide what to do with them further.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"39913","messageId":"4627BCF0.3000004@midwinter.com","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704191043140.8822@racer.site","subject":"Re: GIT vs Other: Need argument","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-04-19T19:03:12Z","receivedAt":"2007-04-19T19:03:12Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Let me pick up the ball here. Once you did your share of conflicting \n> merges, you _will_ realize how much better it is to merge when you are at \n> a relatively stable state, i.e. you can test things (if only to make sure \n> that the merge did not introduce strange side effects). And guess what, at \n> such a stage I would commit anyway.\n> \n\nThat's a great workflow if you're working on relatively discrete, \nstandalone changes. A lot of the time, when I'm working on an isolated \nchange, I do just that, and I merge when I'm stable just like you \ndescribe. That's probably the vastly most common mode of operation for \ndistributed open-source projects, which obviously were git's initial \ntarget audience.\n\nHowever, it is frequently NOT the mode of operation for development at a \ncompany where two or more people are working on implementing the same \nnew feature in a highly collaborative way, often sitting across the room \nfrom one another. In that situation, it's frequently the case that, for \nexample, I'm coding and discover I need some new utility method that Joe \ncan easily factor out of the code he just checked in. So he does his \nquick refactoring, commits that change, and I pull it into my sandbox \nwhere I am *not* yet at a stable stopping point because I was waiting \nfor his change in order to finish and/or test my change. Or, more \ncommonly, I discover a bug in his code and he checks in a fix I want to \npick up.\n\nThat's the use case for dirty working-copy merges. It is extremely \ncommon in my experience. Actually I can't think of a single company I've \nworked at in ~20 years of professional programming, from huge ones to \nsmall startups, where that wasn't a frequent working style, especially \nduring crunch times or initial implementation.\n\nThe XP people even have a name for it: \"continuous integration.\" \n(Granted, that's not *exactly* what that term means, but \"update early \nand often\" is a pretty important part of the CI workflow.)\n\n> It is so much easier to resolve conflicts if you can look at both sides, \n> and can actually go to both sides to test things out, or even just \n> generate the diff to one side. This is just not possible with a dirty \n> merge. Exactly because you knowingly lost the current state, you cannot do \n> diffs with it.\n> \n\nI don't disagree, but that's only an issue given the underlying \nassumption that you will be integrating only occasionally, and thus will \ntend to pull massive numbers of changes with lots of conflicts. If you \nknow there will be at most one or two conflicts (or more likely none at \nall) because your last pull was twenty minutes ago and there have only \nbeen three other pushes since then, it's not an issue. That's the \ntypical situation in a continuous-integration shop. I'd say 95% -- to be \nridiculously conservative -- of the \"svn up\" commands that are run at my \ncompany result in no conflicts at all.\n\nWhen a large conflict is a once-every-couple-of-months event because \nyou've resolved all the trivial conflicts as they've appeared along the \nway, optimizing your daily workflow for the \"what if I need to resolve a \nbig hairy conflict?\" case just doesn't make much sense.\n\n> Needless to say (but I do it nevertheless, since I am in a chatty mood), I \n> _never_ can be seen doing the 4-command equivalent of `svn up`. I only \n> pull when I have a clean state. (Note: this also leads to a more \n> structured way of working, which does prevent errors.)\n> \n\nAnd out of curiosity, are you using git for distributed, relatively \nautonomous development, or for collaboration with a high level of \ninterdependency between developers?\n\n-Steve\n"},{"id":"39918","messageId":"7vzm545d0o.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"20070419124648.GL4489@pasky.or.cz","subject":"Re: [ANNOUNCE] Cogito is for sale","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-19T20:23:51Z","receivedAt":"2007-04-19T20:23:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> I agree that by now, the situation is too confusing and while I'm not\n> happy with everything in Git, I believe that by now the best way is to\n> just fix Git. Therefore, I'm announcing that I don't plan to add any (at\n> least any significant) new features to Cogito. Sorry to all the Cogito\n> users, it is a hard decision for me, but by now I believe that it is\n> much more effective to just focus on Git.\n\nI applaud this; I know this must have been a hard decision for\nyou to make.\n\n> About git homepage:\n>\n> The very least I wanted to do at any rate with git.or.cz ASAP is to\n> switch the crash courses to git-oriented ones too. I think git more or\n> less got to a reasonable point when this is a sane idea.\n\nI would agree, at this point.\n\nWhen git.or.cz started offering those introductory pages, the\nPorcelain-ish scripts (that is correct, \"scripts\", as there were\nno \"built-in\" -- even \"git diff\" unified driver was a shell\nscript to driver diff-index, diff-files and diff-tree) shipped\nwith the core git was infinitely less pleasant to normal people,\nespecially the ones who have not seen the early days of git core\nwhich shipped with almost none. When you and I talked about\nwhat text to put on git.or.cz, it was an obvious and easy thing\nto agree on that newbie documentation should be based on Cogito,\nand you did all the work to put the site together.\n\n I am saying this now for new people on the list, as I heard\n an incorrect \"theory\" that you have been advertising Cogito\n on git.or.cz site against the community's best interest,\n even when nobody seems to talk about it these days on the\n list anymore.\n\nSince the early days of my involvement in git project, I said my\ngoal was to keep the plumbing stable, enhance the plumbing in\nsuch a way that any and all Porcelains can do what they want\nwithout resorting to Porcelain-specific hacks, so that the\nresulting repositories can interoperate no matter what Porcelain\nwas used on top of the plumbing. I worded that goal as \"make\nthe choice of Porcelains irrelevant\". While that ideal still\nstands, we ended up having rich enough Porcelain in the core\ndistribution. To some people, this might look as if we are\nmaking alternative Porcelains irrelevant instead, but that is\nnot the case. Many features and workflows that are now\nsupported by the core Porcelain were first invented outside\n(e.g. \"automated tag following while fetching\" came from\nCogito), and the core Porcelain does not ship with special\npurpose features and expect alternative/augmentative Porcelains\nto fill the niche (an existing example is that people who want\npatch management use StGIT or guilt). I am reasonably sure that\nthere still are features and workflows that Cogito supports\nbetter, and given time and motivated users and contributors,\nhopefully they will be ported to the core Porcelain.\n\nI would thank you for your effort to ease adoption of git family\nof tools to new people with Cogito; I would ask the list to do\nthe same.\n\nAnd I look forward to see your continued involvement to make git\nbetter.\n"},{"id":"39919","messageId":"Pine.LNX.4.64.0704192241230.8822@racer.site","threadId":"7712","inReplyTo":"7vzm545d0o.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Cogito is for sale","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T20:42:49Z","receivedAt":"2007-04-19T20:42:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\n\nOn Thu, 19 Apr 2007, Junio C Hamano wrote:\n\n> I would thank you for your effort to ease adoption of git family of \n> tools to new people with Cogito; I would ask the list to do the same.\n\nDefinitely. Thanks, Pasky. A lot of the user-friendliness we have in Git \nnow, as opposed to, say, June 2005, is because of cogito. It was sort of a \n\"next\" for ui enhancements, and it is sort of sad that this is gone now.\n\nCiao,\nDscho\n"},{"id":"39920","messageId":"Pine.LNX.4.64.0704192244360.8822@racer.site","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704190940330.9964@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T20:49:15Z","receivedAt":"2007-04-19T20:49:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Apr 2007, Linus Torvalds wrote:\n\n> On Thu, 19 Apr 2007, Johannes Schindelin wrote:\n> \n> You can't *not* mention branches, simply because even people who only \n> track other peoples work do end up often needing to know about it, or at \n> least hearing about them..\n\nWell, there is the classical case of an upstream which never merges from \nyou, John R. Developer. You have two branches, upstream and local. But Jim \nR. Developer did not work with Git before, just CVS. To Jim, these are not \ntwo branches. Still, Git operations are easy, and Jim does not have to \nunderstand branches to track upstream (keeping local changes).\n\nThat is a very valid use scenario, at least from my point of view, since I \nuse it quite often.\n\nAs an example, for me, \"next\" is upstream, and I keep some changes local, \neither because Junio refused to merge them, or because they are useful to \nnobody except me.\n\nOf course, these _are_ two branches, but I don't have to realize that when \nworking with Git in that manner.\n\nCiao,\nDscho\n"},{"id":"39921","messageId":"alpine.LFD.0.98.0704191341370.9964@woody.linux-foundation.org","threadId":"7712","inReplyTo":"4627ABBB.8060709@softax.com.pl","subject":"Re: GIT vs Other: Need argument","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-19T20:57:35Z","receivedAt":"2007-04-19T20:57:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Apr 2007, Marcin Kasperski wrote:\n> > \n> > I agree. And to some degree I suspect that the documentation pushes some of\n> > the advanced things a bit *too* eagerly. (...)\n>\n> As I am among those, who think that git *is* complicated, I decided to \n> sit down, and find out why exactly I think so. Here are the top \n> words/options/concepts, which I faced almost immediately while trying \n> GIT, and which I find confusing:\n> \n> rebase\n> index\n> revtree\n> reset\n> ref / refs\n> rev-list\n> rev-parse\n\nYes. I think it might be a good idea to write some kind of tutorial aimed \nfor two very simple cases. Because there are really two cases that stand \nout as being (a) common and (b) something you start out with!\n\n - Case #1 would be using git basically as a \"anonymous CVS\" replacement \n to track somebody others project.\n\n None of the above are ever really needed for that case, and I think all \n you really want to learn is:\n\n\tgit clone\n\tgit pull\n\n\tgitk\n\tgit log HEAD@{2.days.ago}..\n\tgitk HEAD@{1}.. some-file-or-directory\n\n and not a whole lot more (maybe pointing them at gitweb repos and \n telling them what the thing can do). In other words, you want to teach \n people to just fetch the repo, and perhaps how to see what has changed \n lately.\n\n In an advanced section for this usage case might be things like\n\n\tgit bisect\n\n to teach people who track other peoples repository how to help those \n other people find bugs when something goes wrong. But that would \n literally be an \"advanced topic\".\n\n - Case #2 is the \"how to start tracking your own project\".\n\n In some ways, it's even *more* trivial, becuase if you start a new \n project, you usually start from scratch (or perhaps from some CVS \n import), with just one branch, and your first worry is not even how to \n export it yet, but how to just *use* it for development.\n\n So for case #2, we'd never even mention \"git clone/pull\" or branches, \n but instead we'd just talk about\n\n\tgit init\t(and \"git cvsimport\" or something)\n\tgit add/rm/commit\n\tgit diff/show\n\tgit reset\n\tgit checkout\n\n and walk through an everyday problem set of just some _very_ basic \n situations. Explain the whole \"content\" thing, so that people \n understand why \"git add \" + \"git diff\" doesn't actually show \n the filename at all, and what the difference between \"git diff\" and \n \"git diff HEAD\" is.\n\nThose two usage cases actually cover a lot of trivial CVS usage already. A \nlot of people probably don't need to learn about branches AT ALL, or \nabout concurrent development, or anything like that. \n\nAnd the good news is that once you are very comfy with the two trivial \ncases, it's much easier to *later* explain how those two can actually be \ncombined. In other words, there's probably not any reason at all to even \nstart to talk about merging and branches until people are actually ready \nfor it, and start asking you \"so what happens if I've made changes and \nwant to update to the most recent version\". \n\nSimilarly, you generally don't want to actually start serving your \nprojects to others until long after you've started using the thing for \ndevelopment, so early on, it's probably perfectly fine to tell people: \ndon't worry about setting up a server or gitweb, just be happy in the \nknowledge that it *can* be done, and has been done for big projects, so \nwhen you actually want to do that, you can do all these fancy things, but \nyou shouldn't worry about it _yet_.\n\n\t\t\tLinus\n"},{"id":"39922","messageId":"Pine.LNX.4.64.0704192257520.8822@racer.site","threadId":"7712","inReplyTo":"4627BCF0.3000004@midwinter.com","subject":"Re: GIT vs Other: Need argument","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-19T21:00:49Z","receivedAt":"2007-04-19T21:00:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Apr 2007, Steven Grimm wrote:\n\n> Johannes Schindelin wrote:\n>\n> > Let me pick up the ball here. Once you did your share of conflicting \n> > merges, you _will_ realize how much better it is to merge when you are \n> > at a relatively stable state, i.e. you can test things (if only to \n> > make sure that the merge did not introduce strange side effects). And \n> > guess what, at such a stage I would commit anyway.\n> \n> That's a great workflow if you're working on relatively discrete, \n> standalone changes. A lot of the time, when I'm working on an isolated \n> change, I do just that, and I merge when I'm stable just like you \n> describe. That's probably the vastly most common mode of operation for \n> distributed open-source projects, which obviously were git's initial \n> target audience.\n\nIt is also possible (and I do that) when merging often. I use cherry-pick \nfor that. At a later stage, I merge, and this mostly succeeds, since the \nmerge is really a 3-way merge (with the obvious results).\n\n> And out of curiosity, are you using git for distributed, relatively \n> autonomous development, or for collaboration with a high level of \n> interdependency between developers?\n\nI use Git virtually everywhere it can be used:\n\n- backups\n- personal projects\n- configuration files\n- documents\n- collaboration with other people\n- tracking CVS\n- ...\n\nCiao,\nDscho\n"},{"id":"39924","messageId":"7vd52054e3.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"4627B292.6080202@midwinter.com","subject":"Re: GIT vs Other: Need argument","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-19T23:30:12Z","receivedAt":"2007-04-19T23:30:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> I wonder if it makes sense to automate that even more and make git\n> pull behave a bit statefully like rebase does:\n\nMaking things stateful may help, but when done without thinking\nthe consequence through, it would make things more confusing.\n\nBy the way, I never liked the way 'git rebase --continue' works.\n\nDon't get me wrong. I think it *was* a vast improvement.\nBefore 'git rebase --continue' was introduced, you needed to\nknow the implementation detail of 'git rebase' well enough to\nknow that you have to say 'git am --resolved' after resolving\nthe conflicts. Compared to that, being able to tell rebase to\n\"continue\" is much nicer.\n\nBut in practice, after 'git rebase' stops on a conflicting\nmerge, I spend many braincycles to come up with a sensible merge\nand then many CPU cycles to run test, and by the time I do the\nfinal \"git diff\" to make sure everything look right and\n\"update-index\" them, I often end up getting confused and find me\nasking this question: what was I doing? Was I resolving the\nmerge because I merged, or was I in the middle of a rebase, or\nwas I applying from a mailbox?\n\nI do not know what would happen if I say \"git commit\" at that\npoint, but I suspect it would be unpleasant, so I have never\ntried it myself. But it takes nontrivial amount of effort to\nconvince myself that 'git rebase --continue' is what I want to\ndo next, not 'git commit' nor 'git am --resolved'.\n\nAnd I suspect the reason this is confusing to me is not that\nrebase keeps state but that the state is not made more obvious\nto prevent mistakes from happening. Earlier I mentioned perhaps\nwe would want \"git, whatnow?\" command to remind people what they\nwere in the middle of and suggest what the next step would be.\nOr perhaps \"git, continue\" command that makes the obvious next\nstep to happen would be helpful.\n\nI am very much afraid that introducing more hidden state without\nsuch \"what now?\" framework in place would make things more\nconfusing and harder to use, not easier.\n\n> When git pull --continue does the commit, it *might* be nice for it to\n> do a variant of commit -a: if the user has modified all the\n> conflicting files, *and* not done an update-index on any of them\n> manually, then do the update-index implicitly. (That \"and\" part would\n> be to prevent it from tripping up experienced git users who want to\n> manually mark the conflicting files as resolved by running\n> update-index.) I'm not sure that's actually a good idea, though it'd\n> save some commands most of the time; the danger, of course, is that\n> you could end up committing a half-resolved file by accident. But then\n> I guess there's nothing preventing you from doing that with\n> update-index today.\n\nRunning update-index by hand is a conscious act on the part of\nthe user. You cannot compare it with silently doing the\nequivanent without telling the user and screwing up.\n"},{"id":"39940","messageId":"20070420053259.GA29069@spearce.org","threadId":"7712","inReplyTo":"7vd52054e3.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT vs Other: Need argument","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-04-20T05:32:59Z","receivedAt":"2007-04-20T05:32:59Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> And I suspect the reason this is confusing to me is not that\n> rebase keeps state but that the state is not made more obvious\n> to prevent mistakes from happening. Earlier I mentioned perhaps\n> we would want \"git, whatnow?\" command to remind people what they\n> were in the middle of and suggest what the next step would be.\n> Or perhaps \"git, continue\" command that makes the obvious next\n> step to happen would be helpful.\n\nYou use bash, right? What about teaching your PS1 how to show\nyou if you are in the middle of a rebase? Doesn't it show you\nthe current branch already? ;-)\n\n-- \nShawn.\n"},{"id":"39942","messageId":"20070420062254.GB29069@spearce.org","threadId":"7712","inReplyTo":"1176983993.30690.13.camel@cauchy.softax.local","subject":"Re: GIT vs Other: Need argument","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-04-20T06:22:54Z","receivedAt":"2007-04-20T06:22:54Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Marcin Kasperski wrote:\n> > As for permissions, well Shawn has often spoken of his hook scripts that \n> > implement very strong permissions (and he has done so again in this \n> > thread).\n\nI just posted it as a contrib patch. Maybe Junio will be willing\nto carry it around in his tree. If not, gmane now has it. :-)\n \n> I am not quite sure how can you forbid johny to see the code\n> in ./secret, while johny must checkout whole repo...\n> \n> Permissions are not only about writing.\n\nIndeed. But subsetting a repository by path like that is ugly\nin any DVCS. Which is why most don't do it. Probably better\nto subset by repository, aka the subproject support.\n\nBecause odds are that if you are hiding a directory (johny cannot see\n./secret) then you probably also need to hide all commit messages of\nall commits that affected ./secret too. And if those commits were to\nalso modify stuff in ./public, then that starts to get really iffy.\nBetter to just make a very clear distinction at the repository level.\n \n> > Depends what you want - I installed cygwin \n> \n> This is really not an option for typical windows user. Believe me.\n> Maybe it could be, if cygwin managed to create normal setup program\n> one day...\n\nYea. I've had a number of Git users get burned by the\ngit-merge-recursive script changing to git-merge-recursive.exe,\nand Cygwin's installer left git-merge-recursive in the directory\nwhen upgrading, but deleted some of the supporting Python modules.\nSo they were unable to execute a merge.\n\nBetter, one user succeeded in doing a `git merge -s ours foo`,\ncompletely tossing away the work of 20+ users over 3 months,\nbecause their HEAD was very old and their merge-recursive was\nutterly broken... They did not mean to do an ours style merge, it\njust happened that merge-recursive didn't do squat... because it\nwas the old Python version, partially installed...\n\nI found out about the breakage only after those 20+ users managed\nto cram another 80 or so commits onto the top of that bad merge.\nWhich meant that I couldn't just rewind the tree to redo the merge.\nI actually had to redo the merge as a new commit ontop of the bad\nhistory. Without losing any of the new changes. Ick.\n\nThankfully just the week before I taught merge-recursive how to\ntake trees (and not commits), allowing me to use it to carry the\nchanges through whilest ignoring the bad merge base history.\n\nSo anyway, my Git-on-Cygwin installer is now:\n\n\t...on the master system...\n\tmake clean &&\n\tmake prefix=/usr/local/git &&\n\trm -rf /usr/local/git &&\n\tmake install prefix=/usr/local/git &&\n\ttar jcf update-git.tar.bz2 /usr/local/git\n\n\t...and on other systems...\n\tcd / &&\n\trm -rf /usr/local/git &&\n\ttar jxf update-git.tar.bz2\n\nbecause dammit, that works, all of the time. Unlike Cygwin's\nsetup.exe.\n\n-- \nShawn.\n"},{"id":"39950","messageId":"7vzm531ly3.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"4627B292.6080202@midwinter.com","subject":"Re: GIT vs Other: Need argument","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-20T08:36:52Z","receivedAt":"2007-04-20T08:36:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> When git pull --continue does the commit, it *might* be nice for it to\n> do a variant of commit -a: if the user has modified all the\n> conflicting files, *and* not done an update-index on any of them\n> manually,...\n\nHow do you propose to detect that? We do not record the\nconflicted semi-merged state we leave the user to sort out\nanywhere else, and I do not think we would want to stash away a\nhidden duplicates of all unmerged files somewhere only for this\napplication. That feels too wasteful and messy. You also need\nto worry about how to garbage collect such copies if you go that\nroute.\n\n-- >8 --\nBy the way, I've been wondering if giving \"git add\" an ability\nto do \"git commit -a\" without actual committing.\n\n\t$ edit edit edit\n $ git add -u\n\nwould run \"git add\" for all modified (and deleted) files.\n\nI picked \"-u\" instead of \"-a\" because I wanted to stress that\nthis is about \"updating\" (which has connotation that it is\nrelative to something, and in this case it is relative to the\ncurrent \"index\"), and not about \"all\", which \"-a\" would imply.\n\nHmm?\n\n builtin-add.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-\n 1 files changed, 57 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-add.c b/builtin-add.c\nindex 9ec2925..5e6748f 100644\n--- a/builtin-add.c\n+++ b/builtin-add.c\n@@ -8,10 +8,15 @@\n #include \"dir.h\"\n #include \"exec_cmd.h\"\n #include \"cache-tree.h\"\n+#include \"diff.h\"\n+#include \"diffcore.h\"\n+#include \"commit.h\"\n+#include \"revision.h\"\n \n static const char builtin_add_usage[] =\n-\"git-add [-n] [-v] [-f] [--interactive | -i] [--] ...\";\n+\"git-add [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\";\n \n+static int take_all_worktree_changes;\n static const char *excludes_file;\n \n static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)\n@@ -92,6 +97,44 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)\n \t\tprune_directory(dir, pathspec, baselen);\n }\n \n+static void update_callback(struct diff_queue_struct *q,\n+\t\t\t struct diff_options *opt, void *cbdata)\n+{\n+\tint i, verbose;\n+\n+\tverbose = *((int *)cbdata);\n+\tfor (i = 0; i < q->nr; i++) {\n+\t\tstruct diff_filepair *p = q->queue[i];\n+\t\tconst char *path = p->one->path;\n+\t\tswitch (p->status) {\n+\t\tdefault:\n+\t\t\tdie(\"unexpacted diff status %c\", p->status);\n+\t\tcase DIFF_STATUS_UNMERGED:\n+\t\tcase DIFF_STATUS_MODIFIED:\n+\t\t\tadd_file_to_cache(path, verbose);\n+\t\t\tbreak;\n+\t\tcase DIFF_STATUS_DELETED:\n+\t\t\tremove_file_from_cache(path);\n+\t\t\tif (verbose)\n+\t\t\t\tprintf(\"remove '%s'\\n\", path);\n+\t\t\tbreak;\n+\t\t}\n+\t}\n+}\n+\n+static void update_all(int verbose)\n+{\n+\tstruct rev_info rev;\n+\tinit_revisions(&rev, \"\");\n+\tsetup_revisions(0, NULL, &rev, NULL);\n+\trev.diffopt.output_format = DIFF_FORMAT_CALLBACK;\n+\trev.diffopt.format_callback = update_callback;\n+\trev.diffopt.format_callback_data = &verbose;\n+\tif (read_cache() < 0)\n+\t\tdie(\"index file corrupt\");\n+\trun_diff_files(&rev, 0);\n+}\n+\n static int git_add_config(const char *var, const char *value)\n {\n \tif (!strcmp(var, \"core.excludesfile\")) {\n@@ -156,8 +199,20 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\t\tverbose = 1;\n \t\t\tcontinue;\n \t\t}\n+\t\tif (!strcmp(arg, \"-u\")) {\n+\t\t\ttake_all_worktree_changes = 1;\n+\t\t\tcontinue;\n+\t\t}\n \t\tusage(builtin_add_usage);\n \t}\n+\n+\tif (take_all_worktree_changes) {\n+\t\tif (i < argc)\n+\t\t\tdie(\"-u and explicit paths are incompatible\");\n+\t\tupdate_all(verbose);\n+\t\tgoto finish;\n+\t}\n+\n \tif (argc <= i) {\n \t\tfprintf(stderr, \"Nothing specified, nothing added.\\n\");\n \t\tfprintf(stderr, \"Maybe you wanted to say 'git add .'?\\n\");\n@@ -207,6 +262,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \tfor (i = 0; i < dir.nr; i++)\n \t\tadd_file_to_cache(dir.entries[i]->name, verbose);\n \n+ finish:\n \tif (active_cache_changed) {\n \t\tif (write_cache(newfd, active_cache, active_nr) ||\n \t\t close(newfd) || commit_locked_index(&lock_file))\n"},{"id":"39954","messageId":"vpqmz13xvqg.fsf@bauges.imag.fr","threadId":"7712","inReplyTo":"20070419184420.GM4489@pasky.or.cz","subject":"Re: GIT vs Other: Need argument","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-04-20T09:04:23Z","receivedAt":"2007-04-20T09:04:23Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Petr Baudis writes:\n\n> I have added the tutorial to the crash course section, but it should\n> somehow integrated to the website...\n\nWhile you're there, the homepage still points to 1.5.1 while 1.5.1.1\nis the latest.\n\n-- \nMatthieu\n"},{"id":"39961","messageId":"200704201104.35539.jnareb@gmail.com","threadId":"7712","inReplyTo":"7vd52054e3.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT vs Other: Need argument","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-04-20T09:04:34Z","receivedAt":"2007-04-20T09:04:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Steven Grimm writes:\n> \n>> I wonder if it makes sense to automate that even more and make git\n>> pull behave a bit statefully like rebase does:\n> \n> Making things stateful may help, but when done without thinking\n> the consequence through, it would make things more confusing.\n> \n> By the way, I never liked the way 'git rebase --continue' works.\n[...]\n> in practice, after 'git rebase' stops on a conflicting\n> merge, I spend many braincycles to come up with a sensible merge\n> and then many CPU cycles to run test, and by the time I do the\n> final \"git diff\" to make sure everything look right and\n> \"update-index\" them, I often end up getting confused and find me\n> asking this question: what was I doing? Was I resolving the\n> merge because I merged, or was I in the middle of a rebase, or\n> was I applying from a mailbox?\n> \n> I do not know what would happen if I say \"git commit\" at that\n> point, but I suspect it would be unpleasant, so I have never\n> tried it myself. But it takes nontrivial amount of effort to\n> convince myself that 'git rebase --continue' is what I want to\n> do next, not 'git commit' nor 'git am --resolved'.\n> \n> And I suspect the reason this is confusing to me is not that\n> rebase keeps state but that the state is not made more obvious\n> to prevent mistakes from happening. Earlier I mentioned perhaps\n> we would want \"git, whatnow?\" command to remind people what they\n> were in the middle of and suggest what the next step would be.\n> Or perhaps \"git, continue\" command that makes the obvious next\n> step to happen would be helpful.\n\nYou have even implemented \"git explain\" command, but it didn't get\ninto git. Perhaps it is time to resurrect it.\n \n> I am very much afraid that introducing more hidden state without\n> such \"what now?\" framework in place would make things more\n> confusing and harder to use, not easier.\n\nIt would be nice to have such \"git explain\" command, both for use\nin scripts (and perhaps also in builtins), and for the user (perhaps\n\"git status\" should use it, too). \n\nAnd it could be used to implement \"git continue\" and \"git abort\" \ncommands... (or \"git, continue\" and \"git, abort\" ;-).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"39956","messageId":"20070420101801.GA13560@diana.vm.bytemark.co.uk","threadId":"7712","inReplyTo":"7vd52054e3.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT vs Other: Need argument","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-04-20T10:18:01Z","receivedAt":"2007-04-20T10:18:01Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-04-19 16:30:12 -0700, Junio C Hamano wrote:\n\n> But in practice, after 'git rebase' stops on a conflicting merge, I\n> spend many braincycles to come up with a sensible merge and then\n> many CPU cycles to run test, and by the time I do the final \"git\n> diff\" to make sure everything look right and \"update-index\" them, I\n> often end up getting confused and find me asking this question: what\n> was I doing? Was I resolving the merge because I merged, or was I in\n> the middle of a rebase, or was I applying from a mailbox?\n\nThis is the main selling point of StGIT, in my opinion. It keeps track\nof stuff for you when you rebase, so you won't accidentally forget\nthings. The extra help isn't needed much when everything goes\nsmoothly, but as soon as you get a conflict or three in the middle of\nrebasing a largish stack, it's invaluable to just be able to say \"stg\nseries\" to see which patches have been applied to HEAD, and which are\nstill floating in limbo.\n\nThe usability increase is very palpable; without it, I wouldn't even\nattempt many of the rebasings I do, even though they are technically\nperfectly possible to do with just git.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"39958","messageId":"7vr6qf1g9c.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"20070420101801.GA13560@diana.vm.bytemark.co.uk","subject":"Re: GIT vs Other: Need argument","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-20T10:39:43Z","receivedAt":"2007-04-20T10:39:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karl Hasselström writes:\n\n> This is the main selling point of StGIT, in my opinion. It keeps track\n> of stuff for you when you rebase, so you won't accidentally forget\n> things. The extra help isn't needed much when everything goes\n> smoothly, but as soon as you get a conflict or three in the middle of\n> rebasing a largish stack, it's invaluable to just be able to say \"stg\n> series\" to see which patches have been applied to HEAD, and which are\n> still floating in limbo.\n\nI do not think we are talking about the same thing. In your\nexample, you perfectly well remember that you were in the middle\nof StGIT operation. The problem I described is that sometimes I\ndo not even recall if I was rebasing or merging after resolving\nconflicts. If I *knew* I was in the middle of a rebase, I know\nwhere to look (.dotest/ has all the necessary \"state\" for\nrebase/am to continue) to remind me where I was.\n"},{"id":"39977","messageId":"4628BA1B.30802@byu.net","threadId":"7712","inReplyTo":"20070420062254.GB29069@spearce.org","subject":"Re: GIT vs Other: Need argument","fromName":"Eric Blake","fromEmail":"ebb9@byu.net","sentAt":"2007-04-20T13:03:23Z","receivedAt":"2007-04-20T13:03:23Z","isPatch":false,"sender":{"key":"eblake@redhat.com","avatar":"https://avatars.githubusercontent.com/u/32933908?v=4"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAccording to Shawn O. Pearce on 4/20/2007 12:22 AM:\n>> Maybe it could be, if cygwin managed to create normal setup program\n>> one day...\n> \n> Yea. I've had a number of Git users get burned by the\n> git-merge-recursive script changing to git-merge-recursive.exe,\n> and Cygwin's installer left git-merge-recursive in the directory\n> when upgrading, but deleted some of the supporting Python modules.\n> So they were unable to execute a merge.\n\nPlease report these sorts of bugs to the cygwin list, so that the cygwin\nteam can be aware of them and work towards fixing them.\n\n> \n> Better, one user succeeded in doing a `git merge -s ours foo`,\n> completely tossing away the work of 20+ users over 3 months,\n> because their HEAD was very old and their merge-recursive was\n> utterly broken... They did not mean to do an ours style merge, it\n> just happened that merge-recursive didn't do squat... because it\n> was the old Python version, partially installed...\n> \n> I found out about the breakage only after those 20+ users managed\n> to cram another 80 or so commits onto the top of that bad merge.\n> Which meant that I couldn't just rewind the tree to redo the merge.\n> I actually had to redo the merge as a new commit ontop of the bad\n> history. Without losing any of the new changes. Ick.\n> \n> Thankfully just the week before I taught merge-recursive how to\n> take trees (and not commits), allowing me to use it to carry the\n> changes through whilest ignoring the bad merge base history.\n> \n> So anyway, my Git-on-Cygwin installer is now:\n> \n> \t...on the master system...\n> \tmake clean &&\n> \tmake prefix=/usr/local/git &&\n> \trm -rf /usr/local/git &&\n> \tmake install prefix=/usr/local/git &&\n> \ttar jcf update-git.tar.bz2 /usr/local/git\n> \n> \t...and on other systems...\n> \tcd / &&\n> \trm -rf /usr/local/git &&\n> \ttar jxf update-git.tar.bz2\n> \n> because dammit, that works, all of the time. Unlike Cygwin's\n> setup.exe.\n> \n\n- --\nDon't work too hard, make some time for fun as well!\n\nEric Blake ebb9@byu.net\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.5 (Cygwin)\nComment: Public key at home.comcast.net/~ericblake/eblake.gpg\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFGKLoa84KuGfSFAYARAlVwAKCL++zyeKO5iomF/gUQuRP6+N5qkgCfZpHa\n3OrAwLmpJ4IbFpUiuj27jRw=\n=Dyjw\n-----END PGP SIGNATURE-----\n"},{"id":"39981","messageId":"20070420135712.GN4489@pasky.or.cz","threadId":"7712","inReplyTo":"7vr6qf1g9c.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT vs Other: Need argument","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-04-20T13:57:12Z","receivedAt":"2007-04-20T13:57:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Apr 20, 2007 at 12:39:43PM CEST, Junio C Hamano wrote:\n> The problem I described is that sometimes I\n> do not even recall if I was rebasing or merging after resolving\n> conflicts. If I *knew* I was in the middle of a rebase, I know\n> where to look (.dotest/ has all the necessary \"state\" for\n> rebase/am to continue) to remind me where I was.\n\nIn Cogito, cg-status always tell you that you're in the middle of\nsomething special if you are. Perhaps git status could let you know as\nwell. (It wouldn't be as easy to see since git status seems so verbose\nthough compared to cg-status; that has been one of my pet peeves, though\nI suppose it's unlikely to change. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"39991","messageId":"20070420155446.GA11506@delft.aura.cs.cmu.edu","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704190940330.9964@woody.linux-foundation.org","subject":"History cleanup/rewriting script for git","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2007-04-20T15:54:46Z","receivedAt":"2007-04-20T15:54:46Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:\n> On Thu, 19 Apr 2007, Johannes Schindelin wrote:\n> > Hmm. However, I have to say that cogito serves/d another purpose quite \n> > well: Look at what came from cogito into git. Loads of useful \n> > enhancements. So, I really have to point to \"at this stage\", because that \n> > sure was not true 18 months ago.\n> \n> Absolutely. I think there are still some pieces of cogito that we might \n> want to migrate into git too, although they're fairly esoteric (ie the \n> whole history rewriting thing). And I think we still have some places \n\nI actually have a fairly simple history rewriting script (written in python)\nthat I used when I converted some CVS archives to git. It is really intended\nfor such an initial import and history cleanup case so it doesn't deal with\nreflogs and such.\n\nBasic workflow I used is,\n\n- Import CVS archive into a git repository\n- Use gitk + the grafts file to clean up history as much as feasible\n- Run git-rewrite-history.py which will\n - write out new commit objects with the corrected set of parents\n - copy existing refs to .git/newrefs, pointing them at the new commits.\n\n- start gitk --all to see the tree before the rewrite.\n- mv .git/refs .git/oldrefs ; mv .git/newrefs .git/refs\n- start a second gitk --all to see the tree after the rewrite.\n- compare gitk output to check if everything matches up.\n\n- run git repack/prune/gc to get rid of the old commits, or clone the repo.\n\nJan\n\n--8<-----------------------------------------------------------------------\n\n#!/usr/bin/python\n\nimport os, sys\n\ndef git_write_object(type, blob):\n stdin, stdout = os.popen2(\"git-hash-object -t %s -w --stdin\" % type)\n stdin.write(blob)\n stdin.close()\n return stdout.readline().strip()\n\ndef git_commits(branch):\n f = os.popen('git-rev-list --parents --header --topo-order %s' % branch)\n buf = ''\n while 1:\n\tbuf = buf + f.read(4096)\n\tif not buf: break\n\tif not '\\0' in buf: continue\n\tcommit, buf = buf.split('\\0', 1)\n\tyield Commit(commit)\n\ndef git_update_ref(name, hash):\n os.system('git-update-ref \"%s\" \"%s\"' % (name, hash))\n\ngrafts = []\npending = []\nrewriteable = []\nremap = {}\ntodo = 0\nclass Commit:\n def __init__(self, commit):\n\tglobal grafts\n\tlines = commit.split('\\n')\n\tparts = lines.pop(0).split()\n\tself.hash, self.parents = parts[0], parts[1:]\n\n\tself.tree = lines.pop(0)\n\n\tparents = []\n\twhile lines[0][:7] == 'parent ':\n\t parents = parents + lines.pop(0).split()[1:]\n\n\tif parents != self.parents:\n\t grafts.append(self.hash)\n\n\tcommit = []\n\twhile 1:\n\t line = lines.pop(0)\n\t commit.append(line)\n\t if not line: break\n\n\tfor line in lines:\n\t commit.append(line[4:])\n\tself.commit = '\\n'.join(commit)\n\n\tself.wait = 0\n\tself.children = []\n\n def mark(self):\n\tglobal todo, pending\n\tself.wait = self.wait + 1\n\tif self.wait == 1:\n\t todo = todo + 1\n\t for child in self.children:\n\t\tpending.append(child.hash)\n\n def pick(self):\n\tglobal rewriteable\n\tself.wait = self.wait - 1\n\tif not self.wait:\n\t rewriteable.append(self)\n\n def fixup(self, old_hash, new_hash):\n\ti = self.parents.index(old_hash)\n\tself.parents[i] = new_hash\n\tself.pick()\n\n def rehash(self):\n\tglobal todo, remap\n\ttodo = todo - 1\n\n\tblob = self.tree + '\\n'\n\tfor parent in self.parents:\n\t blob = blob + 'parent %s\\n' % parent\n\tblob = blob + self.commit\n\n\tnew_hash = git_write_object('commit', blob)\n\tremap[self.hash] = new_hash\n\n\tfor child in self.children:\n\t child.fixup(self.hash, new_hash)\n\nprint \"Reading commits... \",\ncommits = {}\nfor commit in git_commits('--all'):\n commits[commit.hash] = commit\nprint \"read %d commits, found %d grafts\" % (len(commits), len(grafts))\n\nprint \"Setting up reverse linkage\"\nfor commit in commits.values():\n for parent in commit.parents:\n\tcommits[parent].children.append(commit)\n\nprint \"Propagating graft information... \",\n# first mark all commits that will have to be rewritten.\nfor commit in grafts:\n commits[commit].mark()\n\nfor commit in pending:\n commits[commit].mark()\n\n# pick those commits that do not depend on any earlier rewrites\nfor commit in grafts:\n commits[commit].pick()\nprint \"%d commits need to be rewritten\" % todo\n\nprint \"Rewriting commits... \"\nwhile rewriteable:\n print \"\\rrewriting %5d/%5d commits\" % (len(rewriteable), todo),\n rewriteable.pop().rehash()\nprint \"done...\"\n\nprint \"Rewriting refs...\"\nfor ref in os.popen('git-for-each-ref'):\n hash, type, name = ref.split()\n if type != 'commit': continue\n\n if remap.has_key(hash):\n\thash = remap[hash]\n\n # write updated refs to .git/newrefs\n git_update_ref('new' + name, hash)\n\nprint \"done...\"\n"},{"id":"39992","messageId":"4628ED6E.6060101@midwinter.com","threadId":"7712","inReplyTo":"7vzm531ly3.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT vs Other: Need argument","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-04-20T16:42:22Z","receivedAt":"2007-04-20T16:42:22Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> How do you propose to detect that? We do not record the\n> conflicted semi-merged state we leave the user to sort out\n> anywhere else, and I do not think we would want to stash away a\n> hidden duplicates of all unmerged files somewhere only for this\n> application. That feels too wasteful and messy. You also need\n> to worry about how to garbage collect such copies if you go that\n> route.\n> \n\nWe wouldn't need to store duplicates. Just the SHA1s of the semi-merged \nfiles would suffice. Actually, just the modification times would \nprobably suffice, but the hashes are cheap to compute and slightly more \nrobust. We could put those in a single file (the same place we'd record \nthe fact that the user is in the middle of a conflicted pull) which is \nremoved by --continue or --abort.\n\nAlternately, we could rerun the merge that produced the semi-merged \nfiles in the first place; presumably it will produce exactly the same \nresults it did the first time and we can compare that against the \nworking copy. But I like storing the hashes better since it's cheaper \nand less convoluted.\n\n> By the way, I've been wondering if giving \"git add\" an ability\n> to do \"git commit -a\" without actual committing.\n>\n> \t$ edit edit edit\n> $ git add -u\n>\n> would run \"git add\" for all modified (and deleted) files.\n> \n\nI'm not sure I'd ever use this, personally. Pretty much the only time I \nfind the \"add everything\" functionality useful is when I'm about to \ncommit, and commit -a covers that case fine. But other people might find \nit helpful.\n\n-Steve\n"},{"id":"39998","messageId":"Pine.LNX.4.64.0704202037140.8822@racer.site","threadId":"7712","inReplyTo":"20070420155446.GA11506@delft.aura.cs.cmu.edu","subject":"Re: History cleanup/rewriting script for git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-20T18:39:25Z","receivedAt":"2007-04-20T18:39:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Apr 2007, Jan Harkes wrote:\n\n> On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:\n> > On Thu, 19 Apr 2007, Johannes Schindelin wrote:\n> >\n> > > Hmm. However, I have to say that cogito serves/d another purpose \n> > > quite well: Look at what came from cogito into git. Loads of useful \n> > > enhancements. So, I really have to point to \"at this stage\", because \n> > > that sure was not true 18 months ago.\n> > \n> > Absolutely. I think there are still some pieces of cogito that we \n> > might want to migrate into git too, although they're fairly esoteric \n> > (ie the whole history rewriting thing). And I think we still have some \n> > places\n> \n> I actually have a fairly simple history rewriting script (written in \n> python) that I used when I converted some CVS archives to git.\n\nTelling by your description, cg-admin-rewrite-hist is more capable. And I \nthink it should not be too complicated to rewrite the cogito specific \nparts, what with the parts we added to Git with cogito as a model. And it \nis in Perl... which makes it more portable than Python in my part of the \nworld.\n\nCiao,\nDscho\n"},{"id":"39999","messageId":"20070420184423.GP4489@pasky.or.cz","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704202037140.8822@racer.site","subject":"Re: History cleanup/rewriting script for git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-04-20T18:44:23Z","receivedAt":"2007-04-20T18:44:23Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Apr 20, 2007 at 08:39:25PM CEST, Johannes Schindelin wrote:\n> Telling by your description, cg-admin-rewrite-hist is more capable. And I \n> think it should not be too complicated to rewrite the cogito specific \n> parts, what with the parts we added to Git with cogito as a model. And it \n> is in Perl... which makes it more portable than Python in my part of the \n> world.\n\nIt is in shell, actually. (Well, bash, but I think [[ is the only\nbashism in that one.) And it was specifically written to be as\nindependent of Cogito as possible, I think it uses only Cogito's cool\ncommandline parsing routines. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"40007","messageId":"20070420203622.GA31546@delft.aura.cs.cmu.edu","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704202037140.8822@racer.site","subject":"Re: History cleanup/rewriting script for git","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2007-04-20T20:36:22Z","receivedAt":"2007-04-20T20:36:22Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Fri, Apr 20, 2007 at 08:39:25PM +0200, Johannes Schindelin wrote:\n> On Fri, 20 Apr 2007, Jan Harkes wrote:\n> > On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:\n> > > On Thu, 19 Apr 2007, Johannes Schindelin wrote:\n> > >\n> > > > Hmm. However, I have to say that cogito serves/d another purpose \n> > > > quite well: Look at what came from cogito into git. Loads of useful \n> > > > enhancements. So, I really have to point to \"at this stage\", because \n> > > > that sure was not true 18 months ago.\n> > > \n> > > Absolutely. I think there are still some pieces of cogito that we \n> > > might want to migrate into git too, although they're fairly esoteric \n> > > (ie the whole history rewriting thing). And I think we still have some \n> > > places\n> > \n> > I actually have a fairly simple history rewriting script (written in \n> > python) that I used when I converted some CVS archives to git.\n> \n> Telling by your description, cg-admin-rewrite-hist is more capable. And I \n> think it should not be too complicated to rewrite the cogito specific \n> parts, what with the parts we added to Git with cogito as a model. And it \n> is in Perl... which makes it more portable than Python in my part of the \n> world.\n\nAs I wrote this a while ago, before reflogs and packed refs, and I only\nneeded it for the initial conversion, it only had to write out new\ncommit objects and retarget branch heads and simple tags. If\ncg-admin-rewrite-hist can do better and can be merged into git-core I\nwould say that is a win-win situation for everyone.\n\nSomething like this should be available to allow people to reconstruct\ntheir merge history or fix up empty 'file was added on branch foo'\ncommits that are left around after the initial import from another VCS.\n\nPersonally, I don't think it should ever be used for any published\nrepositories or branches. Most fixups before publishing can already be\ndone by rebasing or amending a commit, so this would only be useful for\nthat intial import where there are in fact a lot of scattered changes\nall over the place, or to reconstruct a merge that went bad. But really\nin that case, it is probably better to redo the merge correctly and\nrebase any commits that might have gone in after the bad merge.\n\nJan\n"},{"id":"40230","messageId":"877is29b1l.wl%cworth@cworth.org","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704191341370.9964@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-23T18:54:14Z","receivedAt":"2007-04-23T18:54:14Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 19 Apr 2007 13:57:35 -0700 (PDT), Linus Torvalds wrote:\n> - Case #1 would be using git basically as a \"anonymous CVS\" replacement\n> to track somebody others project.\n\nI'd extend this to also say \"tracking a specific branch\" in some\nproject.\n\nWhen I raised this recently, Junio suggested something like the\nfollowing:\n\n\tgit config --global branch.autosetupmerge true\t[*]\n\tgit clone \n\tgit checkout -b origin/\n\tgit pull\n\nI haven't gotten around to replying to that message yet, but the\nthrust of my reply would be that that does actually work, but it's not\neven close to the ease with which one can track the default branch as\nLinus described:\n\n> None of the above are ever really needed for that case, and I think all\n> you really want to learn is:\n>\n> \tgit clone\n> \tgit pull\n\nSo, currently, all non-default branches have a sort of second-class\nstatus from the point of view of users that just want to track\nthem.\n\nCompare this to svn, for example. Now, svn has an insanely broken\nmodel for what a branch actually is, while git's model is sane. But I\nthink that with svn the \"anonymously tracking a branch\" use case isn't\nany harder for any one branch compared to any other, (it's just a\nmatter of starting with the right URL). I'd love to see git achieve\nthe same thing.\n\n-Carl\n\n[*] Is the command I have above even correct? What Junio actually\nsuggested was:\n\n\t$ cat >>$HOME/.gitconfig <<\\EOF\n\t[branch]\n\t\tautosetupmerge\n\tEOF\n\nBut I can't find a way to use git-config create a block that looks\nlike that. I'm just guessing that \"autosetupmerge = true\" works\nequivalently, but I could be wildly wrong.\n"},{"id":"40234","messageId":"200704232152.58833.Josef.Weidendorfer@gmx.de","threadId":"7712","inReplyTo":"877is29b1l.wl%cworth@cworth.org","subject":"Re: GIT vs Other: Need argument","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-04-23T19:52:58Z","receivedAt":"2007-04-23T19:52:58Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 23 April 2007, Carl Worth wrote:\n> On Thu, 19 Apr 2007 13:57:35 -0700 (PDT), Linus Torvalds wrote:\n> > - Case #1 would be using git basically as a \"anonymous CVS\" replacement\n> > to track somebody others project.\n> \n> I'd extend this to also say \"tracking a specific branch\" in some\n> project.\n> \n> When I raised this recently, Junio suggested something like the\n> following:\n> \n> \tgit config --global branch.autosetupmerge true\t[*]\n> \tgit clone \n> \tgit checkout -b origin/\n> \tgit pull\n> \n> I haven't gotten around to replying to that message yet, but the\n> thrust of my reply would be that that does actually work, but it's not\n> even close to the ease with which one can track the default branch as\n> Linus described:\n\nThe commands above are not needed for pure tracking, but instead prepare\na local development branch for you to work on, and where you can pull\nupstream changes with \"git pull\".\nFor tracking a remote $branch, it should be enough to do\n\n git clone\n git fetch\n\nand you get the any (*) remote $branch as \"remotes/origin/$branch\".\n\nJosef\n\n\n(*) Perhaps the \"any\" is too much for wanting to track one branch only?\n\n> \n> > None of the above are ever really needed for that case, and I think all\n> > you really want to learn is:\n> >\n> > \tgit clone\n> > \tgit pull\n> \n> So, currently, all non-default branches have a sort of second-class\n> status from the point of view of users that just want to track\n> them.\n> \n> Compare this to svn, for example. Now, svn has an insanely broken\n> model for what a branch actually is, while git's model is sane. But I\n> think that with svn the \"anonymously tracking a branch\" use case isn't\n> any harder for any one branch compared to any other, (it's just a\n> matter of starting with the right URL). I'd love to see git achieve\n> the same thing.\n> \n> -Carl\n> \n> [*] Is the command I have above even correct? What Junio actually\n> suggested was:\n> \n> \t$ cat >>$HOME/.gitconfig <<\\EOF\n> \t[branch]\n> \t\tautosetupmerge\n> \tEOF\n> \n> But I can't find a way to use git-config create a block that looks\n> like that. I'm just guessing that \"autosetupmerge = true\" works\n> equivalently, but I could be wildly wrong.\n> \n"},{"id":"40247","messageId":"87zm4y7nbe.wl%cworth@cworth.org","threadId":"7712","inReplyTo":"200704232152.58833.Josef.Weidendorfer@gmx.de","subject":"Re: GIT vs Other: Need argument","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-23T22:12:05Z","receivedAt":"2007-04-23T22:12:05Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 23 Apr 2007 21:52:58 +0200,Josef Weidendorfer wrote:\n> The commands above are not needed for pure tracking, but instead prepare\n> a local development branch for you to work on, and where you can pull\n> upstream changes with \"git pull\".\n> For tracking a remote $branch, it should be enough to do\n>\n> git clone\n> git fetch\n>\n> and you get the any (*) remote $branch as \"remotes/origin/$branch\".\n\nBy \"tracking\" I mean the ability to get the working-tree state to\nmatch that of some remote-tracking branch and then be able to\nperiodically do some command, (\"git pull\"), to make the working-tree\nreflect the latest state of that remote branch.\n\nSo the fact that at any given point I can say:\n\n\tgit checkout origin/\n\nand get into a detached-HEAD where the working-tree matches what I\nlast fetched, doesn't quite do the job. From there, there's nothing\nlike \"git pull\" to usefully bring the working-tree state up to the\nlatest. Issuing \"git pull\" from the detached HEAD state does fetch,\nbut then complains:\n\n\tYou are not currently on a branch; you must explicitly\n\tspecify which branch you wish to merge:\n\t git pull \n\nSo, no, the current git-clone alone does not get me to where I'd like\nto be.\n\n-Carl\n"},{"id":"40248","messageId":"7vps5ud91x.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"877is29b1l.wl%cworth@cworth.org","subject":"Re: GIT vs Other: Need argument","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-23T22:23:38Z","receivedAt":"2007-04-23T22:23:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> When I raised this recently, Junio suggested something like the\n> following:\n>\n> \tgit config --global branch.autosetupmerge true\t[*]\n> \tgit clone \n> \tgit checkout -b origin/\n> \tgit pull\n>\n> I haven't gotten around to replying to that message yet, but the\n> thrust of my reply would be that that does actually work, but it's not\n> even close to the ease with which one can track the default branch as\n> Linus described:\n>\n>> None of the above are ever really needed for that case, and I think all\n>> you really want to learn is:\n>>\n>> \tgit clone\n>> \tgit pull\n>\n> So, currently, all non-default branches have a sort of second-class\n> status from the point of view of users that just want to track\n> them.\n\nIt is true that non default ones are second class status.\nThat's why they are not \"default\" ;-).\n\nThe autosetup configuration needs to be done once for the user\n(not tied to any project), so you are talking about difference\nbetween:\n\n\tgit clone\n git pull\n git pull\n git pull\n git pull\n git pull\n\t...\n\nvs\n\n\tgit clone\n git checkout -b next origin/next\n git pull\n git pull\n git pull\n git pull\n git pull\n\t...\n\n'git clone' step in both are done only once per project's\nworking tree, 'git checkout -b' step is done once for the\nparticular branch you are interested in, and after that you will\ndoing 'git pull' every day or every minute. I do not think one\nextra step is a big enough deal to make second class citizens\nscream about inequality.\n"},{"id":"40254","messageId":"87vefm7l6g.wl%cworth@cworth.org","threadId":"7712","inReplyTo":"7vps5ud91x.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT vs Other: Need argument","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-23T22:58:15Z","receivedAt":"2007-04-23T22:58:15Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 23 Apr 2007 15:23:38 -0700, Junio C Hamano wrote:\n> It is true that non default ones are second class status.\n> That's why they are not \"default\" ;-).\n\nSure, but different users have different needs. I use the default\nbranch for where I want developers to base most new commits, (a\n\"development\" branch), but for some of these \"anonymous tracking only\"\nusers, a \"stable\" branch can be the only branch of interest. So I'd\nreally like to be able to publish branches on more equal footing.\n\n> The autosetup configuration needs to be done once for the user\n> (not tied to any project), so you are talking about difference\n> between:\n\nWell, it's not so simple to write off the autosetup configuration\nstep. Even if it only has to happen once, I still need to teach users\nhow to do it.\n\nAnd that's an extra step compared to any other SCM tool one might be\ninterested in comparing git too, (which is the original topic).\n\nSo the current git sequence to get to being able to do just \"git pull\"\nto track a specific branch is:\n\n\t# Something to setup autosetup (once per user account)\n\tgit clone \n\tgit checkout -b origin/\n\nI know that that's a single command in many other systems, and it\nseems a very useful case to target. Is there any argument against\nadding a single command that does exactly the above, (with the\nmodification that the autosetup thing could be done as local instead\nof global configuration). And with the recent talk about phasing\ncogito out and just merging its functionality into git itself, why not\njust use the cogito syntax for this:\n\n\tgit clone #\n\nAt that point, git would be supporting this use case as well as any\nother tool out there, (and git can still support things like tracking\n_multiple_ branches in better ways than other tools as it does\nalready).\n\n-Carl\n"},{"id":"40256","messageId":"7vd51ud6ba.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"877is29b1l.wl%cworth@cworth.org","subject":"Re: GIT vs Other: Need argument","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-23T23:22:49Z","receivedAt":"2007-04-23T23:22:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> So, currently, all non-default branches have a sort of second-class\n> status from the point of view of users that just want to track\n> them.\n\nFor some time when people compared hg and git they said git\nsupports multiple branches in repository more naturally. And\nusing more than one branch in a single repository, especially in\none with a working tree, is more convenient for certain things,\nsuch as comparing the branches (both \"diff A B\" and \"log A..B\").\n\nBut that does not necessarily mean we are forced to use as small\nnumber of repositories as possible and use branches to represent\nrelated work.\n\nIf for example all the kernel related repositories in kernel.org\nwere actually represented as a single repository with hundreds\nof branches, with default set to Linus's 'master', people who\nwould want to track subsystem maintainers' trees would feel less\nconvenient as they always have to first clone (perhaps with -n\nbecause they are not interested in a checkout of Linus's tree)\nand then 'checkout -b' for the subsystem branch of their choice.\n\nBut that is not how the kernel group organize the repositories\nfor their project. Each subsystem maintainer have his own tree\nor trees, and a repository can be about a topic or various\ndegree of doneness. So at that level, all repositories are\nequal and it is just a matter of picking the right URL to clone\nfrom.\n\nInstead of trying to make each branch the target of 'clone'\nintended for one class of audience as your message implies, you\ncould publish one repository (you might arrange them to share\nthe objects via alternates to reduce storage requirements, but\nthat is an implementation detail and invisible to your users)\nper an intended class of your audience. Your work, inside one\nrepository done on multiple branches, could be pushed into more\nthan one repositories, each of which has \"the default\" (and\npossibly \"only\") branch set to point at the theme of your branch\nin your local repository.\n\nI think something like this might even work out of the box. On\nthe public box you publish your branch A and B on, have three\nrepositories (i.e. number of branches plus one) like this:\n\n\n\tcw-master.git/\n cw-A.git/\n cw-B.git/\n\nEverything under cw-$X.git (for X in A B) are symlinks to the\ncorresponding place in cw-master.git/, except HEAD. Make\ncw-A.git/HEAD points at refs/heads/A while cw-B.git/HEAD points\nat refs/heads/B.\n\nAnd the maintainer (you) would push into cw-master.git/ and tell\npeople about cw-$X.git repositories but not necessarily about\ncw-master.git/ repository.\n\nDo not complain that the above is cumbersome to set up, not just\nyet. That is not my point. The point is that you are trying to\nsolve this from the consumer side, but I am wondering if this is\nactually a problem on the publisher side. And _if_ the problem\nis on the publishing side, git-clone on the client side to track\ndifferent branch is not the way to solve that problem. Rather,\ngit-clone (or maybe a new program git-publish-repository) to\nmake it easier to set up the publishing side might be what we\nneed.\n"},{"id":"40257","messageId":"alpine.LFD.0.98.0704231609440.9964@woody.linux-foundation.org","threadId":"7712","inReplyTo":"87vefm7l6g.wl%cworth@cworth.org","subject":"Re: GIT vs Other: Need argument","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-23T23:24:23Z","receivedAt":"2007-04-23T23:24:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Apr 2007, Carl Worth wrote:\n>\n> And with the recent talk about phasing cogito out and just merging its \n> functionality into git itself, why not just use the cogito syntax for \n> this:\n> \n> \tgit clone #\n\nThat's a fundamentally weaker operation than the current \"git clone\", so I \nreally don't think it's a good idea. The syntax also absolutely sucks, \nit's so horribly non-unixy.\n\nI'd personally be ok with a\n\n\tgit clone --default= \n\nto create something where \"master\" defaults to some other remote branch, \nbut that just addresses the syntax. And quite frankly, I don't think we \n*need* to. We shoud just tell people how _easy_ it is to track some other \nbranch now.\n\nSo I don't really see the problem with just saying:\n\n - the remote *has* a default branch. That's the one you get by default \n with \"git clone\".\n\n - if you want to track another branch, you should just tell git that you \n want to track it, and switch to that instead:\n\n\tgit branch --track mybranch origin/otherbranch\n\tgit checkout mybranch\n\n and be happy with it.\n\nYes, it's two extra commands, but they aren't *that* hard to explain, \nafter all. You really can basically explain each stage both very simply \nand naturally with just\n\n - first you clone the repository. This gets you all remote branches, and \n sets \"master\" to track the default remote branch.\n\n\tgit clone remote [local-dir]\n\n - then, you create a new branch that you want to track another of the \n branches in origin\n\n\tgit branch --track mybranch origin/otherbranch\n\n - then you check that branch out\n\n\tgit checkout mybranch\n\nand notice how each stage really was not only pretty logical, but even the \ncommand to do it didn't really look *that* strange: even without the \nexplanation of what the commands are doing, somebody reading just the pure \ncommands could probably _guess_ what they do!\n\nReally, all three stages are pretty simple, and they are not really that \nhard to explain. And it's not even like you do this very often - so this \nis the _perfect_ kind of thing to have on a \"git reference card\" kind of \nthing (think O'Reilly reference card series).\n\nSo I _really_ think that if we just had the \"this is how to use 'git' as a \nreplacement for 'anonymous CVS'-like usage\" documentation, you could \nexplain all of this very concisely, and with absolutely zero confusion \neven to a total non-git person. Give a few example command lines from real \nlife (eg, tracking the \"next\" branch from git itself), and make it easy to \nfind, and you're all done.\n\nThe advantage is that unlike that *idiotic* cogito syntax, you don't \nactually *lose* anything. If somebody says \"but I'd like to track *two* \nbranches\", the sequence is _exactly_ the same. There is no \"special magic\" \nat clone time.\n\nAnd the syntax is also much clearer. No magic and horribly non-unixy \nURL#branch syntax.\n\n\t\t\tLinus\n"},{"id":"40260","messageId":"655BF52F-9CD9-4C79-A6D0-5A3BDE9BE58F@silverinsanity.com","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704231609440.9964@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-04-23T23:55:42Z","receivedAt":"2007-04-23T23:55:42Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Apr 23, 2007, at 7:24 PM, Linus Torvalds wrote:\n\n> So I don't really see the problem with just saying:\n>\n> - the remote *has* a default branch. That's the one you get by \n> default\n> with \"git clone\".\n>\n> - if you want to track another branch, you should just tell git \n> that you\n> want to track it, and switch to that instead:\n>\n> \tgit branch --track mybranch origin/otherbranch\n> \tgit checkout mybranch\n>\n> and be happy with it.\n>\n> Yes, it's two extra commands, but they aren't *that* hard to explain,\n> after all. You really can basically explain each stage both very \n> simply\n> and naturally with just\n\nIt's even better than that. Just use \"git checkout --track -b \nmybranch origin/otherbranch\". Slightly cumbersome, but is only one \ncommand. And easily explained: \"Checkout a tracking branch named \nmybranch for origin/otherbranch\".\n\nAnd the --track can be removed by using branch.autosetupmerge for \npeople who always want it.\n\nActually the man page appears to be minorly incorrect. It has \"[-b \n[ --track | --no-track ]\", which doesn't work. Git gives me \"git \ncheckout: updating paths is incompatible with switching branches/ \nforcing\". I think it's interpreting --track as the new branch name. \nI'll send a patch reversing the order of the arguments in the man page.\n\n~~ Brian\n"},{"id":"40278","messageId":"Pine.LNX.4.64.0704232039300.28708@iabervon.org","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704231609440.9964@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-24T01:31:25Z","receivedAt":"2007-04-24T01:31:25Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 23 Apr 2007, Linus Torvalds wrote:\n\n> On Mon, 23 Apr 2007, Carl Worth wrote:\n> >\n> > And with the recent talk about phasing cogito out and just merging its \n> > functionality into git itself, why not just use the cogito syntax for \n> > this:\n> > \n> > \tgit clone #\n> \n> That's a fundamentally weaker operation than the current \"git clone\", so I \n> really don't think it's a good idea. The syntax also absolutely sucks, \n> it's so horribly non-unixy.\n> \n> I'd personally be ok with a\n> \n> \tgit clone --default= \n> \n> to create something where \"master\" defaults to some other remote branch, \n> but that just addresses the syntax. And quite frankly, I don't think we \n> *need* to. We shoud just tell people how _easy_ it is to track some other \n> branch now.\n\nI've converted all my coworkers to git recently, and it was helpful to be \nable to go two weeks without explaining branches, due to the fact that our \nrepositories only have one branch each (at least that people care about). \nIt was also nice that, when one of them did learn about branches, he had \nthe two weeks of experience with the absolute basics. I think that a first \ntime user should be able to get, from the clone command:\n\n[remote \"origin\"]\n\turl = ...\n\tfetch = +refs/heads/*:refs/remotes/origin/*\n[branch \"master\"]\n\tremote = origin\n\tmerge = refs/heads/\n\nif the first-time user's first repository for learning has the interesting \nstuff in a non-default branch. Now, a second-time user can learn about \nbranches, but I think that branches are confusing and scary if you don't \nalready have a bit of experience with the operations that affect a branch.\n\nObviously, if you want to track two branches in one repository, you need \nto know how to *have* additional local branches, but you can put off \nlearning that until you recognize the need for it, if there's any easy way \nto get your initial branch to track the remote branch you're interested \nin.\n\nSomeone can get work done with clone, add, commit -a, pull, and push (or \nformat-patch). Two commands and an additional fundamental concept is a lot \nof overhead at that stage.\n\nFor that matter, I sometimes want a repository where master tracks a \nbranch that isn't default for other people and \"mainline\" tracks the \nupstream master, which requires a small amount of config file editing, and \ncan't be made to just happen.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"40287","messageId":"7v1wiabbfr.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704231609440.9964@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-24T05:15:04Z","receivedAt":"2007-04-24T05:15:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I'd personally be ok with a\n>\n> \tgit clone --default= \n>\n> to create something where \"master\" defaults to some other remote branch, \n> but that just addresses the syntax. And quite frankly, I don't think we \n> *need* to. We should just tell people how _easy_ it is to track some other \n> branch now.\n\nI agree with this (and everything you said in your message).\nKeep the semantics the same, except that behave as if remote\nHEAD pointed at a different branch than what it really points\nat.\n\nIf Carl is also happy with the syntax, we can conclude this\ndiscussion and:\n\n (1) have that as an enhancement to git-clone;\n\n (2) add a how-to document or a section to the manual to teach\n people how to track one or more branches, based on the\n messages already posted on this thread.\n"},{"id":"40329","messageId":"20070424142309.GD18538@fieldses.org","threadId":"7712","inReplyTo":"7v1wiabbfr.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT vs Other: Need argument","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-04-24T14:23:09Z","receivedAt":"2007-04-24T14:23:09Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Apr 23, 2007 at 10:15:04PM -0700, Junio C Hamano wrote:\n> If Carl is also happy with the syntax, we can conclude this\n> discussion and:\n> \n> (1) have that as an enhancement to git-clone;\n> \n> (2) add a how-to document or a section to the manual to teach\n> people how to track one or more branches, based on the\n> messages already posted on this thread.\n\nNote that we almost have the tutorials for the \"two very simple cases\"\nthat Linus identifies:\n\n\t- case #1, the \"anonymous CVS\" replacement: chapter 2 of\n\t user-manual.txt (the first chapter after the quick start) covers\n\t this. Perhaps in greater generality than necessary, and maybe\n\t detached heads and/or --track should be mentioned earlier.\n\n\t- tutorial.txt, the \"how to start tracking your own project\"\n\t case, starts with git-init, git-add, etc.\n\nOne problem is that it's not immediately obvious which one to look at\nfor each case.\n\n--b.\n"},{"id":"40335","messageId":"alpine.LFD.0.98.0704240752030.9964@woody.linux-foundation.org","threadId":"7712","inReplyTo":"20070424142309.GD18538@fieldses.org","subject":"Re: GIT vs Other: Need argument","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-24T15:01:50Z","receivedAt":"2007-04-24T15:01:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 24 Apr 2007, J. Bruce Fields wrote:\n> \n> Note that we almost have the tutorials for the \"two very simple cases\"\n> that Linus identifies:\n> \n> \t- case #1, the \"anonymous CVS\" replacement: chapter 2 of\n> \t user-manual.txt (the first chapter after the quick start) covers\n> \t this. Perhaps in greater generality than necessary, and maybe\n> \t detached heads and/or --track should be mentioned earlier.\n> \n> \t- tutorial.txt, the \"how to start tracking your own project\"\n> \t case, starts with git-init, git-add, etc.\n> \n> One problem is that it's not immediately obvious which one to look at\n> for each case.\n\nWell, I think they really should be documents of their own, so that you \ncan read about the \"CVS tracking\" or so without even worrying about the \nfact that you didn't read the whole thing.\n\nAnd they should be easy to find. I agree that we do actually have a fair \namount of docs, but it seems that people don't tend to *find* them. The \nuser-manual, for example, is great, but I've seen people on the #git logs \napparently not realize it exists ;)\n\nFor example, the git homepage has a \"documentation\" thing, which only \nlists the tutorial, not the user manual explicitly. You _can_ get to the \nuser manual (go to the online version of the Documentation directory and \nnote the \"still work in progress\"), but even if you do actually find \nyourself there, the user manual itself is actually a bit scary to start \nwith.\n\nSo I think we could just make the initial impression a bit easier. The \ntutorial comes fairly close to the \"tracking your own\" thing, I agree, \nbut maybe we could have the documentation listed in order of complexity, \nand having a way for people to know *which* doc they should start with \nwhen they are at http://git.or.cz/ (or the wikipedia page), so that if \nyou're only interested in the \"tracking somebody else\", you could easily \nfind and read just a single simple documentation thing. Hmm?\n\n\t\t\tLinus\n"},{"id":"40390","messageId":"56b7f5510704250155j6870a4dand3726e5444fc5021@mail.gmail.com","threadId":"7712","inReplyTo":"20070417104520.GB4946@moonlight.home","subject":"Re: GIT vs Other: Need argument","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-04-25T08:55:39Z","receivedAt":"2007-04-25T08:55:39Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 4/17/07, Tomash Brechko wrote:\n> On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:\n> > So, in 15 seconds, how does one argue that GIT is vastly superior to\n> > other version control software, especially CVS.\n> ... You can't really\n> explain why 'git commit; git push' into some central repository is\n> better than 'cvs commit', and pushing after every commit is what\n> people will be doing at first ;).\nYes, your point here is very real --\nthis perception that git imposes an \"extra step\"\nis one thing I'm trying to avoid right now. I think I've almost succeeded...\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"40391","messageId":"56b7f5510704250158v5d80feb7gb82db0da2349eb8f@mail.gmail.com","threadId":"7712","inReplyTo":"81b0412b0704170739te4c35f0m8e4a3cd5bad440cd@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-04-25T08:58:05Z","receivedAt":"2007-04-25T08:58:05Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 4/17/07, Alex Riesen wrote:\n> On 4/17/07, Martin Langhoff wrote:\n> > - Old school SCMs allow you to branch, but are unable to keep track\n> > of merges in any meaningful way. Every time you merge, history is\n> > lost. GIT (and other DSCMs) have excellent branching _and_ merging\n> > facilities.\n> This one was a bad argument too. Curiously, and I cannot explain why,\n> ability to branch is considered a weakness of GIT (\"because it confuses\n> the integrators\", them being old mean men). The Perforce is said to\n> be \"vastly superior to everything\" on these grounds: \"it also has\n> branching support, but luckily(!) it is hard enough for simple\n> developers. Was not their (Perforce's) fault, they just included it\n> to keep up with the market\". Almost exact wording (I had to translate it).\n\nYou are also trying to gain traction in a Perforce environment?\nI'd be interested in any more details you might have;\nI'm just starting. Email me directly if you like.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"40394","messageId":"81b0412b0704250335h70dd7cf8l69bb302f0c5f1f92@mail.gmail.com","threadId":"7712","inReplyTo":"56b7f5510704250158v5d80feb7gb82db0da2349eb8f@mail.gmail.com","subject":"Re: GIT vs Other: Need argument","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-25T10:35:47Z","receivedAt":"2007-04-25T10:35:47Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/25/07, Dana How wrote:\n> On 4/17/07, Alex Riesen wrote:\n> > On 4/17/07, Martin Langhoff wrote:\n> > > - Old school SCMs allow you to branch, but are unable to keep track\n> > > of merges in any meaningful way. Every time you merge, history is\n> > > lost. GIT (and other DSCMs) have excellent branching _and_ merging\n> > > facilities.\n> > This one was a bad argument too. Curiously, and I cannot explain why,\n> > ability to branch is considered a weakness of GIT (\"because it confuses\n> > the integrators\", them being old mean men). The Perforce is said to\n> > be \"vastly superior to everything\" on these grounds: \"it also has\n> > branching support, but luckily(!) it is hard enough for simple\n> > developers. Was not their (Perforce's) fault, they just included it\n> > to keep up with the market\". Almost exact wording (I had to translate it).\n>\n> You are also trying to gain traction in a Perforce environment?\n> I'd be interested in any more details you might have;\n\nWell, as I have failed on every attempt get the idea through,\nI am not sure I _have_ any useful details which can be shared.\nRight at this moment I'm working on importing/exporting scripts\nwhich hopefully can impress my colleagues enough to use git\n(P4 is almost universally hated). The problem is complicated\nby the fact we have to use a homegrown program which replaces\n\"p4 sync\" (as it is somewhat handicapped in its ability to specify\nwhat revision of what part of a project to sync).\nAt the moment there 4 scripts: one to workaround the mentioned\ntool (unrelated to git), one to put the data into index (must use\nperforce to get the real names of the files, the local names\nconstantly get mangled by windows), one to commit the index\nalong with information about the clients state (mappings aka\nclient specification, revision lists and custom information this\ndumb tool of ours needs) and one to export git changes.\nAll this is very loosely connected and integrated, so I can use\nthem independent of each other. This also means that there\nis a lot of hand work to do, though. I can share the last three\nscripts, if anyone interested (the first is of no use to anyone,\nexcept me).\n"},{"id":"40400","messageId":"87mz0w7g3j.wl%cworth@cworth.org","threadId":"7712","inReplyTo":"7v1wiabbfr.fsf@assigned-by-dhcp.cox.net","subject":"Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-25T13:12:32Z","receivedAt":"2007-04-25T13:12:32Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 23 Apr 2007 22:15:04 -0700, Junio C Hamano wrote:\n> Linus Torvalds writes:\n>\n> > I'd personally be ok with a\n> >\n> > \tgit clone --default= \n...\n> If Carl is also happy with the syntax, we can conclude this\n> discussion and:\n>\n> (1) have that as an enhancement to git-clone;\n\nI think it's a useful enhancement. It would let me at least document\nsomething like \"tracking this project's stable branch\" with a single\ncommand, which I think is useful. But I don't know that I would be\ntotally happy yet. :-)\n\nSo please allow me to comment on the syntax a bit. Linus, you claimed\nthat # isn't \"unixy\" enough for your taste. What does\nthat mean exactly? Is it that two logically independent things are\ncrammed into a single argument instead of being passed as second\narguments? Or something else?\n\nHere's the reason I want both the URL and the branch to appear as a\nsingle string, (but I don't really care about the precise syntax). I\nreally want to be able to say \"see my branch at \" and have\nthat be a complete and self-contained description of the\nbranch that can be used in several different ways including:\n\n* Cloning a new repository to track that branch as the default\n\n* Begin tracking that branch as a new branch within an existing\n repository\n\n* Viewing that branch's history in a web browser.\n\nSo in my dream world I'd publish a single URL+branch string that could\nbe fed directly to \"git clone\", something like \"git track\", or to a web\nbrowser and the user would get exactly what was desired in all\ncases. (As for http:// vs. git:// in the URL, I hope someone could\nrecommend the right magic to make things efficient in my dream world.)\n\nSo that idea also addresses the problem that Linus had with adding\nsome special \"tracking\" feature that would only be available for a\nsingle branch and only at the time of clone. Of course that would be\nundesirable, and that's why I've been talking about something like\n\"git track\" to add the exact same functionality for tracking\nsubsequent branches after the clone.\n\nWhen I last mentioned \"git track\", Junio pointed out that the existing\n\"git remote add URL\" and \"git checkout --track -b \n/\"[*] is more powerful anyway. I totally agree that\nit's great to be able to add a remote like this, and to be able to\nthen use the alias to refer to the URL.\n\nBut the whole \"git remote add\" doesn't help and actually gets in the\nway in the use case I'm trying to address. The problem is that if the\nuser has already created a remote alias for the URL I'm advertising, I\ncan't take advantage of that in my instructions since I don't know\nwhat local name the user used for it.\n\nHere's the kind of email I'd like to be able to write in my dream\nworld:\n\n[1]\tI've just written some very fancy feature for our cool project\n\twhich you can see at and clone or track with\n\tgit. Please try it out and give me feedback.\n\nAnd from here, readers could paste into a web browser to see\nthe branch's history, (I'd also like some branch-specific description\nto appear), and also be presented with exact commands for cloning or\ntracking the branch with git, (\"git clone \" or \"git track\n\").\n\nEven if the user didn't view the URL I gave in a web browser, there's\nenough detail in my message to guess that \"git clone \" and\n\"git track \" would be useful commands. Or without guessing\nrequired, users would learn this after seeing the commands once or\ntwice in a web browser or whatever.\n\nSo in my dream world, a sentence like the above gives any user all the\ninformation they need to start using git to get at my code. And notice\nthat my text gets to focus on my features and my project which is what\nI care about in a message like this, and doesn't get bogged down in\nsharing details about how to use git.\n\nSo compare the current situation with my dream world. The closest I\ncan get know is something like:\n\n[2]\tI've just written some very fancy feature for our cool project\n\twhich you can see in gitweb at . To track this\n\tbranch, do \"git remote add cworth ; git checkout --track\n\t-b cworth/\" if you already have some clone of\n\tour project. Otherwise do \"git clone ; git checkout\n\t--track -b \". Please try it out and give me feedback.\n\nSo adding \"clone --default\" would help shorten the last command, but\nwouldn't really help simplify the rest of this stuff. And it's really\nall noise when what I want to be talking about is my code, not the\nsyntax of various git commands.\n\nNow, someone might complain that I'm setting up a strawman with a\nparagraph like that---that I'm throwing too much git talk into that\nparagraph and that something more realistic with current git would\nlook like this:\n\n[3]\tI've just written some very fancy feature for our cool project\n\twhich is available in the branch at . Please try\n\tit out and give me feedback.\n\nI agree that that paragraph is more like what people are actually\ndoing with git-based projects today. But this paragraph is definitely\nnot as functional as my dream-world paragraph. What I don't like about\nthis one is how much knowledge this assumes on the part of the\nuser. If the user wants to see things in gitweb, they'll have to know\nhow to construct a URL for that. If they want to start tracking the\nbranch in an existing clone, they'll have to know the \"remote add\" and\n\"checkout --track\" commands to do that.\n\nSome people do know all that stuff and keep it current in their\nheads. Some people will have done this before but will have to dig in\ntheir mental memory banks or re-check a git reference card before they\ncan get at the code. And plenty of people will have have never used\ngit at all so will have to go learn about it. Where to go to learn?\n\nThere are enough obstacles there that some of these people won't be\nsuccessful and will never end up looking at my code, (which is not\nwhat I want---I want as many people as possible to have an effortless\nexperience in getting at my code). And there are enough obstacles\nthere that even those who do make it through can easily get the\nimpression that \"git is hard\".\n\nThe only way I know to avoid those obstacles is to do like I did in\nparagraph [2] and at least give the user all the pointers they need so\nthat they don't need to look anything up. But there again, there's so\nmuch \"git speak\" that it still looks hard, and it definitely distracts\nfrom what I'm really wanting to talk about.\n\nThis is what I'm referring to in the subject where I say that I'd like\ngit to be able to disappear into the background when I'm talking about\nmy code.\n\nDoes that description help you understand what I'm looking for when I\npropose a new syntax for plus that could be accepted by\nboth \"clone\" and also propose a new \"track\" command that could accept\nthe same syntax?\n\n-Carl\n\n[*] I don't know if that command is exactly right---there is a lot to\nhave to remember to put that command together, (and in a precise\norder!), which is another reason I think the current approach is much\nharder than it should be.\n"},{"id":"40402","messageId":"87k5w07dft.wl%cworth@cworth.org","threadId":"7712","inReplyTo":"87mz0w7g3j.wl%cworth@cworth.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-25T14:09:58Z","receivedAt":"2007-04-25T14:09:58Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 25 Apr 2007 06:12:32 -0700, Carl Worth wrote:\n> [2]\tI've just written some very fancy feature for our cool project\n> \twhich you can see in gitweb at . To track this\n> \tbranch, do \"git remote add cworth ; git checkout --track\n> \t-b cworth/\" if you already have some clone of\n> \tour project. Otherwise do \"git clone ; git checkout\n> \t--track -b \". Please try it out and give me feedback.\n\nOops. I just noticed that that last command is wrong. Instead of \"git\ncheckout --track -b \" that should of course be \"git checkout\n--track -b origin/\".\n\nAnd no, I didn't intentionally botch that to be able to make a\npoint. But now, I will make the point: the current syntax is hard to\nremember. It _is_ powerful, and I do personally use it and like it,\n(and if I made the mistake above at the command line it would have\nbeen obvious to me how to fix it, and would have been no big deal).\n\nSo I'm not suggesting replacing any of the remote stuff---I'd just\nlike to have something easier to suggest to people who aren't yet\nfamiliar with remotes and remote-tracking branches, (and something\nsimple enough that I could get it right when writing an email without\ngit around to complain if I botch the syntax).\n\nSo I'd imagine \"git track #\" as being implemented\ndirectly with the existing remote stuff, (lookup and use an existing\nremote for if it exists, otherwise create a new one and name it\nwith some mangling of , or complain politely if the mangling\nwould clash with an existing remote with the same name but a different\nURL---which would be extremely unlikely).\n\nAnyway, as usual I seem to find myself with just enough time and\nmotivation to talk about what I'd like, but not enough to code it up.\nSo feel free to ignore me if you disagree, and please feel free to be\ninspired to code something up if you agree.\n\nAnd thanks to everyone that has worked to make git so excellent!\n\n-Carl\n"},{"id":"40409","messageId":"alpine.LFD.0.98.0704250744440.9964@woody.linux-foundation.org","threadId":"7712","inReplyTo":"87mz0w7g3j.wl%cworth@cworth.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-25T14:51:04Z","receivedAt":"2007-04-25T14:51:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 Apr 2007, Carl Worth wrote:\n> \n> So please allow me to comment on the syntax a bit. Linus, you claimed\n> that # isn't \"unixy\" enough for your taste. What does\n> that mean exactly?\n\nIt means *exactly* what it says. \n\nThat is a horrible syntax. It's not how we do *any* other commands. It's \nweb-centric in a way git simply IS NOT.\n\nWhat's so special about '#' that makes it wonderful for this special case? \nNOTHING.\n\nAnd to make matters worse, it's fundamentally TOO WEAK: The 'url#branch' \nsyntax would be limited to clones, because a \"pull\" and \"fetch\" _needs_ \nsomething more powerful. So if we introduce that syntax, we're forever \ncursed with having two incompatible and independent syntaxes for this, \nbecause (a) people will then say \"why not pull\", and (b) it's NOT A GOOD \nSYNTAX, so we'd support the old syntax for pull/fetch too.\n\nSo don't go there. It's simply a broken idea. Is that so hard to just \nadmit?\n\n\t\tLinus\n"},{"id":"40410","messageId":"alpine.LFD.0.98.0704250751330.9964@woody.linux-foundation.org","threadId":"7712","inReplyTo":"87k5w07dft.wl%cworth@cworth.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-25T14:55:49Z","receivedAt":"2007-04-25T14:55:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 Apr 2007, Carl Worth wrote:\n> \n> Oops. I just noticed that that last command is wrong. Instead of \"git\n> checkout --track -b \" that should of course be \"git checkout\n> --track -b origin/\".\n\nNo, it really should be\n\n\tgit branch --track newbranch origin/oldbranch\n\nfollowed by\n\n\tgit checkout newbranch\n\nand then it's not so hard. It's two commands, but it's two _simpler_ \ncommands, that make sense on their own. Don't use the complex version: \nit's a \"expert mode\" command that just knows how to do both.\n\nAlternatively, we *could* make just\n\n\tgit checkout --track branch\n\nbe a shorthand for\n\n\tgit checkout --track -b branch origin/branch\n\nwhen \"branch\" doesn't exist, but origin/branch does. With the \"--track\", \nit's already unambiguous (you cannot track a detached head, so we know we \nwant a branch.\n\n\t\t\tLinus\n"},{"id":"40414","messageId":"87fy6o770w.wl%cworth@cworth.org","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704250751330.9964@woody.linux-foundation.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-25T16:28:31Z","receivedAt":"2007-04-25T16:28:31Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 25 Apr 2007 07:55:49 -0700 (PDT), Linus Torvalds wrote:\n> Alternatively, we *could* make just\n>\n> \tgit checkout --track branch\n>\n> be a shorthand for\n>\n> \tgit checkout --track -b branch origin/branch\n>\n> when \"branch\" doesn't exist, but origin/branch does. With the \"--track\",\n> it's already unambiguous (you cannot track a detached head, so we know we\n> want a branch.\n\nI like that a lot, thanks! Things that make the command-line simpler\nwith no loss in functionality nor introducing any ambiguity are really\nnice.\n\nAnd I'd even follow that up to propose making \"git checkout branch\"\n(where branch doesn't exist but remote//branch does), do\nsomething new, (not detached head, nor creating a local tracking\nbranch), that would allow the following:\n\n1. Using \"git checkout branch\" to examine the working-tree status of a\n branch.\n\n\tThis functionality exists already, but with a fairly obnoxious\n\tdetached head warning.\n\n2. Subsequently using \"git pull\" to track that remote branch\n\n\tThis functionality is currently missing without creating a\n\tlocal branch first. This is an inconvenience compared to the\n\tpre-separate-remotes git where \"git checkout next\" followed by\n\ta sequence of \"git pull\" was enough to track a branch.\n\n\tNow, old git also had the huge defect that it was too easy to\n\tscrew everything up by committing to what should have been\n\ttreated as a read-only tracking branch, which is where the\n\tnext point comes in.\n\n3. Allow a commit from this state, by *then* creating the explicit\n local branch setup to track the remote-tracking branch.\n\n\tThat is, under this proposal the command sequence of:\n\n\t\tgit checkout branch\n\t\t# hack\n\t\tgit commit\n\n\tWould get one to the exact same state as today's sequence of:\n\n\t\tgit branch --track branch origin/branch\n\t\tgit checkout branch\n\t\t# hack\n\t\tgit commit\n\n\tWhich to me just looks like making git easier to use.\n\n\tOf course, git could complain politely if the branch name it\n\twanted to create were taken already and instruct the user how\n\tto create a new name for the tracking branch before the\n\tcommit.\n\nIs that a totally insane idea? (The answer might very well depend on\nsome details of the implementation---presumably .git/HEAD would have\nto store both the name of the remote-tracking branch as well as the\nsha1 to which it corresponded at the time of the checkout.)\n\n-Carl\n"},{"id":"40416","messageId":"alpine.LFD.0.98.0704251341280.12375@xanadu.home","threadId":"7712","inReplyTo":"87fy6o770w.wl%cworth@cworth.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-25T18:07:23Z","receivedAt":"2007-04-25T18:07:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 25 Apr 2007, Carl Worth wrote:\n\n> And I'd even follow that up to propose making \"git checkout branch\"\n> (where branch doesn't exist but remote//branch does), do\n> something new, (not detached head, nor creating a local tracking\n> branch), that would allow the following:\n> \n> 1. Using \"git checkout branch\" to examine the working-tree status of a\n> branch.\n> \n> \tThis functionality exists already, but with a fairly obnoxious\n> \tdetached head warning.\n\nWith all the safeties (reflogs, etc) this warning could be toned down \neven more now.\n\n> 2. Subsequently using \"git pull\" to track that remote branch\n> \n> \tThis functionality is currently missing without creating a\n> \tlocal branch first. This is an inconvenience compared to the\n> \tpre-separate-remotes git where \"git checkout next\" followed by\n> \ta sequence of \"git pull\" was enough to track a branch.\n> \n> \tNow, old git also had the huge defect that it was too easy to\n> \tscrew everything up by committing to what should have been\n> \ttreated as a read-only tracking branch, which is where the\n> \tnext point comes in.\n> \n> 3. Allow a commit from this state, by *then* creating the explicit\n> local branch setup to track the remote-tracking branch.\n> \n> \tThat is, under this proposal the command sequence of:\n> \n> \t\tgit checkout branch\n> \t\t# hack\n> \t\tgit commit\n> \n> \tWould get one to the exact same state as today's sequence of:\n> \n> \t\tgit branch --track branch origin/branch\n> \t\tgit checkout branch\n> \t\t# hack\n> \t\tgit commit\n> \n> \tWhich to me just looks like making git easier to use.\n\nI don't feel comfortable with that.\n\nTo me it looks like Git would perform some hardcoded magic without \nhelping the user understanding what is going on. Worse: it can perform \nall those operations even if that is not what you wanted.\n\nI much prefer multiple simple commands that perform basic and \nunderstandable operations than a single complex one with more magic in \nit. If it was just me I'd eliminate the pull command and a pull would \nalways be a fetch followed by a merge...\n\nI understand your desire for people to get at your code as quickly and \neasy as possible, but that conflicts with our desire for people to \nreally understand the basics of Git. Creating magic commands with \nhardcoded defaults for a one-click-does-all behavior isn't helping \nthat understanding at all.\n\nIf you really want people to get at your code with no Git consideration \nwhat so ever, then just direct them at the corresponding gitweb and/or \ngit-archive invocations with --remote= to store a local copy.\n\n> \tOf course, git could complain politely if the branch name it\n> \twanted to create were taken already and instruct the user how\n> \tto create a new name for the tracking branch before the\n> \tcommit.\n> \n> Is that a totally insane idea? (The answer might very well depend on\n> some details of the implementation---presumably .git/HEAD would have\n> to store both the name of the remote-tracking branch as well as the\n> sha1 to which it corresponded at the time of the checkout.)\n\nAnd why again isn't detached head just fine for your usage scenario \ninstead? Only the \"obnoxious\" warning?\n\n\nNicolas\n"},{"id":"40420","messageId":"878xcg6zv0.wl%cworth@cworth.org","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704251341280.12375@xanadu.home","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-25T19:03:15Z","receivedAt":"2007-04-25T19:03:15Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 25 Apr 2007 14:07:23 -0400 (EDT), Nicolas Pitre wrote:\n> With all the safeties (reflogs, etc) this warning could be toned down\n> even more now.\n\nThat would definitely help.\n\n> To me it looks like Git would perform some hardcoded magic without\n> helping the user understanding what is going on.\n\nThat's a fine argument.\n\n> If you really want people to get at your code with no Git consideration\n> what so ever, then just direct them at the corresponding gitweb and/or\n> git-archive invocations with --remote= to store a local copy.\n\nBut that's just it. It's not that I want people to get at my code with\nno git consideration. I believe that git provides the best way to get\nat my code, (since it allows not just getting at a single snapshot\nlike git-archive would), but it allows for getting at everything in\nthe past as well, and easily getting at stuff in the future.\n\nIt's more that I want a single way to talk about some branch I've just\npublished, (necessarily both a url and a branch), and I assume an\naudience with a wide range of git experience, (from none to lots).\nSo I'm just looking for a simple way to advertise the branch that will\nwork for the whole audience, (gitweb and git-archive aren't going to\nbe much use for the experienced git user---except in an indirect way\nwhere the user could manually extract the useful parts of the\ninstructions out of the noise).\n\n> And why again isn't detached head just fine for your usage scenario\n> instead? Only the \"obnoxious\" warning?\n\nNo ability to easily follow the branch as new stuff comes along.\n\nCompare what one used to be able to do with pre-separate-remotes git:\n\n\tgit clone git://git.kernel.org/pub/scm/git/git.git\n\tgit checkout next\n\tgit pull # occasionally\n\nto what you have now:\n\n\tgit clone git://git.kernel.org/pub/scm/git/git.git\n\tgit checkout origin/next\n\nAnd what's step 3 to follow this branch? Certainly, doing \"git fetch\"\noccasionally brings in the data, but there's no simple way to use\ndetached head to just \"follow along\".\n\nSo then the user has to learn new concepts like creating a tracking\nbranch:\n\n\tgit branch --track next origin/next\n\tgit checkout next\n\tgit pull # occasionally\n\nYou can say that's just a series of simple commands, but it's still\nmore concepts and commands than other systems, (including past\nversions of git).\n\nAnd for the user that's really just doing read-only branch tracking, I\ndon't see where there's much benefit coming from the extra concepts\nand commands.\n\n-Carl\n"},{"id":"40423","messageId":"7vfy6oxnzp.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"878xcg6zv0.wl%cworth@cworth.org","subject":"Re: Making git disappear when talking about my code","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-25T19:17:30Z","receivedAt":"2007-04-25T19:17:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> It's more that I want a single way to talk about some branch I've just\n> published, (necessarily both a url and a branch), and I assume an\n> audience with a wide range of git experience, (from none to lots).\n\nWhy would you want to add another syntax that can talk about\nonly one branch? It shows that you care only about talking\nabout single branch, making things harder for other people who\nmight want to talk about two branches or more.\n\nI would agree with you that if you are talking to total git\nnewbie, you cannot get away with message like [3] in your\noriginal and you would need some instructions you added in your\nexample [2]. But I suspect that is true for any new system. If\nsomebody has never seen cvs and your project is hosted at cvs,\nand if you want to be really helpful, I think you have to tell\n\"cvs -d :pserver:... co cworth-project\" somewhere in your\nmessage.\n\nBut that does not have to be in the main part of the\nannouncement, like this (this is your [2]):\n\n I've just written some very fancy feature for our cool project\n which you can see in gitweb at . To track this\n branch, do \"git remote add cworth ; git checkout --track\n -b cworth/\" if you already have some clone of\n our project. Otherwise do \"git clone ; git checkout\n --track -b \". Please try it out and give me feedback.\n\nYou can say instead:\n\n I've just written some very fancy feature for our cool project\n which is available in the branch at . Please try\n it out and give me feedback. [*1*]\n\n [Footnote]\n\n *1* If you have never used git, here are the ways to get at\n the cool project ...\n\n\t <<< instruction here >>>\n\n\tIf you have been tracking the upstream of the cool\n\tproject, alternatively you can do this to get to my\n\tfancy feature as a new branch in your repository ...\n\n\t <<< instruction here >>>\n"},{"id":"40426","messageId":"alpine.LFD.0.98.0704251521110.12375@xanadu.home","threadId":"7712","inReplyTo":"7vfy6oxnzp.fsf@assigned-by-dhcp.cox.net","subject":"Re: Making git disappear when talking about my code","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-25T19:22:59Z","receivedAt":"2007-04-25T19:22:59Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 25 Apr 2007, Junio C Hamano wrote:\n\n> I would agree with you that if you are talking to total git\n> newbie, you cannot get away with message like [3] in your\n> original and you would need some instructions you added in your\n> example [2]. But I suspect that is true for any new system. If\n> somebody has never seen cvs and your project is hosted at cvs,\n> and if you want to be really helpful, I think you have to tell\n> \"cvs -d :pserver:... co cworth-project\" somewhere in your\n> message.\n\nYou forget about \"cvs -d :pserver:... login\" that needs to be performed \nas well.\n\n\nNicolas\n"},{"id":"40429","messageId":"Pine.LNX.4.64.0704251345220.28708@iabervon.org","threadId":"7712","inReplyTo":"87mz0w7g3j.wl%cworth@cworth.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-25T19:44:11Z","receivedAt":"2007-04-25T19:44:11Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 25 Apr 2007, Carl Worth wrote:\n\n> On Mon, 23 Apr 2007 22:15:04 -0700, Junio C Hamano wrote:\n> > Linus Torvalds writes:\n> >\n> > > I'd personally be ok with a\n> > >\n> > > \tgit clone --default= \n> ...\n> > If Carl is also happy with the syntax, we can conclude this\n> > discussion and:\n> >\n> > (1) have that as an enhancement to git-clone;\n> \n> I think it's a useful enhancement. It would let me at least document\n> something like \"tracking this project's stable branch\" with a single\n> command, which I think is useful. But I don't know that I would be\n> totally happy yet. :-)\n> \n> So please allow me to comment on the syntax a bit. Linus, you claimed\n> that # isn't \"unixy\" enough for your taste. What does\n> that mean exactly? Is it that two logically independent things are\n> crammed into a single argument instead of being passed as second\n> arguments? Or something else?\n\nLinus has stated a preference on the lkml for being told about branches in \nthe syntax used for anonymous pulls: URL branchname.\n\nThat is, you say:\n\n Please pull from:\n git://server/path branch\n\nAnd he cuts and pastes into the command line:\n\n git pull git://server/path branch\n\nNow, this syntax isn't available for git-clone, because git-clone puts the \noptional directory to create after the URL. But, in an ideal world, this \nis how it would work; you could see a pull request, and just type \"git \nsome-command \".\n\n> Here's the reason I want both the URL and the branch to appear as a\n> single string, (but I don't really care about the precise syntax). I\n> really want to be able to say \"see my branch at \" and have\n> that be a complete and self-contained description of the\n> branch that can be used in several different ways including:\n> \n> * Cloning a new repository to track that branch as the default\n> \n> * Begin tracking that branch as a new branch within an existing\n> repository\n\nHere, you probably need to specify what you want the new branch to be, \nbecause it will often be the case that the remote branch will be \"master\" \nin a repository with a long unrecognizable URL, and you need to be able to \nswitch to and away from the branch in some sane way. On the other hand, \nthe user will presumably never care too deeply about the remote, aside \nfrom that git remembers stuff appropriately. I say, use the hash of the \nURL as the name of the remote, and provide some shorthand for the tracking \nbranch that would be merged by default into the current head, and you're \nset. I.e.:\n\ngit track new-name URL [branch]\n\ncreates and checks out a new branch \"new-name\" with the config:\n\n[remote \"hash of URL\"]\n\turl = URL\n\tfetch = +refs/heads/*:refs/remotes/hash of URL/*\n[branch \"new-name\"]\n\tremote = \"hash of URL\"\n\tmerge = refs/heads/[branch]\n\nWhen on this branch, you update with \"git pull\" (which already works, \ngiven this configuration). And there would just need to be a better way of \ndoing \"git log remotes/hash of URL/branch..HEAD\", which should probably be \nsomething like \"git log MERGE..HEAD\", with MERGE being magic for the thing \nthat tracks the current branch's \"merge\" setting.\n\nIncidentally, I'm not seeing the case of wanting to track multiple \nbranches from the same repository as nearly as likely for a novice as \nwanting to track multiple branches from different repositories. I think \nthe likely order of being interested in things is:\n\n1. The project's maintainer's repository, exactly one of maint, master, or \n next.\n2. Somebody else's repository for some interesting feature, master\n3. Somebody else's repository for all interesting features, some branch\n4. Repository from 3, additional branches\n5. Maintainer's repository, multiple branches.\n\nWith the most common case for two tracking branches being master from two \nrepositories, such that upstream branch names are most often useless for \ndistinguishing anything.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"40432","messageId":"7vzm4ww7lj.fsf@assigned-by-dhcp.cox.net","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704251345220.28708@iabervon.org","subject":"Re: Making git disappear when talking about my code","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-25T19:56:56Z","receivedAt":"2007-04-25T19:56:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Linus has stated a preference on the lkml for being told about branches in \n> the syntax used for anonymous pulls: URL branchname.\n>\n> That is, you say:\n>\n> Please pull from:\n> git://server/path branch\n>\n> And he cuts and pastes into the command line:\n>\n> git pull git://server/path branch\n>\n> Now, this syntax isn't available for git-clone, because git-clone puts the \n> optional directory to create after the URL. But, in an ideal world, this \n> is how it would work; you could see a pull request, and just type \"git \n> some-command \".\n\nI think I already suggested this to Carl once, but if you \nforget about 'git clone' in this case (or any other cases), your\nexample would just work.\n\n\t$ git init\n $ git pull git://server/path branch\n"},{"id":"40439","messageId":"alpine.LFD.0.98.0704251523050.12375@xanadu.home","threadId":"7712","inReplyTo":"878xcg6zv0.wl%cworth@cworth.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-25T20:23:06Z","receivedAt":"2007-04-25T20:23:06Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 25 Apr 2007, Carl Worth wrote:\n\n> Compare what one used to be able to do with pre-separate-remotes git:\n> \n> \tgit clone git://git.kernel.org/pub/scm/git/git.git\n> \tgit checkout next\n> \tgit pull # occasionally\n> \n> to what you have now:\n> \n> \tgit clone git://git.kernel.org/pub/scm/git/git.git\n> \tgit checkout origin/next\n\nBut if you _create_ a new branch in your repository, Git will pick it up \nautomatically now with a fetch operation, which the previous branch \nlayout didn't allow for.\n\n\nNicolas\n"},{"id":"40440","messageId":"874pn46w0e.wl%cworth@cworth.org","threadId":"7712","inReplyTo":"7vfy6oxnzp.fsf@assigned-by-dhcp.cox.net","subject":"Re: Making git disappear when talking about my code","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-25T20:26:25Z","receivedAt":"2007-04-25T20:26:25Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 25 Apr 2007 12:17:30 -0700, Junio C Hamano wrote:\n> Carl Worth writes:\n>\n> > It's more that I want a single way to talk about some branch I've just\n> > published, (necessarily both a url and a branch), and I assume an\n> > audience with a wide range of git experience, (from none to lots).\n>\n> Why would you want to add another syntax that can talk about\n> only one branch?\n\nAs mentioned elsewhere in the thread, I'm fine with a space for a\nseparator instead of a '#'. I really didn't intend to get hung up on\nthat kind of syntactic issue.\n\nThe question is how much work is involved in getting from:\n\n\tCheckout my new work:\n\n\t\t \n\nto where the user can just start tracking it (read-only). Right now,\nin many cases the user has to slice that up and pass the to some\ncommands and the to other commands (see below).\n\n> You can say instead:\n>\n> I've just written some very fancy feature for our cool project\n> which is available in the branch at . Please try\n> it out and give me feedback. [*1*]\n\nOK, and I'll fill in the holes in your footnote. I'm perfectly fine\nwith assuming the user already has a clone of the project, (they can\nfind well-published instructions for that on the project site), so\nthen what's left is:\n\n\t*1* From within your git clone of the project, do the following (if\n\t you haven't made a remote for my repository before):\n\n\t\tgit remote add cworth \n\n\t Finally, you can start tracking my branch with the following:\n\n\t\tgit fetch cworth\n\t\tgit branch --track cworth/\n\t\tgit checkout \n\n\t And use \"git pull\" periodically to stay abreast of future work I\n\t do on that branch.\n\nThat's workable, but notice that every occurrence of \"cworth\" in the\nabove is really getting in the user's way. Once a user knows a bit\nmore about git and remotes, it can be really useful to take advantage\nof them. For example, when I'm interested in inspecting a newly\nannounced branch like this from someone for whom I have already setup\na remote I often do:\n\n\tgit fetch \n\tgit log ../\n\nAnd that's really nice and easy, (yes, multiple-branch tracking in a\nsingle repository *is* the one true way).\n\nBut I don't think forcing the remote-creation on the user, (as in my\nfootnote), is actually making things easier.\n\n-Carl\n"},{"id":"40441","messageId":"873b2o6vvk.wl%cworth@cworth.org","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704251345220.28708@iabervon.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-25T20:29:19Z","receivedAt":"2007-04-25T20:29:19Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 25 Apr 2007 15:44:11 -0400 (EDT), Daniel Barkalow wrote:\n> Linus has stated a preference on the lkml for being told about branches in\n> the syntax used for anonymous pulls: URL branchname.\n\nThat's a fine syntax too.\n\n> Now, this syntax isn't available for git-clone, because git-clone puts the\n> optional directory to create after the URL. But, in an ideal world, this\n> is how it would work; you could see a pull request, and just type \"git\n> some-command \".\n\nYes. That's exactly what I'm talking about, being able to very easily\njust paste the branch specifier to a git command. And yes, it would\nbe convenient if one could do this for as many commands as\npossible. The fact that git-clone can't accept this syntax is\nunfortunate, (and maybe that is the only reason I was inclined to add\nthe '#' character).\n\n> Here, you probably need to specify what you want the new branch to be,\n> because it will often be the case that the remote branch will be \"master\"\n> in a repository with a long unrecognizable URL, and you need to be able to\n> switch to and away from the branch in some sane way. On the other hand,\n> the user will presumably never care too deeply about the remote, aside\n> from that git remembers stuff appropriately. I say, use the hash of the\n> URL as the name of the remote, and provide some shorthand for the tracking\n> branch that would be merged by default into the current head, and you're\n> set. I.e.:\n>\n> git track new-name URL [branch]\n\nOK, that still allows for pasting the URL and branch, but the user has\nto know not only \"git track\" but also that she must invent a local for\nthe branch and insert that into the command as well. And it's hard for\nme to help the user on this point (at least in a cut-and-pasteable\nway), since the whole point of that argument is to create an entry in\na private namespace that I don't know anything about.\n\nHow about making that optional at least? That is create a local branch\nnamed for:\n\n\tgit track URL \n\nbut also allow something like:\n\n\tgit track --as URL \n\n> creates and checks out a new branch \"new-name\" with the config:\n>\n> [remote \"hash of URL\"]\n> \turl = URL\n> \tfetch = +refs/heads/*:refs/remotes/hash of URL/*\n> [branch \"new-name\"]\n> \tremote = \"hash of URL\"\n> \tmerge = refs/heads/[branch]\n\nYes, this is the kind of stuff I'd like to see. Just create a remote\non behalf of the user with whatever unique name you want, (or use an\nexisting remote if one already exists for the given URL).\n\n> Incidentally, I'm not seeing the case of wanting to track multiple\n> branches from the same repository as nearly as likely for a novice as\n> wanting to track multiple branches from different repositories.\n\nYes, I would agree with that.\n\n> With the most common case for two tracking branches being master from two\n> repositories, such that upstream branch names are most often useless for\n> distinguishing anything.\n\nAh, that's an interesting point.\n\nIt's interesting because it's obviously the case for some projects,\nbut it's also not the case for some, (like the cairo project that I\ncare about). Maybe we're still overly accustomed to our \"central\"\nmentality, but we don't really have a lot of interesting \"master\"\nbranches in our personal repositories. Instead, the central repository\nhas \"master\" and one branch for each stable maintenance series, then\neach developer's personal repository has a collection of topic\nbranches for stuff that is cooking.\n\nI guess we just don't have sub-maintainers maintaining entire\ncollections of patches with git like you get with the kernel for\nexample.\n\n-Carl\n"},{"id":"40442","messageId":"alpine.LFD.0.98.0704251325260.9964@woody.linux-foundation.org","threadId":"7712","inReplyTo":"7vzm4ww7lj.fsf@assigned-by-dhcp.cox.net","subject":"Re: Making git disappear when talking about my code","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-25T20:29:54Z","receivedAt":"2007-04-25T20:29:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 Apr 2007, Junio C Hamano wrote:\n> \n> I think I already suggested this to Carl once, but if you \n> forget about 'git clone' in this case (or any other cases), your\n> example would just work.\n> \n> $ git init\n> $ git pull git://server/path branch\n\nThe problem with this is that it doesn't set up tracking, so while it \n*works*, you are now forever doomed to re-do that\n\n\tgit pull git://server/path branch\n\nto update, and if you then ever give the wrong branch name you'll try to \nmerge and get really confused as a beginner.\n\n\t\tLinus\n"},{"id":"40444","messageId":"alpine.LFD.0.98.0704251626140.12375@xanadu.home","threadId":"7712","inReplyTo":"Pine.LNX.4.64.0704251345220.28708@iabervon.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-25T20:31:03Z","receivedAt":"2007-04-25T20:31:03Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 25 Apr 2007, Daniel Barkalow wrote:\n\n> Linus has stated a preference on the lkml for being told about branches in \n> the syntax used for anonymous pulls: URL branchname.\n> \n> That is, you say:\n> \n> Please pull from:\n> git://server/path branch\n> \n> And he cuts and pastes into the command line:\n> \n> git pull git://server/path branch\n> \n> Now, this syntax isn't available for git-clone, because git-clone puts the \n> optional directory to create after the URL. But, in an ideal world, this \n> is how it would work; you could see a pull request, and just type \"git \n> some-command \".\n\nMaybe git-pull could be made usable just as well from an empty \nrepository (isn't it already?) as a substitute for clone.\n\n\nNicolas\n"},{"id":"40445","messageId":"alpine.LFD.0.98.0704251631520.12375@xanadu.home","threadId":"7712","inReplyTo":"7vzm4ww7lj.fsf@assigned-by-dhcp.cox.net","subject":"Re: Making git disappear when talking about my code","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-25T20:32:36Z","receivedAt":"2007-04-25T20:32:36Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 25 Apr 2007, Junio C Hamano wrote:\n\n> I think I already suggested this to Carl once, but if you \n> forget about 'git clone' in this case (or any other cases), your\n> example would just work.\n> \n> \t$ git init\n> $ git pull git://server/path branch\n\nAh, goodie!\n\n\nNicolas\n"},{"id":"40461","messageId":"Pine.LNX.4.64.0704251606470.28708@iabervon.org","threadId":"7712","inReplyTo":"7vzm4ww7lj.fsf@assigned-by-dhcp.cox.net","subject":"Re: Making git disappear when talking about my code","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-25T21:38:06Z","receivedAt":"2007-04-25T21:38:06Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 25 Apr 2007, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > Linus has stated a preference on the lkml for being told about branches in \n> > the syntax used for anonymous pulls: URL branchname.\n> >\n> > That is, you say:\n> >\n> > Please pull from:\n> > git://server/path branch\n> >\n> > And he cuts and pastes into the command line:\n> >\n> > git pull git://server/path branch\n> >\n> > Now, this syntax isn't available for git-clone, because git-clone puts the \n> > optional directory to create after the URL. But, in an ideal world, this \n> > is how it would work; you could see a pull request, and just type \"git \n> > some-command \".\n> \n> I think I already suggested this to Carl once, but if you \n> forget about 'git clone' in this case (or any other cases), your\n> example would just work.\n> \n> \t$ git init\n> $ git pull git://server/path branch\n\nIt works for Linus's usage, where he expects to get all the info again \nnext time there's more useful stuff. I don't think this configures things \nso that:\n\n\t$ git init\n\t$ git pull git://server/path branch\n\t... wait a couple of weeks and forget the URL ...\n\t$ git pull\n\nworks. (Although I haven't actually checked, so I could be totally wrong)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"40465","messageId":"Pine.LNX.4.64.0704251743300.28708@iabervon.org","threadId":"7712","inReplyTo":"873b2o6vvk.wl%cworth@cworth.org","subject":"Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-25T22:39:37Z","receivedAt":"2007-04-25T22:39:37Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 25 Apr 2007, Carl Worth wrote:\n\n> On Wed, 25 Apr 2007 15:44:11 -0400 (EDT), Daniel Barkalow wrote:\n> \n> > Here, you probably need to specify what you want the new branch to be,\n> > because it will often be the case that the remote branch will be \"master\"\n> > in a repository with a long unrecognizable URL, and you need to be able to\n> > switch to and away from the branch in some sane way. On the other hand,\n> > the user will presumably never care too deeply about the remote, aside\n> > from that git remembers stuff appropriately. I say, use the hash of the\n> > URL as the name of the remote, and provide some shorthand for the tracking\n> > branch that would be merged by default into the current head, and you're\n> > set. I.e.:\n> >\n> > git track new-name URL [branch]\n> \n> OK, that still allows for pasting the URL and branch, but the user has\n> to know not only \"git track\" but also that she must invent a local for\n> the branch and insert that into the command as well. And it's hard for\n> me to help the user on this point (at least in a cut-and-pasteable\n> way), since the whole point of that argument is to create an entry in\n> a private namespace that I don't know anything about.\n\nWell, it's not only a private namespace, it's a namespace of stuff that \nshould be meaningful to the user. Sure, there's a certain extent to which \nwhat's meaningful to the publisher is likely to be meaningful to the user, \nbut I've used \"subproject\" to refer to a \"submodule2\" remote branch, \nbecause that's what I was naming the feature in my head, and I wouldn't \nhave found the 2 intuitive in general (it was the second attempt at an \nimplementation). It's fundamentally a local alias for a global name.\n\nOn the other hand, it might be good if the publisher could give \ninstructions with an option that prompts the user with a sensible default, \ngiven the arguments and the state of the repository.\n\n> > With the most common case for two tracking branches being master from two\n> > repositories, such that upstream branch names are most often useless for\n> > distinguishing anything.\n> \n> Ah, that's an interesting point.\n> \n> It's interesting because it's obviously the case for some projects,\n> but it's also not the case for some, (like the cairo project that I\n> care about). Maybe we're still overly accustomed to our \"central\"\n> mentality, but we don't really have a lot of interesting \"master\"\n> branches in our personal repositories. Instead, the central repository\n> has \"master\" and one branch for each stable maintenance series, then\n> each developer's personal repository has a collection of topic\n> branches for stuff that is cooking.\n\nI think there's likely to be a reasonably large variation in what \nrepositories exist and what branches they have. People could easily have a \nrepository per topic, with a branch per stable series (with experimental \nwork being potentially queued for a relatively far future series). There \ncould be shared repositories for features that multiple people work on, \nwith per-person branches. People do all sorts of things, and even within a \nproject, they don't all have to be the same, so long as the \"URL branch\" \nformat works for everybody who has to get a branch. But that also means \nthat it's hard to find a reliable meaningful sub-part of that format.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"40729","messageId":"20070430043136.GA17639@fieldses.org","threadId":"7712","inReplyTo":"alpine.LFD.0.98.0704240752030.9964@woody.linux-foundation.org","subject":"Re: GIT vs Other: Need argument","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-04-30T04:31:36Z","receivedAt":"2007-04-30T04:31:36Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Apr 24, 2007 at 08:01:50AM -0700, Linus Torvalds wrote:\n> Well, I think they really should be documents of their own, so that you \n> can read about the \"CVS tracking\" or so without even worrying about the \n> fact that you didn't read the whole thing.\n\nSure. There may be some tension between making more separate documents\nand keeping them all findable. Well, it just means we need some easy\nway to index them.\n\n> And they should be easy to find. I agree that we do actually have a fair \n> amount of docs, but it seems that people don't tend to *find* them. The \n> user-manual, for example, is great, but I've seen people on the #git logs \n> apparently not realize it exists ;)\n> \n> For example, the git homepage has a \"documentation\" thing, which only \n> lists the tutorial, not the user manual explicitly. You _can_ get to the \n> user manual (go to the online version of the Documentation directory and \n> note the \"still work in progress\"), but even if you do actually find \n> yourself there, the user manual itself is actually a bit scary to start \n> with.\n> \n> So I think we could just make the initial impression a bit easier. The \n> tutorial comes fairly close to the \"tracking your own\" thing, I agree, \n> but maybe we could have the documentation listed in order of complexity, \n> and having a way for people to know *which* doc they should start with \n> when they are at http://git.or.cz/ (or the wikipedia page), so that if \n> you're only interested in the \"tracking somebody else\", you could easily \n> find and read just a single simple documentation thing. Hmm?\n\nYeah. So we can try to figure out a small set of clearly labeled entry\npoints into the documentation, and I'll work with Petr Baudis to make\nsure they're at the top of the git home page. And I suppose the same\nset should appear on the main git man page. Anywhere else? Maybe\nDocumentation/ needs its own index.html....\n\n--b.\n"}]}