{"thread":{"id":"43475","subject":"Re: Cleaning up git user-interface warts","startedAt":"2006-11-16T16:07:00Z","lastAt":"2006-11-24T11:29:03Z","messageCount":4,"participants":["Sanjoy Mahajan","Theodore Tso","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"297321","messageId":"20061116160700.GA3383@thunk.org","threadId":"43475","inReplyTo":"7vd57of2cv.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-11-16T16:07:00Z","receivedAt":"2006-11-16T16:07:00Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Nov 15, 2006 at 08:21:36PM -0800, Junio C Hamano wrote:\n> Theodore Tso <tytso@mit.edu> writes:\n> > So with Bitkeeper, with \"bk pull\" there was never any question about\n> > which branch (\"line of development\") you would be merging into after\n> > doing a \"bk pull\", since there was only one LOD, and given that BK had\n> > the rule that a within a LOD only one tip was allowed, a \"bk pull\"\n> > _had_ to do do a merge operation.   \n> \n> I've never used Bk and I really appreciate your comments here.\n> \n> > If you are operating on your local development branch, the reality is\n> > that merging is probably not the right answer in the general case,\n> \n> I agree, but I wonder why you are pulling/fetching (with or\n> without merge) if you are operating on your local development\n> branch (implying that you are in the middle of something else).\n\nWell, when I was using BitKeeper, I never would.  Bitkeeper has what\nLinus calls the broken \"repository == branch\" model.  So normally I\nwould have one repository where I would track the upstream branch, and\nonly do bk pull into that branch.  I would do my hacking in another\nrepository (i.e., branch), and periodically keep track wha was going\non in mainline by cd'ing to the mainline repository and doing the bk\npull there.  \n\nThe challenge when you put multiple branches into a single repository,\nis you have to keep track of which branch you happen to be in.  In the\nBK world, this was obvious because it would show up in my shell\nprompt:\n\n<tytso@candygram>       {/usr/src/linux-2.6}\n2% \n\n(OK, obviously I'm in the Linux 2.6 upstream repository)\n\nIn a system where you need to keep track of what branch you are in via\nan SCM-specific local state information, it's easy to get confused and\ndo a pull when you are in the \"wrong\" branch, or while you have local\nstate in your working directory.   \n\nWhat I currently do (and I'm sure I'm being really horrible and need\nto be say 100 \"Hail, Linus\"'es for penance for not adhering staying in\nthe one true distributed state of grace) is that I keep an entirely\nseparate Linux 2.6 git repository just to make sure I never get\nconfused about what branch I might happen to be in when I do the \"git\npull\" --- and yeah, I could have used \"git fetch\", but 3+ years of BK\nusage plus Hg usage is hard to get away from.  I'm sure this is where\nLinus would say that use of BK and Hg, causes permanent brain damage,\nala's Dijkstra's ofted quoted comment about use of Basic inducing\nbrain damage....\n\n> I have to disagree with this.  In the simplest CVS-like central\n> repository with single branch setup in which many \"novice users\"\n> start out with, there is almost no need for \"git fetch\" nor\n> tracking branch.  You pull, resolve conflicts, attempt to push\n> back, perhaps gets \"oh, no fast forward somebody pushed first\",\n> pull again, then push back.  So I am not sure where \"you really\n> do not want to use pull.  trust me\" comes from.\n\nI think the problem is the people who have had years of BK or Hg\nexperience.  Maybe it's more of a documentation problem; perhaps a\n\"git for BK\" or \"git for Hg\" users is what's needed.  The problem\nthough is that while use of BK is definitely legacy, there are going\nto be a lot of people who need to use both BK and Hg.   \n\n> It is a different story for people who _know_ git enough to know\n> what is going on.  They may be using multiple branches and\n> interacting with multiple remote branches, and there are times\n> you would want fetch and there are other times you would want\n> pull.  But for them, I do think the suggestion would never end\n> with \"trust me\" -- they would understand what the differences\n> are.\n\nWell, I think this is where git's learning curve challenges are.  Yes,\nfor users that are doing the stupidest, most simplistic usage models,\ngit is quite easy to use.  And I am willing to grant that for people\nwho are using the deepest, most complicated and most distributed\ndevelopment, who understand multiple branches and the index, and all\nof the deep git plumbing, there's also no problem.\n\nThe challenge is in between; to use a car analogy, git has a great\nautomatic transmision, and an extremely powerful \"racing clutch\".  But\nfor someone where the automatic transmission isn't good enough, when\nas they start to learn how to use the manual transmission, git's\nextremely touchy \"racing clutch\" is much more difficult master ---\nespecially in comparison to people who have learned to drive other,\nmore pedestrian \"standard transmission\" cars.  So people who try to\nuse git's racing clutch keep stalling out the car, and some give up in\nfrustration.\n\nAnd maybe the problem is one that should be addressed only by lots of\ntraining, but at the moment, that's the reason why I believe a number\nof projects have chosen Hg instead of git; they need more than the\n\"stupid simple\" git usage, but if they don't need the extreme power of\ngit, Hg is simpler for people to learn how to use.  The problem, of\ncourse, comes when later on, the project finds out they really want\ngit's power, and now they have to deal with the repository conversion\nas well as retraining their entire development community.\n\nBut hey, maybe this isn't a problem the git community wants to solve;\nclearly git is optimized for the Linux kernel development, and maybe\nit's too much to ask that it also work well for somewhat less\nextremely distributed development models.  But in any case, that's why\nI chose Hg for e2fsprogs.  At the time when I made my choice, git was\njust too painful to learn how to use its more esoteric features, and\nHg was much closer to BK's model.  (Since then, Hg has added more\nfunctionality, including better multiple branches in a repository\nsupport, and it's gotten more complicated, but it's still much simper\nto teach someone how to use Hg than git.)\n\nRegards,\n\n"},{"id":"298474","messageId":"20061116164939.GA26278@thunk.org","threadId":"43475","inReplyTo":"20061116160700.GA3383@thunk.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-11-16T16:49:39Z","receivedAt":"2006-11-16T16:49:39Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Nov 16, 2006 at 11:07:00AM -0500, Theodore Tso wrote:\n> I think the problem is the people who have had years of BK or Hg\n> experience.  Maybe it's more of a documentation problem; perhaps a\n> \"git for BK\" or \"git for Hg\" users is what's needed.  The problem\n> though is that while use of BK is definitely legacy, there are going\n> to be a lot of people who need to use both BK and Hg.   \n\nErr, what I meant to say is that there are going to be a lot of people\nwho will need to simultaneously use both git and Hg.\n\n"},{"id":"295008","messageId":"E1Gn1PG-0002oW-00@skye.ra.phy.cam.ac.uk","threadId":"43475","inReplyTo":"20061116160700.GA3383@thunk.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Sanjoy Mahajan","fromEmail":"sanjoy@mrao.cam.ac.uk","sentAt":"2006-11-22T23:21:30Z","receivedAt":"2006-11-22T23:21:30Z","isPatch":false,"sender":{"key":"sanjoy@mrao.cam.ac.uk","avatar":null},"body":"The car analogy is excellently clear.\n\n> they need more than the \"stupid simple\" git usage, but if they don't\n> need the extreme power of git, Hg is simpler for people to learn how\n> to use.\n\nAs a 80%-hg/20%-git user, I'm curious what features of git you had in\nmind, so I know where to look as I wander up the git learning curve.\n\nMy experience with the git user interface, for what it's worth, is\nthat I never quite get the conceptual model crystal clear enough in my\nhead. So it won't stay for long enough for me to progress up the\nlearning curve and retain the gains.  I move up a bit, but the gain\nsoon evaporates and I backslide, and then just hack my way through it.\n\nI found hg's conceptual model very easy to learn, almost as if I don't\nhave to remember anything.  Maybe that simplicity comes at a price,\nwhence my question at the start about the extreme-power features of\ngit.\n\n-Sanjoy\n\n`Never underestimate the evil of which men of power are capable.'\n"},{"id":"298772","messageId":"ek6kuq$dd8$1@sea.gmane.org","threadId":"43475","inReplyTo":"E1Gn1PG-0002oW-00@skye.ra.phy.cam.ac.uk","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-24T11:29:03Z","receivedAt":"2006-11-24T11:29:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sanjoy Mahajan wrote:\n\n> The car analogy is excellently clear.\n> \n>> they need more than the \"stupid simple\" git usage, but if they don't\n>> need the extreme power of git, Hg is simpler for people to learn how\n>> to use.\n> \n> As a 80%-hg/20%-git user, I'm curious what features of git you had in\n> mind, so I know where to look as I wander up the git learning curve.\n> \n> My experience with the git user interface, for what it's worth, is\n> that I never quite get the conceptual model crystal clear enough in my\n> head. So it won't stay for long enough for me to progress up the\n> learning curve and retain the gains.  I move up a bit, but the gain\n> soon evaporates and I backslide, and then just hack my way through it.\n> \n> I found hg's conceptual model very easy to learn, almost as if I don't\n> have to remember anything.  Maybe that simplicity comes at a price,\n> whence my question at the start about the extreme-power features of\n> git.\n\nAs I never used Mercurial (hg), only read a bit about it and discussed on\n#revctrl, I cannot say what features git has that hg has not, but I can\ntell what powerfull git features differ from other SCM.\n\nFirst, usually in other SCM the concept of branch is closely tied to the\nconcept of repository, perhaps allowing to share storage between branches\non the same local filesystem (on the same machine). In git, repository\nholds DAG, the graph of revisions (of versions). Branches are \"only\" ways\nto access this graph, and to extend it of the new commits. This makes git\nmore powerfull, but also perhaps unnecessary complicated if you deal with\nsingle-branch repositories, or few-branch case. Additionally this\n\"complication\" makes very clean model of repository - but you have to\nunderstand it...\n\nSecond, the index. One might think that it is performance hack, but it\nallows for commiting changes piece by piece and, what is more important,\na place form making merge in. Cogito (alternate Git UI/porcelain) tries to\nhide index. By the way, I wonder how hg does merges without index to\nprovide place where do merges in...\n\nThird, explicit/on-demand packing. This allows for the most (I think)\ncompression of all SCMs, and for the wire format to be the same as on-disk\nformat (with the addition that you can send thin packs on wire). As of now\nno porcelain tries to hide it, although with the latest work allowing for\nhistorical packs it would be easy to add this without significantly\naffecting preformance.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"}]}