{"thread":{"id":"30372","subject":"Newbie grief","startedAt":"2012-04-30T22:30:36Z","lastAt":"2012-05-04T22:05:19Z","messageCount":100,"participants":["Rich Pixley","Seth Robertson","Jan Krüger","Junio C Hamano","Sitaram Chamarty","Michael Witten","Ted Ts'o","Randal L. Schwartz","Andreas Ericsson","PJ Weisberg","Felipe Contreras","Philip Oakley","Philippe Vaucher","Hallvard Breien Furuseth","Jakub Narebski","Nathan Gray","Ronan Keryell","Illia Bobyr","Carlos Martín Nieto","Stephen Bash","Mark Brown","Jérôme Benoit","Andrew Sayers"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"190359","messageId":"4F9F128C.5020304@palm.com","threadId":"30372","inReplyTo":null,"subject":"Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-04-30T22:30:36Z","receivedAt":"2012-04-30T22:30:36Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"Hey. I'm a newbie struggling to understand git.\n\nI'm trying to do what seems like a simple thing in darcs, monotone, \nmecurial, gnu arch, etc, but seems nearly impossible in git. There's a \ncentral repository, a long ways away on the other side of the internet. \nSo I want a local repository cache. I'm going to be working on a number \nof different features and different machines all simultaneously so I \nreally don't want them all to be pulling from the central repository.\n\nIn other systems, this is a simple star network. Clone a repository, \nuse, push, pull, etc. But with git, I can't push unless the cache \nrepository is bare, but if the cache repository is bare, then a change \nto the central repository will cause the two to become wedged since \nneither can push or fetch the other. It seems that git is allergic to \nthe dual head branch solution or something, which is surprising and \ndisappointing.\n\nHow do other people address these situations in git?\n\n--rich\n"},{"id":"190373","messageId":"201204302331.q3UNVo7o032303@no.baka.org","threadId":"30372","inReplyTo":"4F9F128C.5020304@palm.com","subject":"Re: Newbie grief","fromName":"Seth Robertson","fromEmail":"in-gitvger@baka.org","sentAt":"2012-04-30T23:31:50Z","receivedAt":"2012-04-30T23:31:50Z","isPatch":false,"sender":{"key":"in-gitvger@baka.org","avatar":null},"body":"\nIn message <4F9F128C.5020304@palm.com>, Rich Pixley writes:\n\n Hey. I'm a newbie struggling to understand git.\n\n I'm trying to do what seems like a simple thing in darcs, monotone,\n mecurial, gnu arch, etc, but seems nearly impossible in git. There's a\n central repository, a long ways away on the other side of the internet.\n So I want a local repository cache. I'm going to be working on a number\n of different features and different machines all simultaneously so I\n really don't want them all to be pulling from the central repository.\n\nAre you working with anyone else locally? If not, then what you are\nprobably really trying to do is save time on fetches, so that the\nlatest changes are more likely to be nearby than far away.\n\nWhat I would do is set up a bare backup/--mirror repository of the\nupstream locally and have it automatically kept up to date with cron\nor something like that. Then you can have your pull URL point to this\nmirror and the push URL point to the real upstream. This will work as\nlong as the real upstream and the local mirror are not out of date (if\nthey are, you will be forbidden to push without either pulling from\nthe real upstream or wait for the next cron fetch and pull from your\nlocal mirror).\n\nThis works, but requires that you separate your fetch and push URLs.\nAnother option is to use git \"alternates\" to have your local\nrepository also look at the automatically updated repository so that\nyou would only fetch over-the-network-changes since the last automatic\nfetch (which, unless you had the cache have an alternate for the\nprimary repository, would mean that the changes would be transferred\ntwice).\n\nAlternates can be problematic if you start moving repositories around\nor delete them or whatever since the repository with the dangling\nalternate will then be bad (until the objects reappear one way or\nanother), so perhaps you just want a cron job to `git fetch` or `git\nremote update -p` in your local repository every so often. Then you\ncan just `git merge` or `git rebase` to get the latest changes instead\nof `git pull [--rebase]`. This is really the simplest solution. No\nextra repositories, no configuration changes, just straightforward git\noperations. The only trick would be race conditions between you (as a\nhuman) reviewing the latest changes and then typing the command to\nmerge/rebase them into your local branch and the cron job updating the\nremote—seeing what happened afterwords would of course work. I would\nprobably try this first and only start using the others if this became\nproblematic for some reason.\n\nNone of these cases specifically handles trying to automate pushes,\nmostly because it cannot always be automatically resolved (and\ndepending on local standards on running test suites before any change\nis pushed, perhaps should not ever be automatically resolved even for\ntrivial conflicts) if changes appear on the real upstream between your\nlast pull and your next push.\n\nCould it be done? Sure. You can push to your local upstream and then\nhave it push out automatically, but if there are conflicts you will\nneed to deal with them, and I would suggest doing so with a bare\nrepository, essentially by having a static preference for the\nreal-upstream's changes and have the cron job send mail to you telling\nyou to re-pull and re-push if it failed to push out due to the remote\nhaving changed (telling you the ref/SHA1 that it failed to push).\n\nOf course, this isn't *that* different from just sticking a `git push`\ninto the background which sends mail/notifies if the push failed for\nsome reason, and again doing so would be much easier than an\nintermediary repository solution.\n\n But with git, I can't push unless the cache repository is bare,\n but if the cache repository is bare, then a change to the central\n repository will cause the two to become wedged since neither can\n push or fetch the other.\n\nNot strictly speaking true. By default git will forbid pushes to\nnon-bare repositories (see receive.denyCurrentBranch in man\ngit-config) since without special automation the working directory\nwill get out of date. See http://bare-vs-nonbare.gitrecipes.de/ for\nmore information. However, I cannot think that having to perform\nintegration in this second repository would actually work.\n\n It seems that git is allergic to the dual head branch solution or\n something, which is surprising and disappointing.\n\nGit tracks your version of master separately from each other remote's\nmaster. This is exactly dual/multiple heads. What git *does* forbid\n(by default) is:\n\n1: Letting you update someone else's checked out (non-bare) repository\nunderneath them\n\n2: Letting you update someone else's repository if they have more\nrecent changes than you do.\n\nBoth of these defaults are really good ideas, but you can disable them\nif you think you know better.\n\n\t\t\t\t\t-Seth Robertson\n"},{"id":"190374","messageId":"4F9F21B8.9070506@jk.gs","threadId":"30372","inReplyTo":"4F9F128C.5020304@palm.com","subject":"Re: Newbie grief","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2012-04-30T23:35:20Z","receivedAt":"2012-04-30T23:35:20Z","isPatch":false,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Hi Rich,\n\nOn 05/01/2012 12:30 AM, Rich Pixley wrote:\n> I'm trying to do what seems like a simple thing in darcs, monotone,\n> mecurial, gnu arch, etc, but seems nearly impossible in git. There's a\n> central repository, a long ways away on the other side of the internet. \n> So I want a local repository cache. I'm going to be working on a number\n> of different features and different machines all simultaneously so I\n> really don't want them all to be pulling from the central repository.\n> \n> In other systems, this is a simple star network. Clone a repository,\n> use, push, pull, etc. But with git, I can't push unless the cache\n> repository is bare, but if the cache repository is bare, then a change\n> to the central repository will cause the two to become wedged since\n> neither can push or fetch the other.\n\nIf the 'cache repository' is set up using \"git clone --mirror\" and you\npush to the primary repository only, that makes the cache repo a\ndefinite slave, so you can always run \"git fetch\" on it without any\ntrouble. You can even enforce this by denying all pushes to the cache\nrepo, thus eliminating any chance of accidental misuse.\n\nConveniently, git allows you to specify a different URL for fetch and\npush in your local working repositories.\n\nHTH,\nJan\n"},{"id":"190378","messageId":"4F9F3919.6060805@palm.com","threadId":"30372","inReplyTo":"201204302331.q3UNVo7o032303@no.baka.org","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T01:15:05Z","receivedAt":"2012-05-01T01:15:05Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"Thank you for the info and the help. Just one argument...\n\nOn 4/30/12 16:31 , Seth Robertson wrote:\n> It seems that git is allergic to the dual head branch solution or\n> something, which is surprising and disappointing.\n>\n> Git tracks your version of master separately from each other remote's\n> master. This is exactly dual/multiple heads.\n\nNo, it isn't at all.\n\nMultiple heads are the idea that a single commit can \"branch\" in the \nrepository and that both commits can be HEADS of the same branch at once \nin a single repository. This allows a potential collision to exist in \nthe repository and to be pushed and pulled through multiple \nrepositories. It also largely eliminates this entire discussion since \neach of the intermediate repositories between, say, you and I can carry \nthe collision. Either you or I, at will, can merge these heads just \nlike we'd merge any other two commits, push/fetch, etc.\n\nThat would seem to be the obvious and intuitive behavior, rather than \narbitrarily preventing the transfer.\n\n > What git *does* forbid\n> (by default) is:\n>\n> 1: Letting you update someone else's checked out (non-bare) repository\n> underneath them\n\nYeah. That \"underneath them\" thing is confusing. I don't see any \nreason why that should necessarily be so.\n\nGit knows what commit is checked out. That's HEAD, yes? So what's \nwrong with letting it collect other commits from other repositories \nwhile your working directory sits? You can always commit your change \nright on top of what's checked out, creating a second head for that branch.\n\nYes, I've read that git-diff, etc, are all making assumptions that fail \nin this case, but there's nothing significantly different about \ncollecting commits to other branches and collecting commits to the \nbranch you're currently checked out from. Either way, you're going to \nneed to merge those into your working directory before committing your \ncurrent changes will make much semantic sense. And if you don't want to \ndo that, you can always commit them directly onto HEAD, and thereby \ncreate a new branch, at least temporarily. That's one of the huge \nadvantages of the daggy architecture.\n\n> 2: Letting you update someone else's repository if they have more\n> recent changes than you do.\n\nAgain, if they have more recent changes, then my line of changes should \ncreate a fresh HEAD on that branch. Then the repositories hold all of \nour changes to be merged at our leisure.\n\n From a UI perspective, that request has a valid, and relatively obvious \nsemantic. That git simply refuses to do anything except produce a \ncryptic error message seems... well, sad.\n\n> Both of these defaults are really good ideas, but you can disable them\n> if you think you know better.\n\nI know better for source code control systems that support the multiple \nHEAD concept. I don't know better for git. So far, it looks to me as \nthough git is just plain failing here.\n\nI thank you for your suggestions. It'll take me a few readings before I \nfollow them all. Regardless of how I think git _should_ behave, I'll \nstill need to figure something, so thank you.\n\n--rich\n"},{"id":"190379","messageId":"7vr4v4d6um.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"4F9F3919.6060805@palm.com","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-01T01:32:01Z","receivedAt":"2012-05-01T01:32:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rich Pixley writes:\n\n>> Git tracks your version of master separately from each other remote's\n>> master. This is exactly dual/multiple heads.\n>\n> No, it isn't at all.\n>\n> Multiple heads are the idea that a single commit can \"branch\" in the\n> repository and that both commits can be HEADS of the same branch at\n> once in a single repository. This allows a potential collision to\n> exist in the repository and to be pushed and pulled through multiple\n> repositories.\n\nI think your \"not at all\" thinking is a bit tainted by your knowing very\nwell how Hg does things, but I do not think there is much fundamental\ndifference between what we do. Git just tends to be a bit more explicit\nand encourages users to be also be more explicit.\n\nWhen you integrate from the other side (say, \"origin\") by pulling, instead\nof splitting the 'master' branch into two (i.e. ours and origin's), we\nstore what came from the origin in remotes/origin/master and let the user\nmerge it into his heads/master. Essentially, the same name 'master' is\nsplit into two, between remotes/origin/ and heads/ namespace. We are just\nmore explicitly about the split.\n\nSimilarly, when pushing, you could follow the same model by pushing your\nchange into remotes/pixley/master, instead of pushing directly to the\n\"master\" branch, i.e. heads/master, and then merge the former to the\nlatter after push succeeds.\n\nNeedless to say, you do not have to limit the splitting just to two.\nSince everything is named, you can tell where each 'master' came from by\nlooking at the namespace (obviously this requires people to establish and\nfollow the naming convention).\n"},{"id":"190380","messageId":"201205010137.q411bxaU002449@no.baka.org","threadId":"30372","inReplyTo":"4F9F28F5.2020403@palm.com","subject":"Re: Newbie grief","fromName":"Seth Robertson","fromEmail":"in-gitvger@baka.org","sentAt":"2012-05-01T01:37:59Z","receivedAt":"2012-05-01T01:37:59Z","isPatch":false,"sender":{"key":"in-gitvger@baka.org","avatar":null},"body":"\nIn message <4F9F28F5.2020403@palm.com>, Rich Pixley writes:\n\n On 4/30/12 16:31 , Seth Robertson wrote:\n > It seems that git is allergic to the dual head branch solution or\n > something, which is surprising and disappointing.\n >\n > Git tracks your version of master separately from each other remote's\n > master. This is exactly dual/multiple heads.\n No, it isn't at all.\n\n Multiple heads are the idea that a single commit can \"branch\" in the\n repository and that /both /commits can be HEADS of the same branch at\n once in a single repository. This allows a potential collision to exist\n in the repository and to be pushed and pulled through multiple\n repositories. It also largely eliminates this entire discussion since\n each of the intermediate repositories between, say, you and I can carry\n the collision. Either you or I, at will, can merge these heads just\n like we'd merge any other two commits, push, etc.\n\n That would seem to be the obvious and intuitive behavior, not\n arbitrarily preventing the transfer.\n\nI still don't see how git isn't providing this to you, with the caveat\nthat in git, a single commit with a specific SHA1 hash is constant.\nYou may modify it (making it a new commit), modify its history (making\nit a new commit), or add new commits after it. Git doesn't number\ncommits the way other VCS do, which may be the source of confusion.\n\nA specific commit with a specific SHA1 can be at the head of multiple\nbranches. Those branch may be local to the repository, local tracking\nbranches, or remote tracking branches.\n\nContrarywise, the head of the \"master\" (or any) branch (or ref) may\npoint to any SHA1. My master branch may point to one SHA1, yours may\npoint to another. You can look at my version of master and I can look\nat your version of master (permissions permitting). After appropriate\nnetwork operations, either you, or I, at will, can merge these heads\njust like we'd merge any other two commits, push, etc. With\nappropriate naming conventions, we can even continue parallel updates\nwhere I can make updates to your version of master and you can make\nupdates to my version of master, in addition to our own.\n\nFor example, in the diagram http://mercurial.selenic.com/wiki/Head\nrev2 might be your version of master and rev3 might be my version.\nBoth might exist in my repository and both might exist in your\nrepository, and both might have the symbolic name \"master\" associated\nwith it, and git would keep it entirely straight.\n\n > What git *does* forbid\n > (by default) is:\n >\n > 1: Letting you update someone else's checked out (non-bare) repository\n > underneath them\n Yeah. That \"underneath them\" thing is confusing. I don't see any\n reason why that should necessarily be so.\n\n Git knows what commit is checked out. That's HEAD, yes? So what's\n wrong with letting it collect other commits from other repositories\n while your working directory sits?\n\nIt does! It can! What is forbidden is for me update what you have\nchecked out. Can you conceive of a revision control system where I\ncommit I would make would change what you have checked out? (Well, I\ncan, ClearCase with dynamic views, and it is more horrible than you\ncan imagine—I've had compile fail because the files changed underneath\nmy feet between the start of the compile and the end of the compile).\nAnd what happens if the file I changed is also the file you are in the\nmiddle of changing? Is your change going to overwrite mine? Is mine\ngoing to overwrite yours? This way leads to insanity.\n\n You can always commit your change right on top of what's checked\n out, creating a second head for that branch.\n\nWith git, you must always commit your change right on top of what's\nchecked out, though of course you may decide to change what's checked\nout and \"float\" the changes you made over to the new head (trivial, as\nlong as there are not conflicts between the two heads and the changes\nyou made). However, only the user of the repository is allowed to do\nthis. A remote user is not allowed to change what's checked out.\n\n Yes, I've read that git-diff, etc, are all making assumptions that fail\n in this case, but there's nothing significantly different about\n collecting commits to other branches and collecting commits to the\n branch you're currently checked out from.\n\nYes there is. Consider this use case. You can I both spot DIFFERENT\nbugs. You and I both start editing filea. I fix my problem one way\nwhich involves lines 10, 100, and 500, you fix your problem which\ninvolves line 10, 100, and 200. I'm typing faster than you so I\ncommit/push first. If I can update your HEAD, at that point I've\nchanged the file you are editing. You save and my change is lost.\n\nNow this is where you say, if git only supported multiple HEADs the\nproblem would go away. I could update my version of master and you\ncould update your version of master and there would be no conflict.\nAnd...of course you can with git. I don't update your master, what\nyou have checked out, I update what you know is my master. Then when\nyou are done, you get to say \"merge my master with your master\" or\n\"instead of committing this change on my branch, let me try this last\nchange I made on top of the changes you made\" or whatever you want to\nsay.\n\n > 2: Letting you update someone else's repository if they have more\n > recent changes than you do.\n Again, if they have more recent changes, then my line of changes should\n create a fresh HEAD on that branch. Then the repositories hold all of\n our changes to be merged at our leisure.\n\nAnd...git does this. Your changes are made on your HEAD (your\nbranch). My changes are made on my HEAD (my branch). Never the twain\nshall meet until someone says \"merge\" (or \"rebase\").\n\nThe key to all of this is the namespace naming convention.\nrefs/remotes// (or more informally\n/) is a remote tracking branch, or my idea of\nwhat your branches (HEADs) currently are. These are (kinda/sorta)\nread-only reference which are only updated when you specifically ask\nthem to be updated, or if I decide to update what you believe I have\n(kinda rude, but allowed).\n\nSo let us consider a specific example. There is a repository which\neveryone call's \"Rich\" (they don't need to use the same name, but it\nreduces confusion), a repository everyone calls \"Seth\", and a central\nrepository everyone calls \"origin\".\n\nLocation Branchname\n-------- ----------\norigin foo\t\t(bare)\nrodger\t foo\nrodger\t origin/foo\nrodger\t seth/foo\nseth\t foo\nseth\t origin/foo\nseth\t rodger/foo\n\nI make a change in my foo. I can push the change into origin's foo,\nrodger's seth/foo (and technically origin/foo but that is more than\njust rude). You can take my change and store it in seth/foo.\n\nAt any point, after you have the changes (either because I push them\nor you fetch them) you can then merge your work with my work.\n\nSo...what's not possible?\n\n\t\t\t\t\t-Seth Robertson\n"},{"id":"190382","messageId":"4F9F427F.7000100@palm.com","threadId":"30372","inReplyTo":"7vr4v4d6um.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T01:55:11Z","receivedAt":"2012-05-01T01:55:11Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 4/30/12 18:32 , Junio C Hamano wrote:\n> Rich Pixley writes:\n>\n>>> Git tracks your version of master separately from each other remote's\n>>> master. This is exactly dual/multiple heads.\n>>\n>> No, it isn't at all.\n>>\n>> Multiple heads are the idea that a single commit can \"branch\" in the\n>> repository and that both commits can be HEADS of the same branch at\n>> once in a single repository. This allows a potential collision to\n>> exist in the repository and to be pushed and pulled through multiple\n>> repositories.\n>\n> I think your \"not at all\" thinking is a bit tainted by your knowing very\n> well how Hg does things,\n\nActually, I came up with the same design back in the early 90's when I \nwas working on CVS. I think the hg way of doing things is pretty \nobvious once we think about it. You can't expect users to do manual \nmerges on a remote server. So the only thing you can reasonably do is \ncollect and propagate the collision with enough info that a human being \ncan put it back together later. Refusing the commit doesn't seem \nreasonable to me.\n\nThe old approach from clearcase multisite where every repository owns \nit's own unique branch, which shows up as a read-only branch in the \nother repositories, is a nuisance because you have to constantly keep \nmerging or your geographic partitions drift. It's difficult enough to \nkeep disparate groups working in concert. Forcing them to do big merges \nin batch frequently doesn't help. That's essentially what we're reduced \nto with git.\n\nThe illusion that we're all working on the same branch, (mercurial, \nmonotone, etc), defaults to more frequent merges, and a much smaller \nchange tree when it comes to visualization.\n\n> but I do not think there is much fundamental\n> difference between what we do. Git just tends to be a bit more explicit\n> and encourages users to be also be more explicit.\n>\n> When you integrate from the other side (say, \"origin\") by pulling, instead\n> of splitting the 'master' branch into two (i.e. ours and origin's), we\n> store what came from the origin in remotes/origin/master and let the user\n> merge it into his heads/master. Essentially, the same name 'master' is\n> split into two, between remotes/origin/ and heads/ namespace. We are just\n> more explicitly about the split.\n\nI wouldn't call it explicit. That level of detail provides no features. \n It's tedious extra work that could have been tracked and managed \nautomatically. The fact that it isn't tracked and managed automatically \nprevents simple repository chaining of the sort I originally set out to \naccomplish.\n\n> Similarly, when pushing, you could follow the same model by pushing your\n> change into remotes/pixley/master, instead of pushing directly to the\n> \"master\" branch, i.e. heads/master, and then merge the former to the\n> latter after push succeeds.\n\nThat presupposes that I own both repositories rather than working in a \ncooperative environment.\n\n> Needless to say, you do not have to limit the splitting just to two.\n> Since everything is named, you can tell where each 'master' came from by\n> looking at the namespace (obviously this requires people to establish and\n> follow the naming convention).\n\nRight. This is the sort of thing people write source code control \nsystems to manage. :).\n\n--rich\n"},{"id":"190387","messageId":"4F9F52B9.9060508@palm.com","threadId":"30372","inReplyTo":"201205010137.q411bxaU002449@no.baka.org","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T03:04:25Z","receivedAt":"2012-05-01T03:04:25Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 4/30/12 18:37 , Seth Robertson wrote:\n> For example, in the diagram http://mercurial.selenic.com/wiki/Head\n> rev2 might be your version of master and rev3 might be my version.\n> Both might exist in my repository and both might exist in your\n> repository, and both might have the symbolic name \"master\" associated\n> with it, and git would keep it entirely straight.\n\nBut not in the same repository. And therein lies the issue.\n\n> > What git *does* forbid\n> > (by default) is:\n> >\n> > 1: Letting you update someone else's checked out (non-bare) repository\n> > underneath them\n> Yeah. That \"underneath them\" thing is confusing. I don't see any\n> reason why that should necessarily be so.\n>\n> Git knows what commit is checked out. That's HEAD, yes? So what's\n> wrong with letting it collect other commits from other repositories\n> while your working directory sits?\n>\n> It does! It can!\n\nTo the branch you have checked out? That's what I want! How do I do that?\n\n> What is forbidden is for me update what you have\n> checked out.\n\nThere's some ambiguity in your sentence here. I don't know whether \nyou're referring to my being forbidden from modifying your working \ndirectory or whether you're referring my being forbidden to modify the \nbranch from which your working directory is checked out. I understand \nand respect the former, but the latter seems arbitrary.\n\n(I think clearcase already answered the dynamic update problem. I liked \nit. And I especially liked clearmake and build avoidance. Shame that \nIBM killed it. (Oh, and if you had inconsistent builds, then you \nweren't using clearmake. Clearmake solved that problem.))\n\nI'm less concerned about whether my push changes your working directory. \n I'm fine with leaving your working directory as is and letting you \ndecide when and how to move forward on your own time.\n\nPerhaps part of the problem here is the unfortunate choice of the word \n\"HEAD\" to refer to the thing you have checked out when that commit might \nnot be a childless commit at all. When I say \"create another head\" I \nmean, \"create a childless commit on the same branch\".\n\n> You can always commit your change right on top of what's checked\n> out, creating a second head for that branch.\n>\n> With git, you must always commit your change right on top of what's\n> checked out, though of course you may decide to change what's checked\n> out and \"float\" the changes you made over to the new head (trivial, as\n> long as there are not conflicts between the two heads and the changes\n> you made). However, only the user of the repository is allowed to do\n> this. A remote user is not allowed to change what's checked out.\n\nOk, how do I ask git to push a commit into the middle of a branch that \nyou have checked out at a tip, (there's always exactly one tip for any \nbranch in git, right?)? I don't care to change your working directory \nnor your index. I just want my commits to show up in the middle of that \nbranch.\n\n> Yes, I've read that git-diff, etc, are all making assumptions that fail\n> in this case, but there's nothing significantly different about\n> collecting commits to other branches and collecting commits to the\n> branch you're currently checked out from.\n>\n> Yes there is. Consider this use case. You can I both spot DIFFERENT\n> bugs. You and I both start editing filea. I fix my problem one way\n> which involves lines 10, 100, and 500, you fix your problem which\n> involves line 10, 100, and 200. I'm typing faster than you so I\n> commit/push first. If I can update your HEAD, at that point I've\n> changed the file you are editing. You save and my change is lost.\n\n\"HEAD\", being defined as the thing I have checked out, should not be \nchanged, I agree.\n\nBut the nomenclature here is a bit misleading. Really, \"HEAD\" could be \nany commit. It doesn't have to be a childless commit. The fact that my \nHEAD was childless at the time I checked it out doesn't necessarily mean \nthat it must remain childless forever.\n\nLet's back it up a moment. I change file1 and you change file2. These \nare non-colliding changes. They can be trivially merged and yet git \nrefuses to push between our repositories.\n\nThe refusal seems arbitrary. It could just as easily accept my change, \nleave your HEAD pointing where it was, but move the \"master\" pointer to \npoint to the merged commit. This is exactly what it does if I pull your \nchanges into my repository. I just can't ever push them again after \nthis happens. (I could push them previously.)\n\n> Now this is where you say, if git only supported multiple HEADs the\n> problem would go away.\n\nRight.\n\n> I could update my version of master and you\n> could update your version of master and there would be no conflict.\n\nThere'd be a conflict. But we'd be able to update anyway. I'd be able \nto see your changes in my repository by default. You'd be able to see \nmine. And either one of us could merge, commit, and push the merge. \nUntil then, the collision could be carried and propagated by multiple \nrepositories around our repository network. Maybe a third person would \nintegrate them for us.\n\n> And...of course you can with git. I don't update your master, what\n> you have checked out, I update what you know is my master. Then when\n> you are done, you get to say \"merge my master with your master\" or\n> \"instead of committing this change on my branch, let me try this last\n> change I made on top of the changes you made\" or whatever you want to\n> say.\n\nYes. And I have no choice. I must say that at every repository I own, \nevery time I push or pull changes, tracking whether those have been \nmerged or not, even when 99% of my changes could have been trivially \nmerged, owned by me, in repositories I own. And I'm forced to do manual \nmerges and extra pulls in the most common collision situation I run \ninto, which can be handled automatically by other systems like \nmercurial, even subversion.\n\nMy problem is that I must necessarily manage 10's of repositories for my \nown work. These extra steps mean a geometric increase in complexity and \nin error potential over something like mercurial, which maintains the \n\"common branch\" illusion automatically for me or something like \nsubversion which genuinely has a common branch.\n\nI don't need separate branches for each repository. What I really want \nis a common branch whose changes I can push back and forth between the \nvarious repositories, or coordinate through a central cache, without \nworrying about the underlying details that git is forcing me to confront.\n\nI think I'm beginning to understand what git does offer now. Thank you \nfor the help with clarifications. I just don't like it. It's a huge \nlet down for me in my context from working with systems like mercurial \nwhich make my life easier. Quite frankly, git is a huge amount of work \nfor me by comparison to mercurial for no added benefit, or even by \ncomparison to subversion, with only minor benefits in most situations \nover subversion.\n\n> So...what's not possible?\n\nIn effect, any interesting activities involving push or any workflows \nthat require pushing. Most of them can probably be worked around by \nusing a pull architecture instead, but that adds an unnecessary \nexplosion of complexity in many cases such as the one I'm facing.\n\nIn particular, sharing a branch becomes problematic with git.\n\n--rich\n"},{"id":"190389","messageId":"CAMK1S_jwVsyKrGoL5uVAiuRrOa8bz79-DAueBmHZE2k=PpcJ2Q@mail.gmail.com","threadId":"30372","inReplyTo":"4F9F3919.6060805@palm.com","subject":"Re: Newbie grief","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-05-01T03:44:24Z","receivedAt":"2012-05-01T03:44:24Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"I've been reading the thread with interest.\n\nPeople who know far more than I do about git, its innards, and its\ndesign have been responding in this thread so consider this a git\n*user*'s point of view:\n\nOn Tue, May 1, 2012 at 6:45 AM, Rich Pixley wrote:\n\n> Multiple heads are the idea that a single commit can \"branch\" in the\n> repository and that both commits can be HEADS of the same branch at once in\n> a single repository.  This allows a potential collision to exist in the\n> repository and to be pushed and pulled through multiple repositories.  It\n\nThat is bizarre; I have no other word for it.\n\nI teach git (occasionally), and if this feature existed I would\ntotally ignore it in my teaching material because I wouldn't know how\nto defend or explain the need for \"hydra branches\".\n\nIt's like having two people with the same first name *and* last name\n(a situation that is not impossible in real life, but is rare and\nalmost always requires special handling).\n\nDoes Hg do this? That would explain why my (admittedly half-hearted)\nattempts to learn it have failed -- whatever tutorial I used must have\nbeen written with the idea that hydra branches are intuitive and\nlogical and sane, but did not express the concept as clearly and\nsuccinctly as you did.\n\nThanks for this insight; my next attempt to understand Hg, should I\never be forced into it, might actually succeed!\n"},{"id":"190397","messageId":"08704bd2e32343a4b9def80e4fa1efa2-mfwitten@gmail.com","threadId":"30372","inReplyTo":"4F9F52B9.9060508@palm.com","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2012-05-01T05:32:50Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote:\n\n> I don't need separate branches for each repository. What I really want \n> is a common branch whose changes I can push back and forth between the \n> various repositories, or coordinate through a central cache, without \n> worrying about the underlying details that git is forcing me to confront.\n\nHere's a start for a more precise discussion.\n\nSincerely,\nMichael Witten\n\n\nCache server:\n\n $ git clone --mirror \"$uri_for_central_repo\"\n\nMachine A:\n\n $ git clone \"$uri_for_cache_repo\"\n $ git checkout -b feature_0 origin/feature_0\n $ # ... do some work ...\n $ git push --set-upstream origin HEAD:shared/feature_0\n $ git config push.default upstream\n\nMachine B:\n\n $ git clone \"$uri_for_cache_repo\"\n $ git checkout -b feature_0 origin/feature_0\n $ # ... do some work that conflicts with work done on Machine A...\n $ git push --set-upstream origin HEAD:shared/feature_0\n To $uri_for_cache_repo\n ! [rejected] HEAD -> shared/feature_0 (non-fast-forward)\n error: failed to push some refs to '$uri_for_cache_repo'\n To prevent you from losing history, non-fast-forward updates were rejected\n Merge the remote changes (e.g. 'git pull') before pushing again. See the\n 'Note about fast-forwards' section of 'git push --help' for details.\n $ git pull origin shared/feature_0\n From $uri_for_cache_repo\n * branch shared/feature_0 -> FETCH_HEAD\n Auto-merging a\n CONFLICT (add/add): Merge conflict in a\n Recorded preimage for 'a'\n Automatic merge failed; fix conflicts and then commit the result.\n $ # ... resolve conflict and commit results ...\n $ git push --set-upstream origin HEAD:shared/feature_0\n $ git config push.default upstream\n\nMachine A:\n\n $ git pull # pulls in origin's shared/feature_0\n $ # ... do some work ...\n $ git push # pushes to origin's shared/feature_0\n\nMachine B:\n\n $ git pull # pulls in origin's shared/feature_0\n $ # ... do some work ...\n $ git push # pushes to origin's shared/feature_0\n\nMachine A:\n\n $ git pull\n $ git remote add central \"$uri_for_central_repo\"\n $ git push central HEAD:feature_0 # Assume there is a conflict\n To $uri_for_central_repo\n ! [rejected] HEAD -> feature_0 (non-fast-forward)\n error: failed to push some refs to '$uri_for_central_repo'\n To prevent you from losing history, non-fast-forward updates were rejected\n Merge the remote changes (e.g. 'git pull') before pushing again. See the\n 'Note about fast-forwards' section of 'git push --help' for details.\n $ git pull central feature_0\n $ # ... resolve conflict and commit results ...\n $ git push central HEAD:feature_0 # Assume it succeeds this time\n $ # Let's update the cache repo from Machine A:\n $ git fetch central\n $ git push origin 'refs/remotes/central/*:refs/heads/*'\n\nMachine B:\n\n $ git pull\n $ git pull . origin/feature_0 # Get new stuff cached from central server\n"},{"id":"190399","messageId":"7vvckgbew5.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"08704bd2e32343a4b9def80e4fa1efa2-mfwitten@gmail.com","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-01T06:21:14Z","receivedAt":"2012-05-01T06:21:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Witten writes:\n\n> Here's a start for a more precise discussion.\n\nWhen does the \"Cache server\" updated from the \"$uri_for_central_repo\" in\nthis picture? If it is after push by either from Machine A or B, somebody\nneeds to reconcile that and whatever A/B pushed.\n\nAnd between Hg style \"split head\" or Git style refs/remotes/* namespaces\nthere is no difference to perform that reconcilation. Somebody needs to\nrun \"merge\" on the \"Cache server\" and at some point the result needs to be\npushed to the $uri_for_central_repo back.\n\nSo...\n"},{"id":"190400","messageId":"CAMOZ1BvMB_Y74eK4Ca1HEzbqiGVCgKp=45Wiu=aQuTXOd-5UZQ@mail.gmail.com","threadId":"30372","inReplyTo":"7vvckgbew5.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2012-05-01T06:24:07Z","receivedAt":"2012-05-01T06:24:07Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Tue, May 1, 2012 at 06:21, Junio C Hamano wrote:\n> Michael Witten writes:\n>\n>> Here's a start for a more precise discussion.\n>\n> When does the \"Cache server\" updated from the \"$uri_for_central_repo\" in\n> this picture?  If it is after push by either from Machine A or B, somebody\n> needs to reconcile that and whatever A/B pushed.\n>\n> And between Hg style \"split head\" or Git style refs/remotes/* namespaces\n> there is no difference to perform that reconcilation.  Somebody needs to\n> run \"merge\" on the \"Cache server\" and at some point the result needs to be\n> pushed to the $uri_for_central_repo back.\n>\n> So...\n\nExamples of pushing to the central repo and updating the cache repo\nare given at the bottom.\n"},{"id":"190415","messageId":"20120501111415.GD5769@thunk.org","threadId":"30372","inReplyTo":"CAMK1S_jwVsyKrGoL5uVAiuRrOa8bz79-DAueBmHZE2k=PpcJ2Q@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2012-05-01T11:14:15Z","receivedAt":"2012-05-01T11:14:15Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote:\n> \n> > Multiple heads are the idea that a single commit can \"branch\" in the\n> > repository and that both commits can be HEADS of the same branch at once in\n> > a single repository.  This allows a potential collision to exist in the\n> > repository and to be pushed and pulled through multiple repositories.  It\n> \n> That is bizarre; I have no other word for it.\n> \n> I teach git (occasionally), and if this feature existed I would\n> totally ignore it in my teaching material because I wouldn't know how\n> to defend or explain the need for \"hydra branches\".\n\nI wouldn't use the verb branch (and certainly not \"hydra branch\"),\nbecause it's confusing to someone who thinks this has something to do\nwith noun \"branch\". But that's a confusion because of the english, or\nrather the terminology that was used.\n\nI would put it this way. Every non-merge commit has a parent (we'll\nignore merge commits for now). When you look at that commit via \"git\nshow \", what you see is the diff between its parent and the\nstate of the source tree as described by that commit-id. If you put\nit this way, it becomes obvious that a particular parent commit can\nhave multiple child commits. (This seems to be what you are calling\n\"hydra branches\".)\n\nA branch is a pointer to a commit. When you add a commit to a branch,\nyou are adding a new commit whose parent is pointing to the current\nbranch head, and afterwards, the branch head pointer is changed to\npoint at the new commit.\n\n> Does Hg do this? That would explain why my (admittedly half-hearted)\n> attempts to learn it have failed -- whatever tutorial I used must have\n> been written with the idea that hydra branches are intuitive and\n> logical and sane, but did not express the concept as clearly and\n> succinctly as you did.\n\nWhat Hg does is it requires that all terminal commits (commits that do\nnot have children) must be named by a branch pointer. So when you\npull in some changes from Hg, there may be a non-terminal commit, but\nbefore the hg pull finishes, it will create a merge commit which\nmerges the current branch pointer and the newly pulled in commits, so\nthat when you are done, the branch pointer points at the new merge\ncommit, and the requirement that there be no non-named terminal\ncommits is maintained.\n\nGit differs in that you can have a child commit which is not pointed\nto by a branch pointer, and which is referred to only by commit-id.\nThese child commits can disappear on you, when you do a garbage\ncollection; but it allows you to have multiple child commits hanging\noff of a single parent commit, and you can do diffs, cherry picks,\netc. But they *do* have a unique name --- the commit id, which is a\nSHA1 hash of the contents of the diff.\n\nDoes this help?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"190425","messageId":"CAMK1S_jN_WdZF4W4szzyJqLfC3FmnhKQ65XQiD-JS_jxwSm8_g@mail.gmail.com","threadId":"30372","inReplyTo":"20120501111415.GD5769@thunk.org","subject":"Re: Newbie grief","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-05-01T16:13:46Z","receivedAt":"2012-05-01T16:13:46Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Tue, May 1, 2012 at 4:44 PM, Ted Ts'o wrote:\n> On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote:\n>>\n>> > Multiple heads are the idea that a single commit can \"branch\" in the\n>> > repository and that both commits can be HEADS of the same branch at once in\n>> > a single repository.  This allows a potential collision to exist in the\n>> > repository and to be pushed and pulled through multiple repositories.  It\n>>\n>> That is bizarre; I have no other word for it.\n>>\n>> I teach git (occasionally), and if this feature existed I would\n>> totally ignore it in my teaching material because I wouldn't know how\n>> to defend or explain the need for \"hydra branches\".\n>\n> I wouldn't use the verb branch (and certainly not \"hydra branch\"),\n\nI coined that phrase for what was described as \"[multiple] HEADS of\nthe same branch at once in a single repository\".\n\n> it this way, it becomes obvious that a particular parent commit can\n> have multiple child commits.  (This seems to be what you are calling\n> \"hydra branches\".)\n\nNo. In git, the multiple child commits you mention are all either\ndifferent branches, tags, or they are detached/subject to GC. At no\ntime do you actually have the situation he was talking about: a single\nbranch representing more than one leaf (no children) commit *at the\nsame time*.\n\n> Git differs in that you can have a child commit which is not pointed\n> to by a branch pointer, and which is referred to only by commit-id.\n> These child commits can disappear on you, when you do a garbage\n> collection; but it allows you to have multiple child commits hanging\n> off of a single parent commit, and you can do diffs, cherry picks,\n> etc.  But they *do* have a unique name --- the commit id, which is a\n> SHA1 hash of the contents of the diff.\n\nSure.\n\nWhat the original poster wants is that all these unnamed commits be\nmagically associated with the branch they were born in, and be\npropagated via pushes and pulls.\n\nAs I understand it, he would like a one -> many relationship between\nbranch name and SHA.\n"},{"id":"190442","messageId":"4FA01D97.6040803@palm.com","threadId":"30372","inReplyTo":"7vvckgbew5.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T17:29:59Z","receivedAt":"2012-05-01T17:29:59Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 4/30/12 23:21 , Junio C Hamano wrote:\n> Michael Witten writes:\n>\n>> Here's a start for a more precise discussion.\n> When does the \"Cache server\" updated from the \"$uri_for_central_repo\" in\n> this picture? If it is after push by either from Machine A or B, somebody\n> needs to reconcile that and whatever A/B pushed.\n>\n> And between Hg style \"split head\" or Git style refs/remotes/* namespaces\n> there is no difference to perform that reconcilation. Somebody needs to\n> run \"merge\" on the \"Cache server\" and at some point the result needs to be\n> pushed to the $uri_for_central_repo back.\nUntrue. In the hg style, the reconciliation can happen at any \nrepository. Or never. It's completely legitimate to allow this \"split \nhead\" to become the beginning of a de facto branch. The only difference \nbetween a \"split head\" and a branch is whether the same branch pointer \npoints to both or whether they have different branch pointers. They can \neven have both.\n\n--rich\n"},{"id":"190443","messageId":"4FA01E53.7080005@palm.com","threadId":"30372","inReplyTo":"08704bd2e32343a4b9def80e4fa1efa2-mfwitten@gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T17:33:07Z","receivedAt":"2012-05-01T17:33:07Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 4/30/12 22:32 , Michael Witten wrote:\n> On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote:\n>\n>> I don't need separate branches for each repository. What I really want\n>> is a common branch whose changes I can push back and forth between the\n>> various repositories, or coordinate through a central cache, without\n>> worrying about the underlying details that git is forcing me to confront.\n> Here's a start for a more precise discussion.\nThank you. That might be just what I need in git.\n\n--rich\n"},{"id":"190455","messageId":"4FA0258D.4000908@palm.com","threadId":"30372","inReplyTo":"20120501111415.GD5769@thunk.org","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T18:03:57Z","receivedAt":"2012-05-01T18:03:57Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 04:14 , Ted Ts'o wrote:\n> On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote:\n>> Does Hg do this? That would explain why my (admittedly half-hearted)\n>> attempts to learn it have failed -- whatever tutorial I used must have\n>> been written with the idea that hydra branches are intuitive and\n>> logical and sane, but did not express the concept as clearly and\n>> succinctly as you did.\n>\n> What Hg does is it requires that all terminal commits (commits that do\n> not have children) must be named by a branch pointer.\n\nNo more so than git does. It's entirely possible to have commits that \nhave no branch pointer pointing to them.\n\n> So when you\n> pull in some changes from Hg, there may be a non-terminal commit, but\n> before the hg pull finishes, it will create a merge commit which\n> merges the current branch pointer and the newly pulled in commits, so\n> that when you are done, the branch pointer points at the new merge\n> commit, and the requirement that there be no non-named terminal\n> commits is maintained.\n\nNot so. What happens is that any commit to a non-terminal commit simply \nsucceeds and creates an additional childless commit. If the new commit \nhad a branch pointer, then it continues to have that branch pointer, \neven if another commit already has that branch pointer. There are just \nmultiple childless commits with that branch pointer.\n\nAny merges are initiated manually. But merging any other childless \ncommits is the default for \"hg merge\". (And merge commits have two \nparents).\n\nThe only merges that are done automatically are the same ones that git \ndoes on a pull. These are sort of degenerate merges in the sense that \nthey exist entirely in the source code repository graph, there are no \nlexical or file content collisions.\n\nIn hg, I can have revision 1 checked out, you can push, (or I can pull), \nrevisions 2, 3, and 4 into my repository, and my next update will merge \n2, 3, and 4 into my current working directory, much like with \nsubversion. In git, your push is refused and I can only fetch if I'm \nalso willing to merge at that very moment.\n\n> Git differs in that you can have a child commit which is not pointed\n> to by a branch pointer, and which is referred to only by commit-id.\n\nHg can do this too.\n\n> These child commits can disappear on you, when you do a garbage\n> collection; but it allows you to have multiple child commits hanging\n> off of a single parent commit, and you can do diffs, cherry picks,\n> etc. But they *do* have a unique name --- the commit id, which is a\n> SHA1 hash of the contents of the diff.\n\nSame with hg, except that they are persistent and don't disappear on \ngarbage collection.\n\n--rich\n"},{"id":"190457","messageId":"4FA02830.3040407@palm.com","threadId":"30372","inReplyTo":"CAMK1S_jN_WdZF4W4szzyJqLfC3FmnhKQ65XQiD-JS_jxwSm8_g@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T18:15:12Z","receivedAt":"2012-05-01T18:15:12Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 09:13 , Sitaram Chamarty wrote:\n> On Tue, May 1, 2012 at 4:44 PM, Ted Ts'o wrote:\n>> I wouldn't use the verb branch (and certainly not \"hydra branch\"),\n> I coined that phrase for what was described as \"[multiple] HEADS of\n> the same branch at once in a single repository\".\n...keeping in mind here that HEAD is a misnomer as HEAD points to the \ncurrently checked out commit, regardless of where that commit might live \nin the commit graph. It might be childless, but it might have children.\n\nWhat I'm talking about is the situation where a branch can have \nmultiple, childless commits. I've switched to calling these \"tips\" for \nthis discussion.\n> Sure. What the original poster wants is that all these unnamed commits \n> be magically associated with the branch they were born in, and be \n> propagated via pushes and pulls. As I understand it, he would like a \n> one -> many relationship between branch name and SHA.\nReally, what I want is for the push semantic to have a meaning. I want \npush to work. I want pull to work even without merging. I want to be \nable to share a branch between different repositories and different \nusers while the source code control system tracks this for me. And I \nwant to create arbitrary network graphs of repositories who all share \ncode via push/pull without manual intervention.\n\nThese are facilities that we've had in other source code control systems \nfor at least a decade.\n\nIt seems as though git is tracking all of the info that is needed - \nexcepting multiple tips. The fact that there are converters, including \ndynamic, real time converters, between git repositories and the hg user \ninterface suggest that there is, indeed, a near one-to-one mapping \nbetween mercurial and git. The only thing that's missing in git is the \nuser interface to provide this semantic. Instead, git simply doesn't do \nwhat it is asked to do, which seems like a silly user interface choice.\n\n--rich\n"},{"id":"190458","messageId":"CAMOZ1Bue4r7aP75xaeKkFC08WfOqD8O41pkSQGx7RSbW5xWcdg@mail.gmail.com","threadId":"30372","inReplyTo":"4FA02830.3040407@palm.com","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2012-05-01T18:20:56Z","receivedAt":"2012-05-01T18:20:56Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Tue, May 1, 2012 at 18:15, Rich Pixley wrote:\n\n> I want pull to work even without merging.  I want to be able to share a\n> branch between different repositories and different users while the source\n> code control system tracks this for me\n\nI believe you are missing the point that a `pull' in git is a `fetch'\nfollowed by a `merge'. You should read about the `fetch' command by\nreading (`git help fetch'), and make sure you understand how to use\nrefspecs; you will probably find it very instructive to play around\nby specifying explicit refspecs to `git fetch' rather than relying\non the implicit rules (which can be somewhat confusing).\n"},{"id":"190460","messageId":"86havzoi8h.fsf@red.stonehenge.com","threadId":"30372","inReplyTo":"4FA02830.3040407@palm.com","subject":"Re: Newbie grief","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2012-05-01T18:42:54Z","receivedAt":"2012-05-01T18:42:54Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Rich\" == Rich Pixley writes:\n\nRich> What I'm talking about is the situation where a branch can have multiple,\nRich> childless commits. I've switched to calling these \"tips\" for this\nRich> discussion.\n\nBut in git, a branch *is* what you're calling a \"tip\".\n\nWhat do you find lacking about git branches, in terms of sharing?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"190463","messageId":"4FA030D1.5030301@palm.com","threadId":"30372","inReplyTo":"CAMOZ1Bue4r7aP75xaeKkFC08WfOqD8O41pkSQGx7RSbW5xWcdg@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T18:52:01Z","receivedAt":"2012-05-01T18:52:01Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 11:20 , Michael Witten wrote:\n> On Tue, May 1, 2012 at 18:15, Rich Pixley wrote:\n>\n>> I want pull to work even without merging. I want to be able to share a\n>> branch between different repositories and different users while the source\n>> code control system tracks this for me\n>\n> I believe you are missing the point that a `pull' in git is a `fetch'\n> followed by a `merge'. You should read about the `fetch' command by\n> reading (`git help fetch'), and make sure you understand how to use\n> refspecs; you will probably find it very instructive to play around\n> by specifying explicit refspecs to `git fetch' rather than relying\n> on the implicit rules (which can be somewhat confusing).\n\nYes, I'm aware of the distinction within git. Confusing is an \nunderstatement. It seems that in most cases git has no defaults nor \nimplicit rules and when it does, they are frequently surprising or \nunfathomable. I suppose it's nice that they can be set explicitly, but \nsad that they pretty much must be.\n\nThat git uses the word \"pull\" to mean something different than previous \nsource code control systems only adds to the confusion. I was using \n\"pull\" in the more general sense of pushing and pulling data, not in the \nvery narrow meaning of \"git fetch + git merge\".\n\nI'm still pretty much lost on refspecs and refs. The terms are \napparently not used in the manuals I've been reading and they don't seem \nto be used consistently even within git error messages.\n\nIs \"refspec\" the git word for the branch pointer that points to the \nchildless commit that defines a branch?\n\n--rich\n"},{"id":"190464","messageId":"4FA03277.7040006@palm.com","threadId":"30372","inReplyTo":"4F9F21B8.9070506@jk.gs","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T18:59:03Z","receivedAt":"2012-05-01T18:59:03Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 4/30/12 16:35 , Jan Krüger wrote:\n> Hi Rich,\n>\n> On 05/01/2012 12:30 AM, Rich Pixley wrote:\n>> I'm trying to do what seems like a simple thing in darcs, monotone,\n>> mecurial, gnu arch, etc, but seems nearly impossible in git. There's a\n>> central repository, a long ways away on the other side of the internet.\n>> So I want a local repository cache. I'm going to be working on a number\n>> of different features and different machines all simultaneously so I\n>> really don't want them all to be pulling from the central repository.\n>>\n>> In other systems, this is a simple star network. Clone a repository,\n>> use, push, pull, etc. But with git, I can't push unless the cache\n>> repository is bare, but if the cache repository is bare, then a change\n>> to the central repository will cause the two to become wedged since\n>> neither can push or fetch the other.\n> If the 'cache repository' is set up using \"git clone --mirror\" and you\n> push to the primary repository only, that makes the cache repo a\n> definite slave, so you can always run \"git fetch\" on it without any\n> trouble. You can even enforce this by denying all pushes to the cache\n> repo, thus eliminating any chance of accidental misuse.\n>\n> Conveniently, git allows you to specify a different URL for fetch and\n> push in your local working repositories.\nThank you.\n\nFor completeness, Michael Witten posted details for a comparable \narchitecture where the data flow is in the other direction. Leaf \nrepositories push/pull to/from the cache, pull from the central \nrepository in order to merge changes, then push to the cache to share \nlocally. Eventually, some leaf repository will push to the central.\n\nMichael's approach has the advantage that the cache repository can be \nunattended and that my changes can be circulated locally before becoming \nvisible to the wider, central repository audience.\n\nBoth approaches cleverly avoid potential collisions in the cache \nrepository by working around them. And, of course, some combinations of \nthe two will work too.\n\n--rich\n"},{"id":"190479","messageId":"4FA04D02.6090702@palm.com","threadId":"30372","inReplyTo":"86havzoi8h.fsf@red.stonehenge.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T20:52:18Z","receivedAt":"2012-05-01T20:52:18Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 11:42 , Randal L. Schwartz wrote:\n>>>>>> \"Rich\" == Rich Pixley writes:\n>\n> Rich> What I'm talking about is the situation where a branch can have multiple,\n> Rich> childless commits. I've switched to calling these \"tips\" for this\n> Rich> discussion.\n>\n> But in git, a branch *is* what you're calling a \"tip\".\n\nAnd therein lies the problem.\n\n> What do you find lacking about git branches, in terms of sharing?\n\nA number of situations. But the short answer is that git completely \nlacks the ability to cope with potential collisions in the repository - \neven collisions that can be handled completely automatically, even when \nthe collision can be handled completely in the repository graph, (as \ndistinct from lexical or file content resolutions).\n\nI want to be able to fetch changes to the branch I currently have \nchecked out. Git blocks this because it doesn't know how to cope with \nthe working directory in that situation. Merging is straightforward. \nEven updating, (checkout), is fairly straightforward. But the \ninsistence on a single tip means that if I commit directly to a non-tip \ncommit, git doesn't know what to do with the branch pointer. If it \nleaves it at my commit, then the other changes are essentially orphaned. \n If it leaves it at the other changes, then my commit is essentially \norphaned. While it's probably possible to force git to do this anyway, \nincluding orphaning one set of changes, doing so is of limited value \nsince the git interface makes the assumption that branches have a single \ntip anyway.\n\nPushing is blocked in git. Git simply refuses some push requests which \nhave obvious and fairly straightforward semantics. There are ways in \ngit to accomplish the more general task of information exchange by \nreversing the initiation request, (pulling), by partitioning the data \ninto branches, etc. But the straightforward, intuitive request to push \nis, in git, frequently blocked for no particular reason. (Pushes are \nanalogous to the previous situation of fetching to my current branch.)\n\nYou and I want to share a branch and we each have local, unattended \ncache/mirror repositories that we would like to use to pass data between \nus. This doesn't work in git because the first time you and I make \nsimultaneous changes, whether they collide or not, the unattended \nrepositories become wedged. They each refuse to talk to the other until \nsomeone manually unwedges them.\n\nI want that if you and say, Sitaram commit conflicting changes to a \nshared branch, it's easy for me to recognize that the conflict exist and \neasy for me to resolve that conflict in my own repository. I want the \nsource code control system to keep track of those things, show them to \nme/us, and to track and show my resolution to you. This stuff should \nall be automatic. It shouldn't require explicit testing, manual \npulling, nor explicit discussion between the three of us. It shouldn't \nprohibit that either, but it shouldn't require it.\n\nThese are all fairly common situations today. And it wouldn't be so bad \nif nothing else solved these problems either. But we've had source code \ncontrol solutions that solved all of these issues for over a decade now. \n Going backwards to git seems like a pain in that context.\n\n--rich\n"},{"id":"190486","messageId":"86mx5rmx32.fsf@red.stonehenge.com","threadId":"30372","inReplyTo":"4FA04D02.6090702@palm.com","subject":"Re: Newbie grief","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2012-05-01T21:05:05Z","receivedAt":"2012-05-01T21:05:05Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Rich\" == Rich Pixley writes:\n\nRich> I want to be able to fetch changes to the branch I currently have checked out.\nRich> Git blocks this because it doesn't know how to cope with the working directory\nRich> in that situation.\n\nIt does? I can always \"git fetch origin\" in my repo, and the remote\nbranches are in \"origin/master, origin/foo, origin/bar\". Totally\nseparate from my working tree.\n\nIf I want to *examine* them, I can make a WIP commit, or use \"git\nstash\", and then check them out headless:\n\n git stash save\n git checkout origin/master\n ## examine\n ## now go back\n git checkout master\n git stash pop\n\nand now I can see what the upstream looks like. Or just diff them:\n\n git diff ..origin/master\n\nRich> Merging is straightforward. Even updating, (checkout), is fairly\nRich> straightforward. But the insistence on a single tip means that if\nRich> I commit directly to a non-tip commit, git doesn't know what to do\nRich> with the branch pointer. If it leaves it at my commit, then the\nRich> other changes are essentially orphaned. If it leaves it at the\nRich> other changes, then my commit is essentially orphaned. While it's\nRich> probably possible to force git to do this anyway, including\nRich> orphaning one set of changes, doing so is of limited value since\nRich> the git interface makes the assumption that branches have a single\nRich> tip anyway.\n\nSo, make a set of related names for your branches. It's better with\nnames anyway.\n\nRich> Pushing is blocked in git. Git simply refuses some push requests\nRich> which have obvious and fairly straightforward semantics.\n\n git push master:from-merlyn/master\n\nAnd now someone can look at \"from-merlyn/master\", and know that it's\nfrom me, and related to master, and either incorporate it into the real\nmaster, or cherry-pick from it, or whatever. Solved.\n\nRich> You and I want to share a branch and we each have local,\nRich> unattended cache/mirror repositories that we would like to use to\nRich> pass data between us. This doesn't work in git because the first\nRich> time you and I make simultaneous changes, whether they collide or\nRich> not, the unattended repositories become wedged. They each refuse\nRich> to talk to the other until someone manually unwedges them.\n\nNo, you do it like above. Some *person* has to sign off the merge each\ntime. But we can share the unmerged changeset through other branches.\n\nRich> I want that if you and say, Sitaram commit conflicting changes to\nRich> a shared branch, it's easy for me to recognize that the conflict\nRich> exist and easy for me to resolve that conflict in my own\nRich> repository. I want the source code control system to keep track\nRich> of those things, show them to me/us, and to track and show my\nRich> resolution to you. This stuff should all be automatic. It\nRich> shouldn't require explicit testing, manual pulling, nor explicit\nRich> discussion between the three of us. It shouldn't prohibit that\nRich> either, but it shouldn't require it.\n\nYou're asking a lot of an automated system. I think you're trying to\nget a system to replace the communication you should be doing as a\ndeveloper.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"190489","messageId":"7v62cf8v2d.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"86mx5rmx32.fsf@red.stonehenge.com","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-01T21:12:26Z","receivedAt":"2012-05-01T21:12:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Rich> I want that if you and say, Sitaram commit conflicting changes to\n> Rich> a shared branch, it's easy for me to recognize that the conflict\n> Rich> exist and easy for me to resolve that conflict in my own\n> Rich> repository. I want the source code control system to keep track\n> Rich> of those things, show them to me/us, and to track and show my\n> Rich> resolution to you. This stuff should all be automatic. It\n> Rich> shouldn't require explicit testing, manual pulling, nor explicit\n> Rich> discussion between the three of us. It shouldn't prohibit that\n> Rich> either, but it shouldn't require it.\n>\n> You're asking a lot of an automated system. I think you're trying to\n> get a system to replace the communication you should be doing as a\n> developer.\n\nWhile what Merlyn says is always right ;-), you could automate things by\nhaving your post-receive hook to notice that remotes/from-merlyn/master\nlocation was updated, attempt an automerge, and then report a failure.\n\nNot everybody wants such an automated system, so there is no such\ncomplexity in the vanilla setting, but the important thing is that whoever\nneeds such a complexity could easily do so.\n"},{"id":"190490","messageId":"4FA054BA.80601@palm.com","threadId":"30372","inReplyTo":"7v62cf8v2d.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T21:25:14Z","receivedAt":"2012-05-01T21:25:14Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 14:12 , Junio C Hamano wrote:\n> merlyn@stonehenge.com (Randal L. Schwartz) writes:\n>\n>> Rich> I want that if you and say, Sitaram commit conflicting changes to\n>> Rich> a shared branch, it's easy for me to recognize that the conflict\n>> Rich> exist and easy for me to resolve that conflict in my own\n>> Rich> repository. I want the source code control system to keep track\n>> Rich> of those things, show them to me/us, and to track and show my\n>> Rich> resolution to you. This stuff should all be automatic. It\n>> Rich> shouldn't require explicit testing, manual pulling, nor explicit\n>> Rich> discussion between the three of us. It shouldn't prohibit that\n>> Rich> either, but it shouldn't require it.\n>>\n>> You're asking a lot of an automated system. I think you're trying to\n>> get a system to replace the communication you should be doing as a\n>> developer.\n>\n> While what Merlyn says is always right ;-), you could automate things by\n> having your post-receive hook to notice that remotes/from-merlyn/master\n> location was updated, attempt an automerge, and then report a failure.\n>\n> Not everybody wants such an automated system, so there is no such\n> complexity in the vanilla setting, but the important thing is that whoever\n> needs such a complexity could easily do so.\n\nI think we have different definitions of \"easily\". This is simple, \nfirst use sorts of stuff. I've already invested weeks in trying to \nunderstand git enough to use it and I still don't have a process I like, \nmuch less do I know how to write a post-receive hook. I'm sure I could, \ngiven enough time. But frankly, I could switch to a different source \ncode control system in less time.\n\nSimple things should be simple. They shouldn't require in-depth \nknowledge and customization of the tool.\n\nIn other systems, the automation is optional, but it's available. If \nyou want to vet each and every change as you take it, you can. But you \ndon't have to.\n\n--rich\n"},{"id":"190491","messageId":"86ipgfmw05.fsf@red.stonehenge.com","threadId":"30372","inReplyTo":"4FA054BA.80601@palm.com","subject":"Re: Newbie grief","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2012-05-01T21:28:26Z","receivedAt":"2012-05-01T21:28:26Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Rich\" == Rich Pixley writes:\n\nRich> I think we have different definitions of \"easily\". This is\nRich> simple, first use sorts of stuff.\n\nHave you read the Pro Git book?\n\nHave you read the gitcore-tutorial page?\n\nHave you read the gitworkflows manpage?\n\nThe processes for \"simple, first use\" sorts of stuff never gets into\nthe complexity you are describing. You're definitely into more advanced\nstuff and then complain when you also need to be more advanced to set it\nup. Not sure what your goal is, then.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"190492","messageId":"4FA055D0.7040102@palm.com","threadId":"30372","inReplyTo":"86mx5rmx32.fsf@red.stonehenge.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T21:29:52Z","receivedAt":"2012-05-01T21:29:52Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 14:05 , Randal L. Schwartz wrote:\n>>>>>> \"Rich\" == Rich Pixley writes:\n>\n> Rich> I want to be able to fetch changes to the branch I currently have checked out.\n> Rich> Git blocks this because it doesn't know how to cope with the working directory\n> Rich> in that situation.\n>\n> It does?\n\nYes, it does.\n\n> I can always \"git fetch origin\" in my repo, and the remote\n> branches are in \"origin/master, origin/foo, origin/bar\". Totally\n> separate from my working tree.\n\nSure. You can fetch other branches, (unless you happen to be checked \nout from them). But you can't fetch to master if you're checked out \nfrom master.\n\n> So, make a set of related names for your branches. It's better with\n> names anyway.\n\nI disagree. They only even need branches if they're different. And the \nbranches can be extremely lightweight. With names, I have to manually \ntrack a geometric explosion of extraneous branches and branch names, \njust in order to be able to sync changes back and forth. That's all \nwork that could be managed automatically by the source code control system.\n\n> Rich> Pushing is blocked in git. Git simply refuses some push requests\n> Rich> which have obvious and fairly straightforward semantics.\n>\n> git push master:from-merlyn/master\n>\n> And now someone can look at \"from-merlyn/master\", and know that it's\n> from me, and related to master, and either incorporate it into the real\n> master, or cherry-pick from it, or whatever. Solved.\n\nAgain, yes, you can push to other branches. You could push to other \nrepositories too. That's not really what I'm talking about.\n\n> You're asking a lot of an automated system. I think you're trying to\n> get a system to replace the communication you should be doing as a\n> developer.\n\nI hear that that's what you think. But really, I'm asking for \nautomation to replace the automation I already have in preexisting \nsource code control systems.\n\nThere are a number of situations, like the ones I've described, that git \njust plain doesn't cope well with. Other source code control systems \nhave, and going backwards seems silly and frustrating.\n\nMy particular situation is that I'm developing a \"feature\" and to do \nthat, I need to be testing on multiple machines. Tens of them. I \nreally don't want hundreds of named branches that I must manually merge \nfrom constantly.\n\nWith mercurial or monotone or even subversion, it's trivial. Branches \ncan be shared. And pushing between them is similarly trivial. It can \nbe done in seconds. With git, it takes hours to do all the manual \nmoves, track the manual moves manually, verify that they've been done \ncorrectly, and then later it takes hours to correct the ones that were \ndone incorrectly because they were all done manually or because one \nmachine happened to be down at the time and so got the changes in the \nwrong order, or whatever.\n\nI'm not asking for anything new. I'm asking for something that's as \ncapable as what we've had for years now.\n\n--rich\n"},{"id":"190493","messageId":"86aa1rmvhb.fsf@red.stonehenge.com","threadId":"30372","inReplyTo":"4FA055D0.7040102@palm.com","subject":"Re: Newbie grief","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2012-05-01T21:39:44Z","receivedAt":"2012-05-01T21:39:44Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Rich\" == Rich Pixley writes:\n\n>> I can always \"git fetch origin\" in my repo, and the remote\n>> branches are in \"origin/master, origin/foo, origin/bar\". Totally\n>> separate from my working tree.\n\nRich> Sure. You can fetch other branches, (unless you happen to be\nRich> checked out from them). But you can't fetch to master if you're\nRich> checked out from master.\n\nNo, you are still missing it.\n\n\"git fetch\" updates the remote tracking branches, which you commonly\nreference preceded by \"origin\". So \"git fetch\" DOES NOT TOUCH \"master\".\nIt touches only \"origin/master\".\n\nOnly when you merge that remote in to your local master do you need to\nworry about dirty trees or broken merges.\n\nRich> My particular situation is that I'm developing a \"feature\" and to\nRich> do that, I need to be testing on multiple machines. Tens of them.\n\nI think you're now confusing git with a deploy system. That is also\nsomething that will lead you to unnecessary grief. Pick a deploy system\nthat's not git, and integrate git with it.\n\nRich> I really don't want hundreds of named branches that I must\nRich> manually merge from constantly.\n\nI don't see how you would end up with this.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"190495","messageId":"4FA05C66.2060608@palm.com","threadId":"30372","inReplyTo":"86ipgfmw05.fsf@red.stonehenge.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T21:57:58Z","receivedAt":"2012-05-01T21:57:58Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 14:28 , Randal L. Schwartz wrote:\n>>>>>> \"Rich\" == Rich Pixley writes:\n>\n> Rich> I think we have different definitions of \"easily\". This is\n> Rich> simple, first use sorts of stuff.\n>\n> Have you read the Pro Git book?\n\nYes. The things it covers, it mostly covers well. But it's lacking a lot.\n\nThere's nothing in it about repository networks, how to get stuff out of \nmy index, reset, and it's not very good about explaining that things \nlike rebase screw up your repository in ways that make sharing \nimpossible. I know that because of how mercurial works and from reverse \nengineering what must be required, not from reading git doc.\n\nAnd I've spent close to a week now trying to use git on this project, \nthrowing away repositories, patching by hand, and trying to sort out why \ngit was refusing to push for me. That wasn't explained at all nor do \nthe git error messages explain what's happening.\n\n> Have you read the gitcore-tutorial page?\n\nNot recently. It was pretty much impenetrable the first few times \nthrough. I was looking for how to use git, I wasn't interested in all \nof the gory details of how it stored everything.\n\nJust skimmed again. Will need to read it again more thoroughly, though \nI don't see anything on the stuff we've been discussing.\n\n> Have you read the gitworkflows manpage?\n\nYes, but not in a long time. It seems to be more about the policies of \nworking on git source code than about usage of git.\n\n> The processes for \"simple, first use\" sorts of stuff never gets into\n> the complexity you are describing. You're definitely into more advanced\n> stuff and then complain when you also need to be more advanced to set it\n> up. Not sure what your goal is, then.\n\nThis stuff isn't advanced anymore. It's kind of standard. My complaint \nis that doing standard stuff like this shouldn't require advanced work.\n\nI have days, weeks into git learning curve so far, I've clearly only \nbegun, and I have a big list of things I still can't do in git, though I \ncan do them in other source code control systems. In contrast, I was up \nand using mercurial in about a day and a half, including all of the \nstuff we've discussed, and all of the things I've even read about in \ngit. Learning mq's only took about 20 minutes.\n\n--rich\n"},{"id":"190497","messageId":"4FA05E9F.9090709@palm.com","threadId":"30372","inReplyTo":"86aa1rmvhb.fsf@red.stonehenge.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-01T22:07:27Z","receivedAt":"2012-05-01T22:07:27Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 14:39 , Randal L. Schwartz wrote:\n>>>>>> \"Rich\" == Rich Pixley writes:\n>\n>>> I can always \"git fetch origin\" in my repo, and the remote\n>>> branches are in \"origin/master, origin/foo, origin/bar\". Totally\n>>> separate from my working tree.\n>\n> Rich> Sure. You can fetch other branches, (unless you happen to be\n> Rich> checked out from them). But you can't fetch to master if you're\n> Rich> checked out from master.\n>\n> No, you are still missing it.\n>\n> \"git fetch\" updates the remote tracking branches, which you commonly\n> reference preceded by \"origin\". So \"git fetch\" DOES NOT TOUCH \"master\".\n> It touches only \"origin/master\".\n\nYes. I understand that that is how git typically works in a non-bare \nrepository.\n\nDo you understand what I'm saying?\n\n> Only when you merge that remote in to your local master do you need to\n> worry about dirty trees or broken merges.\n>\n> Rich> My particular situation is that I'm developing a \"feature\" and to\n> Rich> do that, I need to be testing on multiple machines. Tens of them.\n>\n> I think you're now confusing git with a deploy system. That is also\n> something that will lead you to unnecessary grief. Pick a deploy system\n> that's not git, and integrate git with it.\n\nNo, not a deploy system. You use a deploy system to set up something \nlike multiple server http farms. What I'm doing is more akin to porting \nthe same piece of software to 20 different operating system \ndistributions. I'm not \"deploying\" the source code. I'm developing it.\n\nThank you for acknowledging that git is a poor match for this scenario, \nthough.\n\n> Rich> I really don't want hundreds of named branches that I must\n> Rich> manually merge from constantly.\n>\n> I don't see how you would end up with this.\n\nYup. I'm beginning to see that.\n\n--rich\n"},{"id":"190498","messageId":"4FA060DD.9030208@op5.se","threadId":"30372","inReplyTo":"4FA05E9F.9090709@palm.com","subject":"Re: Newbie grief","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-05-01T22:17:01Z","receivedAt":"2012-05-01T22:17:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 05/02/2012 12:07 AM, Rich Pixley wrote:\n> On 5/1/12 14:39 , Randal L. Schwartz wrote:\n>> \n>> Rich> My particular situation is that I'm developing a \"feature\"\n>> and to do that, I need to be testing on multiple machines.\n>> Tens of them.\n>> \n>> I think you're now confusing git with a deploy system. That is\n>> also something that will lead you to unnecessary grief. Pick a\n>> deploy system that's not git, and integrate git with it.\n> \n> No, not a deploy system. You use a deploy system to set up something\n> like multiple server http farms. What I'm doing is more akin to\n> porting the same piece of software to 20 different operating system\n> distributions. I'm not \"deploying\" the source code. I'm developing\n> it.\n> \n> Thank you for acknowledging that git is a poor match for this\n> scenario, though.\n> \n\nGit works well for that if you put hooks in place to trigger builds\nand test-runs on the testservers though. We do exactly that, and I\ndoubt we're the only ones who do automated testing of every push.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"190502","messageId":"CAMOZ1BuiznhrzEOHe0N+uu=mLEw5wWTQyDpnwG8PuF1f_aNaXw@mail.gmail.com","threadId":"30372","inReplyTo":"4FA05C66.2060608@palm.com","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2012-05-01T22:56:29Z","receivedAt":"2012-05-01T22:56:29Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Tue, May 1, 2012 at 9:57 PM, Rich Pixley wrote:\n\n> In contrast, I was up and using mercurial in about a day and a half,\n> including all of the stuff we've discussed, and all of the things I've even\n> read about in git.  Learning mq's only took about 20 minutes.\n\nFortunately, git is based on extremely simple principles.\nUnfortunately, git grew out of really bright people hacking stuff\ntogether in order to get sh!t dun; the result is not approachably or\neven well documented, the UI is sometimes a bit of a kludge, the API\nis probably nonexistent, and the terminology is so loosely thrown\nabout that it's easy to forget which way is up in discussions.\n(Note, though, that Junio has done a laudable job of keeping the\nwhole experiment going strong).\n\nHaving recognized these deficiencies, I suggest that you provide\nat least one tiny little use case that doesn't work as you'd\nlike; it should be in the form of a command line example that we\ncan all reproduce and discuss precisely.\n"},{"id":"190503","messageId":"CAJsNXTmo1B86nSm7u923jJuGX0zajz3iqVu-onANMN-5BE5DfQ@mail.gmail.com","threadId":"30372","inReplyTo":"4FA05E9F.9090709@palm.com","subject":"Re: Newbie grief","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-05-01T23:01:42Z","receivedAt":"2012-05-01T23:01:42Z","isPatch":false,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"On Tue, May 1, 2012 at 3:07 PM, Rich Pixley wrote:\n\n> No, not a deploy system.  You use a deploy system to set up something like\n> multiple server http farms.  What I'm doing is more akin to porting the same\n> piece of software to 20 different operating system distributions.  I'm not\n> \"deploying\" the source code.  I'm developing it.\n\nI fail to see how you would end up with more than one branch per\nenvironment, though. Fewer, if you do the merge before pushing your\nchange back to the server.\n\nIt sounds like you're asking for branches without names (or\nautomatically assigned names like master-0, master-1, etc.). I'm sure\nit's all very intuitive in Hg (which I know nothing about), but it\nsounds to me like a recipe for confusion.\n\n-PJ\n\nGehm's Corollary to Clark's Law: Any technology distinguishable from\nmagic is insufficiently advanced.\n"},{"id":"190504","messageId":"CAMP44s2h4EY3Qu2+Ys_n3TUzmyykMkG-wMoqmKg5hjg24JQ+bg@mail.gmail.com","threadId":"30372","inReplyTo":"4FA055D0.7040102@palm.com","subject":"Re: Newbie grief","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-01T23:30:50Z","receivedAt":"2012-05-01T23:30:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, May 1, 2012 at 11:29 PM, Rich Pixley wrote:\n\n> I'm not asking for anything new.  I'm asking for something that's as capable\n> as what we've had for years now.\n\nSo you are basically saying; \"I want to do X *exactly* like I do it in\nmercurial, and that's not easy in git\".\n\nWell, duh, that's because git is not mercurial. Why don't you do it\nthe _git way_? That would be easy.\n\nShow all the hg commands of what you are trying to do, and we can show\nyou how you can achieve the same in git, but much more easily.\n\n-- \nFelipe Contreras\n"},{"id":"190507","messageId":"5ADB8D763B2B4CDA889052A1AA45F089@PhilipOakley","threadId":"30372","inReplyTo":"CAMOZ1BuiznhrzEOHe0N+uu=mLEw5wWTQyDpnwG8PuF1f_aNaXw@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-05-01T23:55:24Z","receivedAt":"2012-05-01T23:55:24Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Michael Witten\" Sent: Tuesday, May 01, 2012 \n11:56 PM\n> On Tue, May 1, 2012 at 9:57 PM, Rich Pixley wrote:\n>\n>> In contrast, I was up and using mercurial in about a day and a half,\n>> including all of the stuff we've discussed, and all of the things I've \n>> even\n>> read about in git. Learning mq's only took about 20 minutes.\n>\n> Fortunately, git is based on extremely simple principles.\n> Unfortunately, git grew out of really bright people hacking stuff\n> together in order to get sh!t dun; the result is not approachably or\n> even well documented, the UI is sometimes a bit of a kludge, the API\n> is probably nonexistent, and the terminology is so loosely thrown\n> about that it's easy to forget which way is up in discussions.\n> (Note, though, that Junio has done a laudable job of keeping the\n> whole experiment going strong).\n>\n> Having recognized these deficiencies, I suggest that you provide\n> at least one tiny little use case that doesn't work as you'd\n> like; it should be in the form of a command line example that we\n> can all reproduce and discuss precisely.\n> --\nA bit of browsing found \nhttp://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ which \nhelped with some of the confusion about the different meanings of \"branch\". \nIt looks like an Hg branch is a Git clone. Git can be hard work until one \n'gets' how and why the new DVCS approach works. Plus learing the UI.\n\nIt is very hard to change one's mindset about how/why/when the old VCS \napproach broke (or isn't). The common VCS approach is based on drawing \noffice practices from before the Titanic was built. It is only very recently \nthat the reproduction and verification cost for data duplication have \ndropped sufficiently that a DVCS is the better approach. The historical \napproach was to protect the single 'master' item (with lots of admin & \nprocess). Now it's about 'status accounting' - do I have the right copy at \nthe right status - i.e. the declared master sha1.\n\nPhilip \n"},{"id":"190510","messageId":"CAMK1S_jrDXvPTKt_Azk2BZm=N7SdgcvgAV7X1TEUvGhwcan_AA@mail.gmail.com","threadId":"30372","inReplyTo":"4FA01C73.5000909@palm.com","subject":"Re: Newbie grief","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-05-02T00:44:46Z","receivedAt":"2012-05-02T00:44:46Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"[I'm going to assume not copying the list on your reply to me was an\noversight, since there's nothing in the text to indicate it was\nsupposed to confidential or personal in any way].\n\n[second, sorry about the multiple emails!]\n\nOn Tue, May 1, 2012 at 10:55 PM, Rich Pixley wrote:\n>\n> On 4/30/12 20:44 , Sitaram Chamarty wrote:\n>>\n>> I've been reading the thread with interest.\n>>\n>> People who know far more than I do about git, its innards, and its\n>> design have been responding in this thread so consider this a git\n>> *user*'s point of view:\n>>\n>> On Tue, May 1, 2012 at 6:45 AM, Rich Pixley  wrote:\n>>\n>>> Multiple heads are the idea that a single commit can \"branch\" in the\n>>> repository and that both commits can be HEADS of the same branch at once\n>>> in\n>>> a single repository.  This allows a potential collision to exist in the\n>>> repository and to be pushed and pulled through multiple repositories.\n>>>  It\n>>\n>> That is bizarre; I have no other word for it.\n>>\n>> I teach git (occasionally), and if this feature existed I would\n>> totally ignore it in my teaching material because I wouldn't know how\n>> to defend or explain the need for \"hydra branches\".\n>>\n>> It's like having two people with the same first name *and* last name\n>> (a situation that is not impossible in real life, but is rare and\n>> almost always requires special handling).\n>>\n>> Does Hg do this?\n>\n> Yes, it does.  \"Hg merge\" by default merges a second head into your\n> current working directory.\n>\n> It's a conceptual leap, I concur.  Believe me, I'm going through the\n\n\nIt's a conceptual leap I can do without; I'm bowing out of this discussion.\n\nThere's an ambiguity in the branch name now that, to me, is both\nconfusing and unnecessary.\n\nIt's like each branch name is now an array variable instead of a scalar.\n\nWe all know when arrays are better than a bunch of similarly named\nscalars, but in *this* context I don't see why it is needed.\n\nThe fact that, (in later emails to others), you called this a basic\nbeginning need, or words to that effect, is just icing on top.\n\n> reverse cultural shock now that git doesn't have this facility.  But it's a\n> leap whose idea has been around for over 20 years.  It wasn't until the\n> daggy source code control systems like monotone showed up that it became\n> practical, but that was a decade ago now.\n>\n> The big win, of course, is that we can both push to the same repository,\n> (and through multiple repositories), and we can decide later whether we want\n> to merge or branch permanently.\n>\n>>   That would explain why my (admittedly half-hearted)\n>> attempts to learn it have failed -- whatever tutorial I used must have\n>> been written with the idea that hydra branches are intuitive and\n>> logical and sane, but did not express the concept as clearly and\n>> succinctly as you did.\n>>\n>> Thanks for this insight; my next attempt to understand Hg, should I\n>> ever be forced into it, might actually succeed!\n>\n> It's really pretty simple.  Your commit, (or push, or pull), always\n> succeeds, even if it's not at the tip of a branch.  If it's not at the tip\n> of a branch, then it creates a new tip.\n>\n> The word \"head\" here is problematic since git uses it in a totally\n> different way.  In git, \"HEAD\" refers to whatever commit is currently\n> checked out.  In hg, \"head\" refers to a childless commit.  It doesn't even\n> need to be on a named branch.\n>\n> --rich\n\n\n\n\n--\nSitaram\n"},{"id":"190528","messageId":"CAGK7Mr4U67GD7t2_Yy=VPcG_dY0riXO0bX6T88NRBFeqVXsGTA@mail.gmail.com","threadId":"30372","inReplyTo":"4F9F128C.5020304@palm.com","subject":"Re: Newbie grief","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2012-05-02T08:25:45Z","receivedAt":"2012-05-02T08:25:45Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> In other systems, this is a simple star network.  Clone a repository, use, push, pull, etc.  But with git, I can't push unless the cache repository is bare, but if the cache repository is bare, then a change to the central repository will cause the two to become wedged since neither can push or fetch the other.  It seems that git is allergic to the dual head branch solution or something, which is surprising and disappointing.\n\n\nIf I understand correctly, you're looking for a system where you have\na lot of systems that needs to share the modifications on their repo\n*without* having a central repo. Basically you want a lot of non-bare\nrepositories pushing/pulling from each others.\n\nIt sounds to me that your problem could easily be solved if your\nrestrict yourself to \"pulling\" only. Whenever you want the latest\nchange from repo on machine A, just pull from machine A and benefit\nfrom the automagic merging etc.\n\nTell me if there's something I'm missing, or maybe describe a simple\nscenario we can relate with in terms of ideal commands to type and\nthings happening.\n\nThanks,\nPhilippe\n"},{"id":"190562","messageId":"85ff02fc05e4a52ee0b1f1922f774a8d@ulrik.uio.no","threadId":"30372","inReplyTo":"4FA05E9F.9090709@palm.com","subject":"Re: Newbie grief","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-05-02T14:21:07Z","receivedAt":"2012-05-02T14:21:07Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" On Tue, 01 May 2012 15:07:27 -0700, Rich Pixley wrote:\n> On 5/1/12 14:39 , Randal L. Schwartz wrote:\n>> \"git fetch\" updates the remote tracking branches, which you commonly\n>> reference preceded by \"origin\". So \"git fetch\" DOES NOT TOUCH \n>> \"master\".\n>> It touches only \"origin/master\".\n>\n> Yes. I understand that that is how git typically works in a non-bare\n> repository.\n\n And in a bare repository:\n\n git init --bare foo.git\n cd foo.git\n git remote add bar ../bar.git\n git fetch bar\n --> adds bar/master etc.\n\n For some reason, 'git clone --bare' does not treat the cloned\n repository the same way - it just copies it under refs/heads/\n instead of refs/remotes/, without even adding it as a remote.\n\n-- \n Hallvard\n"},{"id":"190569","messageId":"947c3d6ae263495985543764a57c3fbb-mfwitten@gmail.com","threadId":"30372","inReplyTo":"85ff02fc05e4a52ee0b1f1922f774a8d@ulrik.uio.no","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2012-05-02T15:12:13Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, 02 May 2012 16:21:07 +0200, Hallvard Breien Furuseth wrote:\n\n> And in a bare repository:\n>\n> git init --bare foo.git\n> cd foo.git\n> git remote add bar ../bar.git\n> git fetch bar\n> --> adds bar/master etc.\n>\n> For some reason, 'git clone --bare' does not treat the cloned\n> repository the same way - it just copies it under refs/heads/\n> instead of refs/remotes/, without even adding it as a remote.\n\nWhat do you mean?\n\n $ git init bar.git; cd bar.git\n $ echo a > a; git add a; git commit -m a; cd ..\n $ git clone bar.git baz.git\n $ git clone --bare baz.git foo.git; cd foo.git\n $ git remote add bar ../bar.git\n $ git fetch bar\n $ git branch -a\n * master\n remotes/bar/master\n\nAlso, removing the `baz' intermediate repository doesn't matter:\n\n $ git init bar.git; cd bar.git\n $ echo a > a; git add a; git commit -m a; cd ..\n $ git clone --bare bar.git foo.git; cd foo.git\n $ git remote add bar ../bar.git\n $ git fetch bar\n $ git branch -a\n * master\n remotes/bar/master\n\nFor completenes, your example again:\n\n $ git init bar.git; cd bar.git\n $ echo a > a; git add a; git commit -m a; cd ..\n $ git init --bare foo.git\n $ cd foo.git\n $ git remote add bar ../bar.git\n $ git fetch bar\n $ git branch -a\n remotes/bar/master\n"},{"id":"190597","messageId":"m3pqamqnnz.fsf@localhost.localdomain","threadId":"30372","inReplyTo":"4FA030D1.5030301@palm.com","subject":"Re: Newbie grief","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-05-02T21:28:20Z","receivedAt":"2012-05-02T21:28:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Rich Pixley writes:\n> On 5/1/12 11:20 , Michael Witten wrote:\n>> On Tue, May 1, 2012 at 18:15, Rich Pixley wrote:\n>>\n>>> I want pull to work even without merging. I want to be able to share a\n>>> branch between different repositories and different users while the source\n>>> code control system tracks this for me\n>>\n>> I believe you are missing the point that a `pull' in git is a `fetch'\n>> followed by a `merge'. You should read about the `fetch' command by\n>> reading (`git help fetch'), and make sure you understand how to use\n>> refspecs; you will probably find it very instructive to play around\n>> by specifying explicit refspecs to `git fetch' rather than relying\n>> on the implicit rules (which can be somewhat confusing).\n\n[...]\n> That git uses the word \"pull\" to mean something different than\n> previous source code control systems only adds to the confusion. I\n> was using \"pull\" in the more general sense of pushing and pulling\n> data, not in the very narrow meaning of \"git fetch + git merge\".\n\nIn using \"pull\" vs \"fetch\" Git follows the convention of BitKeeper\n(proprietary distributed version control system which was used for\nLinux kernel development 'till \"BitKeeper fiasco\", and which Git\nreplaced).\n\n> I'm still pretty much lost on refspecs and refs. The terms are\n> apparently not used in the manuals I've been reading and they don't\n> seem to be used consistently even within git error messages.\n> \n> Is \"refspec\" the git word for the branch pointer that points to the\n> childless commit that defines a branch?\n\n\"Ref\" in Git is a named reference (pointer) to a commit in DAG of\nrevisions, i.e. either [local] branch, tag, remote-tracking branch,\netc.\n\n\"Refspec\" is a specification of mapping between ref name in remote\nrepository and \"tracking\" ref in local repository, e.g.\n\n refs/heads/*:refs/remotes/origin/*\n refs/tags/*:refs/tags/*\n\nSee any of git-pull(1), git-fetch(1) and git-push(1) manpages.\n\n-- \nJakub Narebski\n"},{"id":"190638","messageId":"63c4e1944dcfd03e8c9ff324080ff62f@ulrik.uio.no","threadId":"30372","inReplyTo":"947c3d6ae263495985543764a57c3fbb-mfwitten@gmail.com","subject":"Re: Newbie grief","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-05-03T12:23:59Z","receivedAt":"2012-05-03T12:23:59Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" On Wed, 02 May 2012 15:21:29 -0000, Michael Witten \n wrote:\n>On Wed, 02 May 2012 16:21:07 +0200, Hallvard Breien Furuseth wrote:\n>> And in a bare repository:\n>>\n>> git init --bare foo.git\n>> cd foo.git\n>> git remote add bar ../bar.git\n>> git fetch bar\n>> --> adds bar/master etc.\n>>\n>> For some reason, 'git clone --bare' does not treat the cloned\n>> repository the same way - it just copies it under refs/heads/\n>> instead of refs/remotes/, without even adding it as a remote.\n>\n> What do you mean?\n\n I mean 'git clone --bare bar.git foo.git' does not give foo.git\n a remote named 'origin' with a branch origin/master. Not sure\n if there is a _simple_ way to do it well either. init + fetch\n above does not try to hardlink objects/packs like clone does.\n\n> (...)\n> $ git init bar.git; cd bar.git\n> $ echo a > a; git add a; git commit -m a; cd ..\n> $ git clone --bare bar.git foo.git; cd foo.git\n\n $ git branch -a\n * master\n\n> $ git remote add bar ../bar.git\n> $ git fetch bar\n\n-- \n Hallvard\n"},{"id":"190640","messageId":"8662cdjui6.fsf@red.stonehenge.com","threadId":"30372","inReplyTo":"63c4e1944dcfd03e8c9ff324080ff62f@ulrik.uio.no","subject":"Re: Newbie grief","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2012-05-03T12:53:37Z","receivedAt":"2012-05-03T12:53:37Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Hallvard\" == Hallvard Breien Furuseth writes:\n\nHallvard> I mean 'git clone --bare bar.git foo.git' does not give foo.git\nHallvard> a remote named 'origin' with a branch origin/master. Not sure\nHallvard> if there is a _simple_ way to do it well either. init + fetch\nHallvard> above does not try to hardlink objects/packs like clone does.\n\nInteresting. I was surprised by this, but I've confirmed it.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"190651","messageId":"67e635d73b952088917d197cbbd06684@ulrik.uio.no","threadId":"30372","inReplyTo":"5ADB8D763B2B4CDA889052A1AA45F089@PhilipOakley","subject":"Re: Newbie grief","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-05-03T16:08:46Z","receivedAt":"2012-05-03T16:08:46Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" Philip Oakley wrote:\n> A bit of browsing found\n> http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/\n> which helped with some of the confusion about the different meanings\n> of \"branch\". It looks like an Hg branch is a Git clone. Git can be\n> hard work until one 'gets' how and why the new DVCS approach works.\n> Plus learing the UI.\n\n Aha, now this thread finally makes some sense. So when Rich\n wants a \"branch\" with several tips, he actually wants several\n Git clones (repositories) with the same Git branch checked out -\n and some of them with local commits to it.\n\n And these commits can be shared as remote branches between the\n clones, which in Hg-speak means that in one particular clone,\n Git will \"bookmark\" the other clones' tips.\n\n-- \n Hallvard\n"},{"id":"190652","messageId":"e7c7047452954a4b80f5fd436103cb11-mfwitten@gmail.com","threadId":"30372","inReplyTo":"63c4e1944dcfd03e8c9ff324080ff62f@ulrik.uio.no","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2012-05-03T16:08:46Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote:\n\n> On Wed, 02 May 2012 15:21:29 -0000, Michael Witten wrote:\n>\n>>On Wed, 02 May 2012 16:21:07 +0200, Hallvard Breien Furuseth wrote:\n>>> And in a bare repository:\n>>>\n>>> git init --bare foo.git\n>>> cd foo.git\n>>> git remote add bar ../bar.git\n>>> git fetch bar\n>>> --> adds bar/master etc.\n>>>\n>>> For some reason, 'git clone --bare' does not treat the cloned\n>>> repository the same way - it just copies it under refs/heads/\n>>> instead of refs/remotes/, without even adding it as a remote.\n>>\n>> What do you mean?\n>\n> I mean 'git clone --bare bar.git foo.git' does not give foo.git\n> a remote named 'origin' with a branch origin/master. Not sure\n> if there is a _simple_ way to do it well either. init + fetch\n> above does not try to hardlink objects/packs like clone does.\n>\n>> (...)\n>> $ git init bar.git; cd bar.git\n>> $ echo a > a; git add a; git commit -m a; cd ..\n>> $ git clone --bare bar.git foo.git; cd foo.git\n>\n> $ git branch -a\n> * master\n\n>From `git help clone':\n\n --bare\n Make a bare GIT repository. That is, instead of creating\n and placing the administrative files in\n /.git, make the itself the $GIT_DIR.\n This obviously implies the -n because there is nowhere to\n check out the working tree. Also the branch heads at the\n remote are copied directly to corresponding local branch\n heads, without mapping them to refs/remotes/origin/. When\n this option is used, neither remote-tracking branches nor the\n related configuration variables are created.\n\nnamely:\n\n Also the branch heads at the\n remote are copied directly to corresponding local branch\n heads, without mapping them to refs/remotes/origin/. When\n this option is used, neither remote-tracking branches nor the\n related configuration variables are created.\n"},{"id":"190653","messageId":"f66919ac273fd1c90839e5556f126960@ulrik.uio.no","threadId":"30372","inReplyTo":"e7c7047452954a4b80f5fd436103cb11-mfwitten@gmail.com","subject":"Re: Newbie grief","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-05-03T16:20:43Z","receivedAt":"2012-05-03T16:20:43Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" On Thu, 03 May 2012 16:09:15 -0000, Michael Witten wrote:\n> On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote:\n>> I mean 'git clone --bare bar.git foo.git' does not give foo.git\n>> a remote named 'origin' with a branch origin/master. Not sure\n>> if there is a _simple_ way to do it well either. init + fetch\n>> above does not try to hardlink objects/packs like clone does.\n>>\n>>> (...)\n>>> $ git init bar.git; cd bar.git\n>>> $ echo a > a; git add a; git commit -m a; cd ..\n>>> $ git clone --bare bar.git foo.git; cd foo.git\n>>\n>> $ git branch -a\n>> * master\n>\n> From `git help clone':\n>\n> --bare\n> Make a bare GIT repository. That is, instead of creating\n> and placing the administrative files in\n> /.git, make the itself the $GIT_DIR.\n> This obviously implies the -n because there is nowhere to\n> check out the working tree. Also the branch heads at the\n> remote are copied directly to corresponding local branch\n> heads, without mapping them to refs/remotes/origin/. When\n> this option is used, neither remote-tracking branches nor the\n> related configuration variables are created.\n\n Yes, I know. I just don't know why.\n\n-- \n Hallvard\n"},{"id":"190654","messageId":"f16516bc77a645e4b0d6b5d2f42090d3-mfwitten@gmail.com","threadId":"30372","inReplyTo":"f66919ac273fd1c90839e5556f126960@ulrik.uio.no","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2012-05-03T16:20:43Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, 03 May 2012 18:20:43 +0200, Hallvard Furuseth wrote:\n\n> On Thu, 03 May 2012 16:09:15 -0000, Michael Witten wrote:\n>\n>> On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote:\n>>\n>>> I mean 'git clone --bare bar.git foo.git' does not give foo.git\n>>> a remote named 'origin' with a branch origin/master. Not sure\n>>> if there is a _simple_ way to do it well either. init + fetch\n>>> above does not try to hardlink objects/packs like clone does.\n>>>\n>>>> (...)\n>>>> $ git init bar.git; cd bar.git\n>>>> $ echo a > a; git add a; git commit -m a; cd ..\n>>>> $ git clone --bare bar.git foo.git; cd foo.git\n>>>\n>>> $ git branch -a\n>>> * master\n>>\n>> From `git help clone':\n>>\n>> --bare\n>> Make a bare GIT repository. That is, instead of creating\n>> and placing the administrative files in\n>> /.git, make the itself the $GIT_DIR.\n>> This obviously implies the -n because there is nowhere to\n>> check out the working tree. Also the branch heads at the\n>> remote are copied directly to corresponding local branch\n>> heads, without mapping them to refs/remotes/origin/. When\n>> this option is used, neither remote-tracking branches nor the\n>> related configuration variables are created.\n>\n> Yes, I know. I just don't know why.\n\nI imagine that the purpose behind a bare repository is really just to\nprovide a repository into which objects may be pushed and from which\nobjects may be fetched, and that's it; it's sole purpose is to act\nas a point of communication. Cloning a repository with --bare is\nmeant to simplify the task of setting up a bare repository with\nsome initial content.\n\nFortunately, we're talking about the history of a revision control\nsystem. I found this with `git blame -L70,76 71821351^ git-clone.txt':\n\n commit 4fb66a62eeb7bfec115cd0058d7a05ab62fc23e7\n Author: Junio C Hamano \n Date: Sun Jan 22 17:27:52 2006 -0800\n \n clone: do not create remotes/origin nor origin branch in a bare repository.\n \n It is simply pointless, since no merges will ever happen in such\n a repository.\n \n Signed-off-by: Junio C Hamano \n\nThat certainly corroborates the limited purpose of a bare repository.\n"},{"id":"190665","messageId":"4FA2CC88.9000207@palm.com","threadId":"30372","inReplyTo":"67e635d73b952088917d197cbbd06684@ulrik.uio.no","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T18:20:56Z","receivedAt":"2012-05-03T18:20:56Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/3/12 09:08 , Hallvard Breien Furuseth wrote:\n> Philip Oakley wrote:\n>> A bit of browsing found\n>> http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/\n>> which helped with some of the confusion about the different meanings\n>> of \"branch\". It looks like an Hg branch is a Git clone. Git can be\n>> hard work until one 'gets' how and why the new DVCS approach works.\n>> Plus learing the UI.\n> Aha, now this thread finally makes some sense. So when Rich\n> wants a \"branch\" with several tips, he actually wants several\n> Git clones (repositories) with the same Git branch checked out -\n> and some of them with local commits to it.\nYes.\n> And these commits can be shared as remote branches between the\n> clones, which in Hg-speak means that in one particular clone,\n> Git will \"bookmark\" the other clones' tips.\nWell, no. In hg, these are all managed. So there's no scaling issue. \nThey can all push/pull together, since they are really all just one \nshared branch. Adding a new repository to the mix is trivial. And \neither pushes or pulls can be used, or any combo.\n\nWith git, I must manually make space for each and every repository, \nmanually track which set of changes are where, manually track which need \nto be merged, and manually track which repositories are looking at which \ngit branches so that they don't collide, or only collide in the current \nrepository and only when I'm prepared to merge them.\n\n(The bookmark solution appears to be what hg-git uses. Hg-git is an hg \nextension to allow push/pull/clone from git repositories using hg. \nUnfortunately, it doesn't translate git submodules into hg \nsubrepositories - yet.)\n\n--rich\n"},{"id":"190662","messageId":"4FA2CDCC.6020303@palm.com","threadId":"30372","inReplyTo":"f66919ac273fd1c90839e5556f126960@ulrik.uio.no","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T18:26:20Z","receivedAt":"2012-05-03T18:26:20Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/3/12 09:20 , Hallvard Breien Furuseth wrote:\n> On Thu, 03 May 2012 16:09:15 -0000, Michael Witten wrote:\n>> On Thu, 03 May 2012 14:23:59 +0200, Hallvard Furuseth wrote:\n>>> I mean 'git clone --bare bar.git foo.git' does not give foo.git\n>>> a remote named 'origin' with a branch origin/master. Not sure\n>>> if there is a _simple_ way to do it well either. init + fetch\n>>> above does not try to hardlink objects/packs like clone does.\n>>>\n>>>> (...)\n>>>> $ git init bar.git; cd bar.git\n>>>> $ echo a> a; git add a; git commit -m a; cd ..\n>>>> $ git clone --bare bar.git foo.git; cd foo.git\n>>> $ git branch -a\n>>> * master\n>> From `git help clone':\n>>\n>> --bare\n>> Make a bare GIT repository. That is, instead of creating\n>> and placing the administrative files in\n>> /.git, make the itself the $GIT_DIR.\n>> This obviously implies the -n because there is nowhere to\n>> check out the working tree. Also the branch heads at the\n>> remote are copied directly to corresponding local branch\n>> heads, without mapping them to refs/remotes/origin/. When\n>> this option is used, neither remote-tracking branches nor the\n>> related configuration variables are created.\n> Yes, I know. I just don't know why.\nI do.\n\nIt's because creating a string of repositories is a nuisance in git \nbecause of the remote/foo practice. You have to manually fetch and \nmerge at each location.\n\nIn other systems, the branches are tracked identically. You see master, \nI see master. The only differences we see are any changes I've created \nthat haven't yet been pushed to you or vice verse. But since git can't \nhandle collisions in the repository the way other systems do, it's \nforced to use the geographic branch scheme for non-bare repositories. \nBare repositories don't have the collision between repository branch and \nworking directory copy in git, so with bare repositories, git can use \nthe identical branch scheme, (although it still refuses colliding pushes).\n\nIf bare repositories used the triangulation approach of non-bare \nrepositories, then automation would be considerably more complicated. \nSo would repository chaining.\n\nWhat I don't understand is why git chose this less functional \narchitecture over the previously existing practice that doesn't have \nthese limitations, although \"because that's what BitKeeper did\" might be \nthe sad answer.\n\n--rich\n"},{"id":"190663","messageId":"4FA2CF18.5090509@palm.com","threadId":"30372","inReplyTo":"CAMP44s2h4EY3Qu2+Ys_n3TUzmyykMkG-wMoqmKg5hjg24JQ+bg@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T18:31:52Z","receivedAt":"2012-05-03T18:31:52Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 16:30 , Felipe Contreras wrote:\n> On Tue, May 1, 2012 at 11:29 PM, Rich Pixley wrote:\n>\n>> I'm not asking for anything new. I'm asking for something that's as capable\n>> as what we've had for years now.\n> So you are basically saying; \"I want to do X *exactly* like I do it in\n> mercurial, and that's not easy in git\".\nWell, no, I'm saying that I want to do it at all, and that's not easy in \ngit.\n> Well, duh, that's because git is not mercurial. Why don't you do it\n> the _git way_? That would be easy.\nThat would be great, except that it's not easy. It's a mess.\n\nI do have a partial solution now, thanks to the list. It's just a bit \nmessier and non-intuitive since I have to work around the limitations of \ngit.\n\n--rich\n"},{"id":"190666","messageId":"4FA2D1D7.3020807@palm.com","threadId":"30372","inReplyTo":"CAJsNXTmo1B86nSm7u923jJuGX0zajz3iqVu-onANMN-5BE5DfQ@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T18:43:35Z","receivedAt":"2012-05-03T18:43:35Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 16:01 , PJ Weisberg wrote:\n> On Tue, May 1, 2012 at 3:07 PM, Rich Pixley wrote:\n>\n>> No, not a deploy system. You use a deploy system to set up something like\n>> multiple server http farms. What I'm doing is more akin to porting the same\n>> piece of software to 20 different operating system distributions. I'm not\n>> \"deploying\" the source code. I'm developing it.\n> I fail to see how you would end up with more than one branch per\n> environment, though. Fewer, if you do the merge before pushing your\n> change back to the server.\n>\n> It sounds like you're asking for branches without names (or\n> automatically assigned names like master-0, master-1, etc.). I'm sure\n> it's all very intuitive in Hg (which I know nothing about), but it\n> sounds to me like a recipe for confusion.\nI'm finding the reverse to be true.\n\nIn hg, I don't have to think about how many other branches or \nrepositories there might be. I don't have to track where the changes \nare. And I don't have to do anything to add another repository to the \nmix or to remove one. Trivial merges are trivial. The view from any \nrepository is identical, not just symmetric. The things I want to do \nare all simple commands. Pull from the cache, merge if necessary, do \nsome work, push to the cache. Repeat as necessary since there will be \nnumerous collisions and merges since I'm working on multiple machines \nconcurrently. And eventually, push to central server.\n\nWith git, if I use the traditional triangle architecture, I have to \nmanually name every repository and every branch uniquely, create fresh \nbranches in every other repository when I create one new repository. \nRemove old branches from every other repository whenever I remove one. \nTrack collisions manually, track which repositories have which changes \nmanually, and be extra careful about moving changes around so that they \ndon't collide or force merge commits because that screws up git \nhistories. In order to do a simple source code control task, I have to \nstop, formulate a plan for making things work in git that still ducks \nboth the limitations and traps of git and still accomplishes my goal, \nand then execute that plan precisely, because recovery is difficult.\n\nIf I skip the standard git triangle merging architecture, I can collapse \nsome of that bookkeeping by sharing a branch. But the cost is that \npushing, pulling, and merging become even more complex as I have to \ndodge more limitations, (essentially, pushing doesn't work, star \nnetworks don't work, etc.)\n\nTrying to keep all of that bookkeeping in my head, or trying to remember \nall of those arbitrary and unnecessary limitations is more complicated.\n\nI'll grant that some of this is unique to my current work flow. But I \nthink that a lot of it carries into other work flows as well.\n\n--rich\n"},{"id":"190668","messageId":"4FA2D295.1090405@palm.com","threadId":"30372","inReplyTo":"CAMOZ1BuiznhrzEOHe0N+uu=mLEw5wWTQyDpnwG8PuF1f_aNaXw@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T18:46:45Z","receivedAt":"2012-05-03T18:46:45Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 15:56 , Michael Witten wrote:\n> On Tue, May 1, 2012 at 9:57 PM, Rich Pixley wrote:\n>\n>> In contrast, I was up and using mercurial in about a day and a half,\n>> including all of the stuff we've discussed, and all of the things I've even\n>> read about in git. Learning mq's only took about 20 minutes.\n> Fortunately, git is based on extremely simple principles.\n> Unfortunately, git grew out of really bright people hacking stuff\n> together in order to get sh!t dun; the result is not approachably or\n> even well documented, the UI is sometimes a bit of a kludge, the API\n> is probably nonexistent, and the terminology is so loosely thrown\n> about that it's easy to forget which way is up in discussions.\n> (Note, though, that Junio has done a laudable job of keeping the\n> whole experiment going strong).\nThank you for acknowledging that.\n> Having recognized these deficiencies, I suggest that you provide\n> at least one tiny little use case that doesn't work as you'd\n> like; it should be in the form of a command line example that we\n> can all reproduce and discuss precisely.\nI think I already have. And you've given me an approach that is largely \nfunctional in git. It's not wonderful, but it's mostly functional.\n\nI'll post my comparison elsepost.\n\n--rich\n"},{"id":"190670","messageId":"4FA2D565.1080806@palm.com","threadId":"30372","inReplyTo":"CAMP44s2h4EY3Qu2+Ys_n3TUzmyykMkG-wMoqmKg5hjg24JQ+bg@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T18:58:45Z","receivedAt":"2012-05-03T18:58:45Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/1/12 16:30 , Felipe Contreras wrote:\n> Show all the hg commands of what you are trying to do, and we can show\n> you how you can achieve the same in git, but much more easily.\nhg init foo\nfor i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg clone foo \nfoo-$d; (cd foo-$d && date > bar && hg add bar && hg ci -m $d)); done\nfor i in foo-*; do (set -x ; (cd $i && hg push -f)); done\n\n--rich\n"},{"id":"190673","messageId":"CA+7g9JzZ36RgsniT4UN0Zk+z1ohZYW5u+0AoGMjJZqsoBjqvqA@mail.gmail.com","threadId":"30372","inReplyTo":"4FA2D1D7.3020807@palm.com","subject":"Re: Newbie grief","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-05-03T19:09:22Z","receivedAt":"2012-05-03T19:09:22Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"On Thu, May 3, 2012 at 11:43 AM, Rich Pixley wrote:\n>\n> In hg, I don't have to think about how many other branches or repositories\n> there might be.  I don't have to track where the changes are.  And I don't\n> have to do anything to add another repository to the mix or to remove one.\n>  Trivial merges are trivial.  The view from any repository is identical, not\n> just symmetric.  The things I want to do are all simple commands.  Pull from\n> the cache, merge if necessary, do some work, push to the cache.  Repeat as\n> necessary since there will be numerous collisions and merges since I'm\n> working on multiple machines concurrently.  And eventually, push to central\n> server.\n\nWow, this hg sounds great! You should use that!\n\nAll kidding aside, what you're talking about are design decisions\nbased on preferred workflows. The workflow you're describing may seem\nobvious and fantastic to you, but it sounds absurdly complicated to\nme. You hate the way git handles remote branches. I think it's\nincredibly sensible for a *truly* distributed VCS to enforce\nlocation-based namespacing. Basically, we have differences of\nopinion. Since your opinion seems to be that hg has done everything\nright and git has done everything wrong, why are you using git?\n\nCheers,\n-n8\n\n-- \nHexaLex: A New Angle on Crossword Games for iPhone and iPod Touch\nhttp://hexalex.com\nOn The App Store: http://bit.ly/8Mj1CU\nOn Facebook: http://bit.ly/9MIJiV\nOn Twitter: http://twitter.com/hexalexgame\nhttp://n8gray.org\n"},{"id":"190675","messageId":"4FA2D8EA.7030809@palm.com","threadId":"30372","inReplyTo":"08704bd2e32343a4b9def80e4fa1efa2-mfwitten@gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T19:13:46Z","receivedAt":"2012-05-03T19:13:46Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 4/30/12 22:32 , Michael Witten wrote:\n> On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote:\n>\n>> I don't need separate branches for each repository. What I really want\n>> is a common branch whose changes I can push back and forth between the\n>> various repositories, or coordinate through a central cache, without\n>> worrying about the underlying details that git is forcing me to confront.\n>\n> Here's a start for a more precise discussion.\n>\n> Sincerely,\n> Michael Witten\n>\n>\n> Cache server:\n>\n> $ git clone --mirror \"$uri_for_central_repo\"\n>\n> Machine A:\n>\n> $ git clone \"$uri_for_cache_repo\"\n> $ git checkout -b feature_0 origin/feature_0\n> $ # ... do some work ...\n> $ git push --set-upstream origin HEAD:shared/feature_0\n> $ git config push.default upstream\n>\n> Machine B:\n>\n> $ git clone \"$uri_for_cache_repo\"\n> $ git checkout -b feature_0 origin/feature_0\n> $ # ... do some work that conflicts with work done on Machine A...\n> $ git push --set-upstream origin HEAD:shared/feature_0\n> To $uri_for_cache_repo\n> ! [rejected] HEAD -> shared/feature_0 (non-fast-forward)\n> error: failed to push some refs to '$uri_for_cache_repo'\n> To prevent you from losing history, non-fast-forward updates were rejected\n> Merge the remote changes (e.g. 'git pull') before pushing again. See the\n> 'Note about fast-forwards' section of 'git push --help' for details.\n> $ git pull origin shared/feature_0\n> From $uri_for_cache_repo\n> * branch shared/feature_0 -> FETCH_HEAD\n> Auto-merging a\n> CONFLICT (add/add): Merge conflict in a\n> Recorded preimage for 'a'\n> Automatic merge failed; fix conflicts and then commit the result.\n> $ # ... resolve conflict and commit results ...\n> $ git push --set-upstream origin HEAD:shared/feature_0\n> $ git config push.default upstream\n>\n> Machine A:\n>\n> $ git pull # pulls in origin's shared/feature_0\n> $ # ... do some work ...\n> $ git push # pushes to origin's shared/feature_0\n>\n> Machine B:\n>\n> $ git pull # pulls in origin's shared/feature_0\n> $ # ... do some work ...\n> $ git push # pushes to origin's shared/feature_0\n>\n> Machine A:\n>\n> $ git pull\n> $ git remote add central \"$uri_for_central_repo\"\n> $ git push central HEAD:feature_0 # Assume there is a conflict\n> To $uri_for_central_repo\n> ! [rejected] HEAD -> feature_0 (non-fast-forward)\n> error: failed to push some refs to '$uri_for_central_repo'\n> To prevent you from losing history, non-fast-forward updates were rejected\n> Merge the remote changes (e.g. 'git pull') before pushing again. See the\n> 'Note about fast-forwards' section of 'git push --help' for details.\n> $ git pull central feature_0\n> $ # ... resolve conflict and commit results ...\n> $ git push central HEAD:feature_0 # Assume it succeeds this time\n> $ # Let's update the cache repo from Machine A:\n> $ git fetch central\n> $ git push origin 'refs/remotes/central/*:refs/heads/*'\n>\n> Machine B:\n>\n> $ git pull\n> $ git pull . origin/feature_0 # Get new stuff cached from central server\n\nThis is probably what I'm going to end up using.\n\nJust for comparison, here's a similar process in hg.\n\nCache server:\n\n $ hg clone $uri_for_central_repo\n\nMachine A:\n\n $ hg clone $uri_for_cache_repo\n $ # ...do some work...\n $ hg push\n\nMachine B:\n\n $ hg clone $uri_for_cache_repo\n $ # ...do some work...\n $ hg push # assume this collides\n pushing to $uri_for_cache_repo\n searching for changes\n abort: push creates new remote head 6d2eb0a6a278!\n (you should pull and merge or use push -f to force)\n $ hg push -f # the pull and merge case parallels git, so let's use \npush -f.\n\nAny repo:\n\n $ hg pull # pulls in all changes including the dual heads\n $ hg merge # collapses the dual heads\n $ hg commit # commits the merge\n $ hg push\n\nMachine A:\n\n $ hg pull # pulls in all changes so far\n $ hg up\n $ #... do some work ...\n $ hg push\n\nMachine B\n\n $ hg pull\n $ hg up\n $ # ... do some work ...\n $ hg push\n\nAny repo:\n\n $ hg pull $uri_to_central_repo\n $ hg merge\n $ hg push $uri_to_central_repo\n $ hg push # default is cache repo\n\nMachine B:\n\n $ hg pull\n\n\nSome Conclusions:\n\n* the work flows are similar.\n\n* the hg commands are simpler and have the defaults that we want, \nprimarily because no extra branches are required.\n\n* the hg error messages are straightforward, clear, and don't require \nany deep knowledge of the source code control system or it's \nlimitations. (I still don't understand what the git message on \ncollision is saying.)\n\n* hg has more options about how to handle the collisions or the merges. \n While git can mimic some of those options, doing so requires a priori \nknowledge that isn't stored in the source code control system and \ntherefor requires a human exchange which is optional with hg.\n\n--rich\n"},{"id":"190676","messageId":"4FA2D97A.8090504@palm.com","threadId":"30372","inReplyTo":"CA+7g9JzZ36RgsniT4UN0Zk+z1ohZYW5u+0AoGMjJZqsoBjqvqA@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T19:16:10Z","receivedAt":"2012-05-03T19:16:10Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/3/12 12:09 , Nathan Gray wrote:\n> On Thu, May 3, 2012 at 11:43 AM, Rich Pixley wrote:\n>> In hg, I don't have to think about how many other branches or repositories\n>> there might be. I don't have to track where the changes are. And I don't\n>> have to do anything to add another repository to the mix or to remove one.\n>> Trivial merges are trivial. The view from any repository is identical, not\n>> just symmetric. The things I want to do are all simple commands. Pull from\n>> the cache, merge if necessary, do some work, push to the cache. Repeat as\n>> necessary since there will be numerous collisions and merges since I'm\n>> working on multiple machines concurrently. And eventually, push to central\n>> server.\n> Wow, this hg sounds great! You should use that!\n>\n> All kidding aside, what you're talking about are design decisions\n> based on preferred workflows. The workflow you're describing may seem\n> obvious and fantastic to you, but it sounds absurdly complicated to\n> me. You hate the way git handles remote branches. I think it's\n> incredibly sensible for a *truly* distributed VCS to enforce\n> location-based namespacing. Basically, we have differences of\n> opinion. Since your opinion seems to be that hg has done everything\n> right and git has done everything wrong, why are you using git?\nCorporate mandate. Political decision made without discussion with the \npeople who would be using it.\n\n--rich\n"},{"id":"190679","messageId":"20120503193353.GI18002@thunk.org","threadId":"30372","inReplyTo":"4FA2CDCC.6020303@palm.com","subject":"Re: Newbie grief","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2012-05-03T19:33:53Z","receivedAt":"2012-05-03T19:33:53Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, May 03, 2012 at 11:26:20AM -0700, Rich Pixley wrote:\n> \n> In other systems, the branches are tracked identically. You see\n> master, I see master. The only differences we see are any changes\n> I've created that haven't yet been pushed to you or vice verse. But\n> since git can't handle collisions in the repository the way other\n> systems do, it's forced to use the geographic branch scheme for\n> non-bare repositories. Bare repositories don't have the collision\n> between repository branch and working directory copy in git, so with\n> bare repositories, git can use the identical branch scheme,\n> (although it still refuses colliding pushes).\n\nI'm still not sure I understand your development workflow. It seems\nlike you are trying to publish multiple branches across to multiple\nrepositories on different machines, so they are visible to different\ndevelopers? What are all of these branches used for, and why are you\ndoing things this way? (I'm not implying that the reason you have for\ndoing this way is silly or stupid, just that I don't understand it and\nI don't understand why you feel you need to do things this way.)\n\n> What I don't understand is why git chose this less functional\n> architecture over the previously existing practice that doesn't have\n> these limitations, although \"because that's what BitKeeper did\"\n> might be the sad answer.\n\nIt's mainly because many git users, including many kernel developers\nhave a set of development workflows which is well suited for how git\nis set up to work. So git was very much shaped by the development\nworkflows of the early git users --- and it goes the other way, too\n--- new git features will sometimes cause our development practices\nand workflow to evolve.\n\nSo I may have a number of different branches that I'm working on, but\nin general they stay local to my repository until they are ready to be\nmerged to mainline. If patches need to be reviewed, they either get\nsent via e-mail to the appropriate mailing list, and the review\nhappens via e-mail, or internally at $WORK, we use Gerrit and we push\nthe change to gerrit where the patches are kept and trackked inside\nGerrit, alongside the comments as the patch goes through the review\nprocess. (I suspect you are pushing patches out to the repository for\nreview as the patches are getting developed and refined, but I don't\nknow that for sure, since you haven't talked about why you want the\nparticular SCM features that you've been asking for.)\n\nOnce a patch is fully baked, it goes into a maintainer's repository\nwhere it gets pulled into a higher-level maintainer's repository. So\nin practice a developer's repository has very few branches that he or\nshe needs to export to the outside world, at least as I and other\nLinux kernel developers typically tend to use git.\n\nIt's obvious you want to use your DSCM in a different way, and it's\nnot that any particular workflow is right or wrong. But obviously,\nsome tools are a better match for certain workflows as compared to\nother workflows.\n\nRegards,\n\n\t\t\t\t\t- Ted\n"},{"id":"190683","messageId":"86ipgdhvjo.fsf@red.stonehenge.com","threadId":"30372","inReplyTo":"4FA2D97A.8090504@palm.com","subject":"Re: Newbie grief","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2012-05-03T20:14:03Z","receivedAt":"2012-05-03T20:14:03Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Rich\" == Rich Pixley writes:\n\nRich> Corporate mandate. Political decision made without discussion\nRich> with the people who would be using it.\n\nSounds like you put two strikes against git before you even invoked the\nfirst command, with that attitude.\n\nIf you are *serious* about having *git* work for you, it will.\nThousands of projects are using git every day.\n\nBut if you're looking at git like \"it's not hg, and I already hate\nthat\", you'll end up sounding like you have in the past few days.\n\nMethinks *this* is the actual problem. Not git.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"190684","messageId":"87obq5ggpu.fsf@an-dro.info.enstb.org","threadId":"30372","inReplyTo":"4FA2D8EA.7030809@palm.com","subject":"Re: Newbie grief","fromName":"Ronan Keryell","fromEmail":"ronan.keryell@hpc-project.com","sentAt":"2012-05-03T20:19:41Z","receivedAt":"2012-05-03T20:19:41Z","isPatch":false,"sender":{"key":"ronan.keryell@hpc-project.com","avatar":null},"body":">>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley said:\n\n Rich> * the hg error messages are straightforward, clear, and don't\n Rich> require any deep knowledge of the source code control system\n Rich> or it's limitations. (I still don't understand what the git\n Rich> message on collision is saying.)\n\nThis is a very good suggestion.\n\nThis would help people not having time to embrace all the advanced\ndetails to understand easily what is happening.\n\nAt least, print a simpler message with some typical use case causing\nthis and some workflow ideas before the detailed explanation.\n\nOr adding a new config message.style = expert | newbie | ...\nand of course with newbie by default. :-)\n-- \n Ronan KERYELL |\\/ Phone: +1 408 658 9453\n Wild Systems / HPC Project |/)\n 5201 Great America Parkway, Suite 320 K Ronan.Keryell@wild-systems.com\n Santa Clara, CA 95054 |\\ skype:keryell\n USA | \\ http://wild-systems.com\n"},{"id":"190687","messageId":"4FA2F013.3020904@palm.com","threadId":"30372","inReplyTo":"86ipgdhvjo.fsf@red.stonehenge.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T20:52:35Z","receivedAt":"2012-05-03T20:52:35Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/3/12 13:14 , Randal L. Schwartz wrote:\n>>>>>> \"Rich\" == Rich Pixley writes:\n> Rich> Corporate mandate. Political decision made without discussion\n> Rich> with the people who would be using it.\n>\n> Sounds like you put two strikes against git before you even invoked the\n> first command, with that attitude.\n>\n> If you are *serious* about having *git* work for you, it will.\n> Thousands of projects are using git every day.\n>\n> But if you're looking at git like \"it's not hg, and I already hate\n> that\", you'll end up sounding like you have in the past few days.\n>\n> Methinks *this* is the actual problem. Not git.\nIt's not just hg. It's other source code control systems as well. \nCheck out any of the other daggy guys. So sure, I'll admit a bias for \ncurrent technology over older tech.\n\nAnother part of the problem is that git is badly designed, poorly \ndocumented, and the terminology is inconsistent. That, and the \nlimitations make for a pretty steep learning curve.\n\nAnd a third part of the problem is that coming from a number of other \ndaggy tools, I was expecting a lot more out of git that what git \nactually provides. Certainly, git can be used to do whatever, but a \npile of sand and some plastic can be made into a computer too, if we're \nwilling to put enough effort into it.\n\nBut hey, I'm using it. (I refuse to work with perforce). I had an even \nworse bias against mecurial before I started using it. The big learning \ncurve was from the linear tools to the daggy tools which happened for me \nwith monotone.\n\n--rich\n"},{"id":"190689","messageId":"7vipgddl9m.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"CAMOZ1BuiznhrzEOHe0N+uu=mLEw5wWTQyDpnwG8PuF1f_aNaXw@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-03T21:09:41Z","receivedAt":"2012-05-03T21:09:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Witten writes:\n\n> (Note, though, that Junio has done a laudable job of keeping the\n> whole experiment going strong).\n\nYou are giving me too much credit, and at the same time insulting the\npeople who polished Git enough to suit their workflow. To them, the tool\nhas past \"experiment\" stage long time ago. They found what was lacking\nand what would help the need in their workflow. I just have helped them\nshape their ideas into a coherent whole.\n\nThat does not mean there is nothing missing, still appears experimental,\nor inconsistent in the parts of the system that these people do not use\nnor care about, and when you bring in people coming from different\nbackground, they will notice the behaviour or default that do not match\ntheir expectation. They can do the usual \"scratching own itches\" thing\nthe same way to others who have done before. As nobody forces them to do\nso, they can instead keep whining. It's mostly their choice.\n"},{"id":"190691","messageId":"7vehr1dl2z.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"87obq5ggpu.fsf@an-dro.info.enstb.org","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-03T21:13:40Z","receivedAt":"2012-05-03T21:13:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ronan Keryell writes:\n\n>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley said:\n>\n> Rich> * the hg error messages are straightforward, clear, and don't\n> Rich> require any deep knowledge of the source code control system\n> Rich> or it's limitations. (I still don't understand what the git\n> Rich> message on collision is saying.)\n>\n> This is a very good suggestion.\n> ...\n> At least, print a simpler message with some typical use case causing\n> this and some workflow ideas before the detailed explanation.\n\nIt indeed is a good starting point to make a suggestion, but there is\nnothing actionable in the above by itself, especially since \"typical use\ncase\" is quite different for different Git users.\n"},{"id":"190698","messageId":"87y5p8dhu4.fsf@an-dro.info.enstb.org","threadId":"30372","inReplyTo":"7vehr1dl2z.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Ronan Keryell","fromEmail":"ronan.keryell@hpc-project.com","sentAt":"2012-05-03T22:23:47Z","receivedAt":"2012-05-03T22:23:47Z","isPatch":false,"sender":{"key":"ronan.keryell@hpc-project.com","avatar":null},"body":">>>>> On Thu, 03 May 2012 14:13:40 -0700, Junio C Hamano said:\n\n >> This is a very good suggestion. ... At least, print a simpler\n >> message with some typical use case causing this and some workflow\n >> ideas before the detailed explanation.\n\n Junio> It indeed is a good starting point to make a suggestion, but\n Junio> there is nothing actionable in the above by itself,\n Junio> especially since \"typical use case\" is quite different for\n Junio> different Git users.\n\nRight.\n\nJust add a new git config entry defining \"typical use case\". :-)\nAnd we can recurse to define what is the default value of this and so\non... :-)\n\nJust to be constructive, in the previous case, adding something like\n\"It appears that you are trying to push some modifications on a remote\nserver on a branch that has been updated. It may be due to someone\nhaving worked on it in the meantime. To go on, you may first do a\ngit merge .... \nand try again after solving this so that we are able to precisely track\nthe real history of your project.\"\n\nThe last sentence is to motivate the user to do what may be complicated\nwhen coming from, say, SVN, and who do not really care with... real\nhistory. ;-)\n\nWell I'm not a native English speaker, but I hope you can get the idea.\n\nAfter that, there are some other use cases, but I'm not sure that in\nthis case this kind of message would help, because you may have some\ndeeper knowledge of git anyway.\n\nFor example for my software testing infrastructure, I push some stuff on\nsome remote git and I force the update of the remote branch anyway with\na git push -f. If I forgot the '-f' I would have the same error message\nabove that would not be helpful for me. But anyway, this message is not\nneeded since I use git for my very own specific purpose in this case.\n-- \n Ronan KERYELL |\\/ Phone: +1 408 658 9453\n Wild Systems / HPC Project |/)\n 5201 Great America Parkway, Suite 320 K Ronan.Keryell@wild-systems.com\n Santa Clara, CA 95054 |\\ skype:keryell\n USA | \\ http://wild-systems.com\n"},{"id":"190699","messageId":"4FA307C5.102@palm.com","threadId":"30372","inReplyTo":"7vehr1dl2z.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T22:33:41Z","receivedAt":"2012-05-03T22:33:41Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/3/12 14:13 , Junio C Hamano wrote:\n> Ronan Keryell writes:\n>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley said:\n>> Rich> * the hg error messages are straightforward, clear, and don't\n>> Rich> require any deep knowledge of the source code control system\n>> Rich> or it's limitations. (I still don't understand what the git\n>> Rich> message on collision is saying.)\n>>\n>> This is a very good suggestion.\n>> ...\n>> At least, print a simpler message with some typical use case causing\n>> this and some workflow ideas before the detailed explanation.\n> It indeed is a good starting point to make a suggestion, but there is\n> nothing actionable in the above by itself, especially since \"typical use\n> case\" is quite different for different Git users.\nHow about, \"Your push can't be made because it would cause an \nirreconcilable collision. You probably want to pull and merge before \nattempting to push again.\"\n\n--rich\n"},{"id":"190700","messageId":"4FA3090D.5080406@palm.com","threadId":"30372","inReplyTo":"4FA307C5.102@palm.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T22:39:09Z","receivedAt":"2012-05-03T22:39:09Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/3/12 15:33 , Rich Pixley wrote:\n> On 5/3/12 14:13 , Junio C Hamano wrote:\n>> Ronan Keryell writes:\n>>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich Pixley said:\n>>> Rich> * the hg error messages are straightforward, clear, and don't\n>>> Rich> require any deep knowledge of the source code control system\n>>> Rich> or it's limitations. (I still don't understand what the git\n>>> Rich> message on collision is saying.)\n>>>\n>>> This is a very good suggestion.\n>>> ...\n>>> At least, print a simpler message with some typical use case causing\n>>> this and some workflow ideas before the detailed explanation.\n>> It indeed is a good starting point to make a suggestion, but there is\n>> nothing actionable in the above by itself, especially since \"typical use\n>> case\" is quite different for different Git users.\n> How about, \"Your push can't be made because it would cause an\n> irreconcilable collision. You probably want to pull and merge before\n> attempting to push again.\"\n\nEr... \"Your push can't be made because it would cause an irreconcilable \ncollision. You probably want to fetch and merge before attempting to \npush again.\"\n\n--rich\n"},{"id":"190701","messageId":"4FA30A68.5010002@palm.com","threadId":"30372","inReplyTo":"7vipgddl9m.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-03T22:44:56Z","receivedAt":"2012-05-03T22:44:56Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/3/12 14:09 , Junio C Hamano wrote:\n> Michael Witten writes:\n>\n>> (Note, though, that Junio has done a laudable job of keeping the\n>> whole experiment going strong).\n>\n> You are giving me too much credit, and at the same time insulting the\n> people who polished Git enough to suit their workflow. To them, the tool\n> has past \"experiment\" stage long time ago. They found what was lacking\n> and what would help the need in their workflow. I just have helped them\n> shape their ideas into a coherent whole.\n>\n> That does not mean there is nothing missing, still appears experimental,\n> or inconsistent in the parts of the system that these people do not use\n> nor care about, and when you bring in people coming from different\n> background, they will notice the behaviour or default that do not match\n> their expectation. They can do the usual \"scratching own itches\" thing\n> the same way to others who have done before. As nobody forces them to do\n> so, they can instead keep whining. It's mostly their choice.\n\nOnce you've been bitten, and learned to shy away from the sore spot, you \ndon't really have much motivation to change it. The motivation to \nchange it would be to make it easier for the next person.\n\nGit clearly doesn't have much of that value in the community culture.\n\n--rich\n"},{"id":"190703","messageId":"861un0j2qe.fsf@red.stonehenge.com","threadId":"30372","inReplyTo":"4FA30A68.5010002@palm.com","subject":"Re: Newbie grief","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2012-05-03T22:53:29Z","receivedAt":"2012-05-03T22:53:29Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Rich\" == Rich Pixley writes:\n\nRich> Git clearly doesn't have much of that value in the community\nRich> culture.\n\nYou don't know how wrong you are. Good luck getting help after\ndisrespecting the very people who *are* trying to help you.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"190704","messageId":"7v1un0euqm.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"4FA30A68.5010002@palm.com","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-03T22:59:45Z","receivedAt":"2012-05-03T22:59:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rich Pixley writes:\n\n> On 5/3/12 14:09 , Junio C Hamano wrote:\n>> Michael Witten writes:\n>>\n>>> (Note, though, that Junio has done a laudable job of keeping the\n>>> whole experiment going strong).\n>>\n>> You are giving me too much credit, and at the same time insulting the\n>> people who polished Git enough to suit their workflow. To them, the tool\n>> has past \"experiment\" stage long time ago. They found what was lacking\n>> and what would help the need in their workflow. I just have helped them\n>> shape their ideas into a coherent whole.\n>>\n>> That does not mean there is nothing missing, still appears experimental,\n>> or inconsistent in the parts of the system that these people do not use\n>> nor care about, and when you bring in people coming from different\n>> background, they will notice the behaviour or default that do not match\n>> their expectation....\n> \n> ... The motivation to\n> change it would be to make it easier for the next person.\n\nThat is how the workflow support elements that were originally missing\nlike reflogs, stashes, tracking branches, etc. all came to exist. Making\nit easier for the next person is why we had a large discussion on the\ndefault behaviour of unconfigured push andthe follow-up implementation of\nthe \"simple\" push behaviour. It is a good example that community members\nare willing to help new person even at the expense of inconvenience to old\ntimers.\n\nWhat does _not_ happen is to chase down people who whined and left without\ngiving us something concrete enough to base design of new workflow support\nelements, but the community cannot police the behaviour of those who come,\nwhine and then leave, so...\n"},{"id":"190705","messageId":"da7535728c9a0ad2a27e83078492efa0@ulrik.uio.no","threadId":"30372","inReplyTo":"4FA2CC88.9000207@palm.com","subject":"Re: Newbie grief","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-05-03T23:04:24Z","receivedAt":"2012-05-03T23:04:24Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" On Thu, 03 May 2012 11:20:56 -0700, Rich Pixley \n wrote:\n> On 5/3/12 09:08 , Hallvard Breien Furuseth wrote:\n>> Aha, now this thread finally makes some sense. So when Rich\n>> wants a \"branch\" with several tips, he actually wants several\n>> Git clones (repositories) with the same Git branch checked out -\n>> and some of them with local commits to it.\n> Yes.\n>> And these commits can be shared as remote branches between the\n>> clones, which in Hg-speak means that in one particular clone,\n>> Git will \"bookmark\" the other clones' tips.\n> Well, no. In hg, these are all managed. So there's no scaling\n> issue. They can all push/pull together, since they are really all\n> just one shared branch. Adding a new repository to the mix is\n> trivial. And either pushes or pulls can be used, or any combo.\n>\n> With git, I must manually make space for each and every repository,\n> manually track which set of changes are where, manually track which\n> need to be merged, and manually track which repositories are looking\n> at which git branches so that they don't collide, or only collide in\n> the current repository and only when I'm prepared to merge them.\n> (...)\n\n If you say so. I don't know Hg and I'm not about to try to guess\n if you're stuck in another misconception about Git or not, nor\n to re-read this entire thread substituting \"clone\" for \"branch\".\n\n Anyway, I notice you're now giving practical Hg examples to go\n with your Hg vocabulary instead talking Git in Hg vocabulary, so\n hopefully this'll get cleared up.\n\n Anyway, if you have not done so already: If you show this too with\n a practical Hg example instead of talking Git in a Hg vocabulary,\n maybe someone can help.\n\n-- \n Hallvard\n"},{"id":"190707","messageId":"5846cb41607f384fb2bd7c46ea896f25@ulrik.uio.no","threadId":"30372","inReplyTo":"da7535728c9a0ad2a27e83078492efa0@ulrik.uio.no","subject":"Re: Newbie grief","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-05-03T23:06:54Z","receivedAt":"2012-05-03T23:06:54Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" I wrote:\n> Anyway, (...) Anyway, (...)\n\n Meh. I hate cut&paste into/out of webmail.\n\n-- \n Hallvard\n"},{"id":"190710","messageId":"4FA32A6A.4070007@blizzard.com","threadId":"30372","inReplyTo":"4FA3090D.5080406@palm.com","subject":"Re: Newbie grief","fromName":"Illia Bobyr","fromEmail":"ibobyr@blizzard.com","sentAt":"2012-05-04T01:01:30Z","receivedAt":"2012-05-04T01:01:30Z","isPatch":false,"sender":{"key":"ibobyr@blizzard.com","avatar":null},"body":"On 5/3/2012 3:39 PM, Rich Pixley wrote:\n> On 5/3/12 15:33 , Rich Pixley wrote:\n>> On 5/3/12 14:13 , Junio C Hamano wrote:\n>>> Ronan Keryell writes:\n>>>>>>>>> On Thu, 03 May 2012 12:13:46 -0700, Rich \n>>>>>>>>> Pixley said:\n>>>> Rich> * the hg error messages are straightforward, clear, \n>>>> and don't\n>>>> Rich> require any deep knowledge of the source code control \n>>>> system\n>>>> Rich> or it's limitations. (I still don't understand what \n>>>> the git\n>>>> Rich> message on collision is saying.)\n>>>>\n>>>> This is a very good suggestion.\n>>>> ...\n>>>> At least, print a simpler message with some typical use case causing\n>>>> this and some workflow ideas before the detailed explanation.\n>>> It indeed is a good starting point to make a suggestion, but there is\n>>> nothing actionable in the above by itself, especially since \"typical \n>>> use\n>>> case\" is quite different for different Git users.\n>> How about, \"Your push can't be made because it would cause an\n>> irreconcilable collision. You probably want to pull and merge before\n>> attempting to push again.\"\n>\n> Er... \"Your push can't be made because it would cause an \n> irreconcilable collision. You probably want to fetch and merge before \n> attempting to push again.\"\n\nWhile this error message makes more sense to you at this point it is not \nentirely true.\nThe collision is not irreconcilable and may not even be a collision. \nFor example, if you just rebased, it is not a collision from a more \nabstract point of view.\n\nIt is just a \"non-fast forward\" move of a branch tip. This term \ndescribes what happens precisely :)\n\nIt is true, that the term is non obvious to the new comers.\nOne may google and get an explanation of the error pretty quickly. \nFirst hit for \"git non fast forward error\" gives an explanation from a \nnew comer point of view for the simplest case.\n\nAnother option is to change the way git \"talks\". AFAIR there were a \nnumber of attempts to come up with a new dictionary for git.\nI am not sure if any of the attempts were complete as it is not that easy.\nChanging just one error message at a time would make it less consistent \nas a concept of \"fast forward\" moves is used in other places.\nFor example, git merge has --ff and --no-ff options that stand for \"fast \nforwrad\" and \"no fast forward\" respectively.\n\nIllia Bobyr"},{"id":"190713","messageId":"CA+7g9Jxp859st6SrViizwOMrU9vsnmfy6P64SK9y_-ZEzEB6Mw@mail.gmail.com","threadId":"30372","inReplyTo":"4FA32A6A.4070007@blizzard.com","subject":"Re: Newbie grief","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-05-04T03:13:01Z","receivedAt":"2012-05-04T03:13:01Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr wrote:\n>\n> It is just a \"non-fast forward\" move of a branch tip.  This term\n> describes what happens precisely :)\n>\n> It is true, that the term is non obvious to the new comers.\n> One may google and get an explanation of the error pretty quickly.\n> First hit for \"git non fast forward error\" gives an explanation from a\n> new comer point of view for the simplest case.\n\nI just led a team of reasonably bright people through a transition\nfrom SVN to git. Not one of them understood this message. Every one\nof them thought something was broken. This is a very common\noccurrence, so a short, simple message without jargon for this error\nwould be a big, big win.\n\nCheers,\n-n8\n\n-- \nHexaLex: A New Angle on Crossword Games for iPhone and iPod Touch\nhttp://hexalex.com\nOn The App Store: http://bit.ly/8Mj1CU\nOn Facebook: http://bit.ly/9MIJiV\nOn Twitter: http://twitter.com/hexalexgame\nhttp://n8gray.org\n"},{"id":"190716","messageId":"1167779eee7d442b9db0eecb347d5516-mfwitten@gmail.com","threadId":"30372","inReplyTo":"CA+7g9Jxp859st6SrViizwOMrU9vsnmfy6P64SK9y_-ZEzEB6Mw@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2012-05-04T04:20:18Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, 3 May 2012 20:13:01 -0700, Nathan Gray wrote:\n\n> On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr wrote:\n>>\n>> It is just a \"non-fast forward\" move of a branch tip.  This term\n>> describes what happens precisely :)\n>>\n>> It is true, that the term is non obvious to the new comers.\n>> One may google and get an explanation of the error pretty quickly.\n>> First hit for \"git non fast forward error\" gives an explanation from a\n>> new comer point of view for the simplest case.\n>\n> I just led a team of reasonably bright people through a transition\n> from SVN to git. Not one of them understood this message. Every one\n> of them thought something was broken. This is a very common\n> occurrence, so a short, simple message without jargon for this error\n> would be a big, big win.\n\nWell, what is your suggestion?\n\nNobody in this thread has yet provided an explicit improvement because\nthe actual complaint is that the vast majority of people (including\nsupposed \"professionals\") don't RTFM; it never even occurs to them!\n\nLet's look at the message in question:\n\n To $uri_for_central_repo\n ! [rejected] HEAD -> feature_0 (non-fast-forward)\n error: failed to push some refs to '$uri_for_central_repo'\n To prevent you from losing history, non-fast-forward updates were rejected\n Merge the remote changes (e.g. 'git pull') before pushing again. See the\n 'Note about fast-forwards' section of 'git push --help' for details.\n\nNot only does this already spoonfeed the reader with a suggested\ncommand for getting back on track (i.e., 'git pull'), but it also\nexplicitly points out the relevant documentation and HOW to gain\nimmediate access to that information from the command line!\n\nAs for a seemingly conservative suggestion, how about using a little\nmore structural white space:\n\n To $uri_for_central_repo\n ! [rejected] HEAD -> feature_0 (non-fast-forward)\n\n error: failed to push some refs to '$uri_for_central_repo'\n\n To prevent you from losing history, non-fast-forward updates were rejected\n Merge the remote changes (e.g. 'git pull') before pushing again. See the\n 'Note about fast-forwards' section of 'git push --help' for details.\n\nAlas! Error output like this is constructed in the code in a way that\npotentially makes adding such white space non-trivial.\n\nPerhaps the error message system needs an overhall; rather than spitting\nout error messages from anywhere, they ought to be corralled and collated\nby a dedicated subsystem.\n"},{"id":"190719","messageId":"7vmx5ocyc3.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"1167779eee7d442b9db0eecb347d5516-mfwitten@gmail.com","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-04T05:25:00Z","receivedAt":"2012-05-04T05:25:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Witten writes:\n\n> As for a seemingly conservative suggestion, how about using a little\n> more structural white space:\n>\n> To $uri_for_central_repo\n> ! [rejected] HEAD -> feature_0 (non-fast-forward)\n>\n> error: failed to push some refs to '$uri_for_central_repo'\n>\n> To prevent you from losing history, non-fast-forward updates were rejected\n> Merge the remote changes (e.g. 'git pull') before pushing again. See the\n> 'Note about fast-forwards' section of 'git push --help' for details.\n>\n> Alas! Error output like this is constructed in the code in a way that\n> potentially makes adding such white space non-trivial.\n>\n> Perhaps the error message system needs an overhall; rather than spitting\n> out error messages from anywhere, they ought to be corralled and collated\n> by a dedicated subsystem.\n\nDidn't somebody recently rework these messages quite extensively?\n"},{"id":"190743","messageId":"1336126182.3490.28.camel@beez.lab.cmartin.tk","threadId":"30372","inReplyTo":"7vmx5ocyc3.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-05-04T10:09:42Z","receivedAt":"2012-05-04T10:09:42Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote:\n> Michael Witten writes:\n> \n> > As for a seemingly conservative suggestion, how about using a little\n> > more structural white space:\n> >\n> > To $uri_for_central_repo\n> > ! [rejected] HEAD -> feature_0 (non-fast-forward)\n> >\n> > error: failed to push some refs to '$uri_for_central_repo'\n> >\n> > To prevent you from losing history, non-fast-forward updates were rejected\n> > Merge the remote changes (e.g. 'git pull') before pushing again. See the\n> > 'Note about fast-forwards' section of 'git push --help' for details.\n> >\n> > Alas! Error output like this is constructed in the code in a way that\n> > potentially makes adding such white space non-trivial.\n> >\n> > Perhaps the error message system needs an overhall; rather than spitting\n> > out error messages from anywhere, they ought to be corralled and collated\n> > by a dedicated subsystem.\n> \n> Didn't somebody recently rework these messages quite extensively?\n\nIf you're thinking of me, I only changed the pull/rebase side, which was\na ridiculously bad message. As this subthread looks like it might\nactually have something actionable, let me look at this message with the\nsame critical eyes.\n\nMost of the first sentence repeats what we can see above. Restating that\nnon-ff updates were rejected doesn't add information and doesn't help\npeople who don't already know what a non-ff update is, so it's either\nredundant or not helpful[0]. So lets see if we can come up with a\nfriendlier way of saying it. Maybe something like:\n\n To $uri_for_central_repo\n ! [rejected] HEAD -> feature_0 (non-fast-forward)\n\n error: failed to push some refs to '$uri_for_central_repo'\n\n Some updates which might rewrite history and lose someone else's\n changes were rejected. Merge those changes (e.g. 'git pull') to\n incorporate that history. See the 'Note about fast-forwards' section\n of 'git push --help' for details.\n\nIt may be a bit longer, but if you don't know what a non-ff is or why\nit's a problem, this text should help you a lot more than the previous\none did. Not reading the documentation (specially when the error message\npoints you to a specific section for a longer explanation) is still no\nexcuse for not known what's going on, but if you've been working on your\nown for a while, you might have forgotten what this is all about.[1]\n\nIf people don't have it, I'll try to find time to create a patch.\n\n cmn\n\n[0] Or worse, as repeating jargon can leave the user thinking that they\ndon't understand anything and reduces the chanced they'd try to figure\nout the missing parts. I'd qualify this with friendliness rather than\nanything else, as the message isn't wrong or misleading, just rather\non-your-face.\n\n[1] At least this is show I rationalise why doing saying \"non-ff updates\nrejected. Read the ff section of the push manpage for an explanation\"\nisn't the right thing to do.\n\n"},{"id":"190754","messageId":"4FA3E31A.6060606@op5.se","threadId":"30372","inReplyTo":"4FA2D565.1080806@palm.com","subject":"Re: Newbie grief","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-05-04T14:09:30Z","receivedAt":"2012-05-04T14:09:30Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 05/03/2012 08:58 PM, Rich Pixley wrote:\n> On 5/1/12 16:30 , Felipe Contreras wrote:\n>> Show all the hg commands of what you are trying to do, and we can show\n>> you how you can achieve the same in git, but much more easily.\n> hg init foo\n> for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg clone foo foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci -m $d)); done\n> for i in foo-*; do (set -x ; (cd $i && hg push -f)); done\n> \n\nHere's how that would look in git (though I got rid of the timestamp\nstuff and used seq instead):\n\ngit init foo\nfor i in $(seq 1 4000); do git clone foo foo-$i; (cd foo-$i && date > bar && git add bar && git commit -m \"$i\"; done)\nfor i in foo-*; do (set -x; (cd $i && git push master:$i/master)); done\n\nThe hg recipe creates 4000 branches which I for some reason can't\nfind the names of so I have no idea how to interact with them. The\ngit recipe names them explicitly to foo-$i/master in the foo/ repo,\nsince git doesn't allow pushing of commits without a ref.\n\n\nHaving read further in the thread, I see you did \"hg merge\" to merge\n*all* the branches (which is impressive in itself, doing a 4000-way\nmerge), but I still don't see how you'd go about merging just one of\nthem. Perhaps that's not desirable.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"190755","messageId":"7vehr0c852.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"1336126182.3490.28.camel@beez.lab.cmartin.tk","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-04T14:50:49Z","receivedAt":"2012-05-04T14:50:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto writes:\n\n> On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote:\n>> Michael Witten writes:\n>> \n>> > As for a seemingly conservative suggestion, how about using a little\n>> > more structural white space:\n>> >\n>> > To $uri_for_central_repo\n>> > ! [rejected] HEAD -> feature_0 (non-fast-forward)\n>> >\n>> > error: failed to push some refs to '$uri_for_central_repo'\n>> >\n>> > To prevent you from losing history, non-fast-forward updates were rejected\n>> > Merge the remote changes (e.g. 'git pull') before pushing again. See the\n>> > 'Note about fast-forwards' section of 'git push --help' for details.\n>> >\n>> > Alas! Error output like this is constructed in the code in a way that\n>> > potentially makes adding such white space non-trivial.\n>> >\n>> > Perhaps the error message system needs an overhall; rather than spitting\n>> > out error messages from anywhere, they ought to be corralled and collated\n>> > by a dedicated subsystem.\n>> \n>> Didn't somebody recently rework these messages quite extensively?\n>\n> If you're thinking of me,...\n\nNo, I was referring to f25950f (push: Provide situational hints for\nnon-fast-forward errors, 2012-03-20).\n"},{"id":"190756","messageId":"6211a2de-a545-41c3-9fb5-e7e3033b45f4@mail","threadId":"30372","inReplyTo":"4FA3E31A.6060606@op5.se","subject":"Re: Newbie grief","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2012-05-04T14:59:30Z","receivedAt":"2012-05-04T14:59:30Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"----- Original Message -----\n> From: \"Andreas Ericsson\" \n> Sent: Friday, May 4, 2012 10:09:30 AM\n> Subject: Re: Newbie grief\n> \n> On 05/03/2012 08:58 PM, Rich Pixley wrote:\n> > On 5/1/12 16:30 , Felipe Contreras wrote:\n> > > Show all the hg commands of what you are trying to do, and we can\n> > > show you how you can achieve the same in git, but much more\n> > > easily.\n> >\n> > hg init foo\n> > for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg\n> > clone foo foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci\n> > -m $d)); done\n> > for i in foo-*; do (set -x ; (cd $i && hg push -f)); done\n>\n> ... snip ... \n> \n> The hg recipe creates 4000 branches which I for some reason can't\n> find the names of so I have no idea how to interact with them. The\n> git recipe names them explicitly to foo-$i/master in the foo/ repo,\n> since git doesn't allow pushing of commits without a ref.\n\nIf my hg-foo isn't too out of date... The hg recipe creates 4000 \"heads\" on a single branch, rather than 4000 branches (see the 'hg heads' command). This is basically the point Rich is arguing I believe. hg allows for multiple tip commits all with the same branch name (IMO this is important because hg branch names are permanently recorded in their version of the commit object).\n\nThis is a *fundamental* difference in the implementation of the two tools (and causes confusion because now \"branch\" has two slightly different meanings). However, IMHO, philosophically it all boils down to the same thing: development has forked and has to be merged. Whether that fork has a name or not is up to the tool. In hg it doesn't *have* to have a name (multiple heads per branch), in git it does (single head per branch).\n\nI personally find Git's enforcement of naming a good thing: either the change I just made should be incorporated into the original branch, or there is a reason for it to stay separate. In the latter case I should name it in a meaningful way so I (and other team members) remember why it is being kept separate (similar to why we use meaningful variable names). In the former, I fetch and then merge or rebase as appropriate before pushing back upstream.\n\nHTH,\nStephen\n"},{"id":"190762","messageId":"20120504155606.GB30130@sirena.org.uk","threadId":"30372","inReplyTo":"4FA2F013.3020904@palm.com","subject":"Re: Newbie grief","fromName":"Mark Brown","fromEmail":"broonie@opensource.wolfsonmicro.com","sentAt":"2012-05-04T15:56:06Z","receivedAt":"2012-05-04T15:56:06Z","isPatch":false,"sender":{"key":"broonie@opensource.wolfsonmicro.com","avatar":"https://gravatar.com/avatar/5fb25e4e0de3255caa21123e2b518c314d26245069221ff55910d5c6ba3343c4?d=mp&s=160"},"body":"On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:\n\n> It's not just hg. It's other source code control systems as well.\n> Check out any of the other daggy guys. So sure, I'll admit a bias\n> for current technology over older tech.\n\nI'm still not sure what's missing here without a central server? The\nother DVCSs I've used (which don't include hg) do require that the user\ntrigger a merge operation somehow; they don't magically go and merge\nthings without being asked. The only thing I've noticed that git does\ndifferently is that it caches the remote branches locally by default\nwhen remotes are set up.\n"},{"id":"190766","messageId":"20120504162947.GA2311@sirena.org.uk","threadId":"30372","inReplyTo":"6211a2de-a545-41c3-9fb5-e7e3033b45f4@mail","subject":"Re: Newbie grief","fromName":"Mark Brown","fromEmail":"broonie@opensource.wolfsonmicro.com","sentAt":"2012-05-04T16:29:48Z","receivedAt":"2012-05-04T16:29:48Z","isPatch":false,"sender":{"key":"broonie@opensource.wolfsonmicro.com","avatar":"https://gravatar.com/avatar/5fb25e4e0de3255caa21123e2b518c314d26245069221ff55910d5c6ba3343c4?d=mp&s=160"},"body":"On Fri, May 04, 2012 at 10:59:30AM -0400, Stephen Bash wrote:\n\n> If my hg-foo isn't too out of date... The hg recipe creates 4000\n> \"heads\" on a single branch, rather than 4000 branches (see the 'hg\n> heads' command). This is basically the point Rich is arguing I\n> believe. hg allows for multiple tip commits all with the same branch\n> name (IMO this is important because hg branch names are permanently\n> recorded in their version of the commit object).\n\n> This is a *fundamental* difference in the implementation of the two\n> tools (and causes confusion because now \"branch\" has two slightly\n> different meanings). However, IMHO, philosophically it all boils down\n> to the same thing: development has forked and has to be merged.\n> Whether that fork has a name or not is up to the tool. In hg it\n> doesn't *have* to have a name (multiple heads per branch), in git it\n> does (single head per branch).\n\nAh, this makes some sense - I *think* it's coming down not so much that\nyou have to name the branches (googling around it seems hg does assign\nnames, it's just that they're autogenerated numbers) as to the fact that\nunless you branch directly from wherever your origin repository is git\ndoesn't keep track of where you're ultimately trying to merge development\nback to.\n\nIf the above is right then some UI around remotes and branch --track and\n--set-upstream which provides an automated way of saying \"this is a\nscratch branch for merge into X\" and can then do things like helping\nwith merging and enumerating all the scratch branches for a given\ndestination, or with bundling up all the scratch branches and dropping\nthem elsewhere for merge might do the trick? A \"strong\" branch kind of\nthing.\n\nThis does come up a bit with traditional git workflows - I have it a\nlittle when working between my desktop and my laptop - but is IME\nusually resolved by publishing frequently to some central location\nfrequently and then rebasing if lots of local merges aren't approved of\nin your workflow. git (at least in kernel usage) has more of a\n\"building a patch series\" model oriented around preparing things for\nreview.\n"},{"id":"190767","messageId":"CA+7g9Jx20q6C8JqrcrmbWhYNH1K35Gwp_BAckjM=8qg1kMwU4Q@mail.gmail.com","threadId":"30372","inReplyTo":"1336126182.3490.28.camel@beez.lab.cmartin.tk","subject":"Re: Newbie grief","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-05-04T16:46:04Z","receivedAt":"2012-05-04T16:46:04Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"On Fri, May 4, 2012 at 3:09 AM, Carlos Martín Nieto wrote:\n> On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote:\n>> Michael Witten writes:\n>>\n>> > As for a seemingly conservative suggestion, how about using a little\n>> > more structural white space:\n>> >\n>> >   To $uri_for_central_repo\n>> >    ! [rejected]        HEAD -> feature_0 (non-fast-forward)\n>> >\n>> >   error: failed to push some refs to '$uri_for_central_repo'\n>> >\n>> >   To prevent you from losing history, non-fast-forward updates were rejected\n>> >   Merge the remote changes (e.g. 'git pull') before pushing again.  See the\n>> >   'Note about fast-forwards' section of 'git push --help' for details.\n>> >\n>\n> Most of the first sentence repeats what we can see above. Restating that\n> non-ff updates were rejected doesn't add information and doesn't help\n> people who don't already know what a non-ff update is, so it's either\n> redundant or not helpful[0]. So lets see if we can come up with a\n> friendlier way of saying it. Maybe something like:\n>\n>    To $uri_for_central_repo\n>    ! [rejected]        HEAD -> feature_0 (non-fast-forward)\n>\n>    error: failed to push some refs to '$uri_for_central_repo'\n>\n>    Some updates which might rewrite history and lose someone else's\n>    changes were rejected. Merge those changes (e.g. 'git pull') to\n>    incorporate that history. See the 'Note about fast-forwards' section\n>    of 'git push --help' for details.\n>\n> It may be a bit longer, but if you don't know what a non-ff is or why\n> it's a problem, this text should help you a lot more than the previous\n> one did. Not reading the documentation (specially when the error message\n> points you to a specific section for a longer explanation) is still no\n> excuse for not known what's going on, but if you've been working on your\n> own for a while, you might have forgotten what this is all about.[1]\n\nThe whitespace that Michael introduced is a big help, for starters,\nand this rewording is also a nice step forward. I'm still not\nthrilled about the \"rewriting history\" verbiage -- that makes it sound\nlike the user did something super risky and was rescued by the system.\n Here's my suggestion for replacing the last paragraph:\n\n Some of your branches are out of date. Merge the remote changes\n(e.g. 'git pull') then try again.\n\nIt's short and easy to scan. It has no git-specific jargon that new\nusers would be unfamiliar with. There's no reference to fast-forward\nupdates so no need to refer the user to that help section. What do\nyou think?\n\nCheers,\n-n8\n\n-- \nHexaLex: A New Angle on Crossword Games for iPhone and iPod Touch\nhttp://hexalex.com\nOn The App Store: http://bit.ly/8Mj1CU\nOn Facebook: http://bit.ly/9MIJiV\nOn Twitter: http://twitter.com/hexalexgame\nhttp://n8gray.org\n"},{"id":"190769","messageId":"4FA40F2A.7070109@blizzard.com","threadId":"30372","inReplyTo":"CA+7g9Jx20q6C8JqrcrmbWhYNH1K35Gwp_BAckjM=8qg1kMwU4Q@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Illia Bobyr","fromEmail":"ibobyr@blizzard.com","sentAt":"2012-05-04T17:17:30Z","receivedAt":"2012-05-04T17:17:30Z","isPatch":false,"sender":{"key":"ibobyr@blizzard.com","avatar":null},"body":"On 5/4/2012 9:46 AM, Nathan Gray wrote:\n> On Fri, May 4, 2012 at 3:09 AM, Carlos Martín Nieto wrote:\n>> On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote:\n>>> Michael Witten writes:\n>>>\n>>>> As for a seemingly conservative suggestion, how about using a little\n>>>> more structural white space:\n>>>>\n>>>> To $uri_for_central_repo\n>>>> ! [rejected] HEAD -> feature_0 (non-fast-forward)\n>>>>\n>>>> error: failed to push some refs to '$uri_for_central_repo'\n>>>>\n>>>> To prevent you from losing history, non-fast-forward updates were rejected\n>>>> Merge the remote changes (e.g. 'git pull') before pushing again. See the\n>>>> 'Note about fast-forwards' section of 'git push --help' for details.\n>>>>\n>> Most of the first sentence repeats what we can see above. Restating that\n>> non-ff updates were rejected doesn't add information and doesn't help\n>> people who don't already know what a non-ff update is, so it's either\n>> redundant or not helpful[0]. So lets see if we can come up with a\n>> friendlier way of saying it. Maybe something like:\n>>\n>> To $uri_for_central_repo\n>> ! [rejected] HEAD -> feature_0 (non-fast-forward)\n>>\n>> error: failed to push some refs to '$uri_for_central_repo'\n>>\n>> Some updates which might rewrite history and lose someone else's\n>> changes were rejected. Merge those changes (e.g. 'git pull') to\n>> incorporate that history. See the 'Note about fast-forwards' section\n>> of 'git push --help' for details.\n>>\n>> It may be a bit longer, but if you don't know what a non-ff is or why\n>> it's a problem, this text should help you a lot more than the previous\n>> one did. Not reading the documentation (specially when the error message\n>> points you to a specific section for a longer explanation) is still no\n>> excuse for not known what's going on, but if you've been working on your\n>> own for a while, you might have forgotten what this is all about.[1]\n> The whitespace that Michael introduced is a big help, for starters,\n> and this rewording is also a nice step forward. I'm still not\n> thrilled about the \"rewriting history\" verbiage -- that makes it sound\n> like the user did something super risky and was rescued by the system.\n> Here's my suggestion for replacing the last paragraph:\n>\n> Some of your branches are out of date. Merge the remote changes\n> (e.g. 'git pull') then try again.\n>\n> It's short and easy to scan. It has no git-specific jargon that new\n> users would be unfamiliar with. There's no reference to fast-forward\n> updates so no need to refer the user to that help section. What do\n> you think?\n\nNot everybody is a new user :)\nThrowing away a precise explanation for the purpose of avoiding a \npossible confusion for someone who either just started (and will have to \nlearn the terms anyway) or for someone who does not really care to learn \nis a decision that I would weight very carefully.\n\nJust as I side note, I lead a team of an ordinary developers through a \ntransition from CVS to Git and there were pretty much fine with the fact \nthat there are pieces in such a complex system as Git that they do not \nunderstand immediately. Over a couple of month everyone who cared or \nrequired this knowledge knew what a fast-forward is. And people who did \nnot care just learn to do git pull as the message suggests.\n\nI think that a reference to the documentation is very nice. I remember \nthat this kind of references allowed me to learn Git gradually as I was \nfacing different usage scenarios instead of reading the whole \ndocumentation for all the tools."},{"id":"190771","messageId":"7vsjffalqw.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"7vehr0c852.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-04T17:39:51Z","receivedAt":"2012-05-04T17:39:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Carlos Martín Nieto writes:\n>\n>>> Didn't somebody recently rework these messages quite extensively?\n>>\n>> If you're thinking of me,...\n>\n> No, I was referring to f25950f (push: Provide situational hints for\n> non-fast-forward errors, 2012-03-20).\n\nIf anybody wants to further discuss possible rephrasing of the advice\nmessages, please do not base your discussion without what was discussed\nalready in the previous round and what issues need to be taken into\naccount.\n\nA good text to use as the starting point of your discussion is the advice\nmessages in 'master'; use c5da24a (Merge branch 'ct/advise-push-default',\n2012-04-20) or anything more recent. Also see\n\n http://thread.gmane.org/gmane.comp.version-control.git/193079\n\nfor the discussion that led to the current text.\n"},{"id":"190772","messageId":"4FA418A7.2050100@palm.com","threadId":"30372","inReplyTo":"1167779eee7d442b9db0eecb347d5516-mfwitten@gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-04T17:57:59Z","receivedAt":"2012-05-04T17:57:59Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/3/12 21:35 , Michael Witten wrote:\n> On Thu, 3 May 2012 20:13:01 -0700, Nathan Gray wrote:\n>\n>> On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr wrote:\n>>> It is just a \"non-fast forward\" move of a branch tip. This term\n>>> describes what happens precisely :)\n>>>\n>>> It is true, that the term is non obvious to the new comers.\n>>> One may google and get an explanation of the error pretty quickly.\n>>> First hit for \"git non fast forward error\" gives an explanation from a\n>>> new comer point of view for the simplest case.\n>> I just led a team of reasonably bright people through a transition\n>> from SVN to git. Not one of them understood this message. Every one\n>> of them thought something was broken. This is a very common\n>> occurrence, so a short, simple message without jargon for this error\n>> would be a big, big win.\n> Well, what is your suggestion?\n>\n> Nobody in this thread has yet provided an explicit improvement because\n> the actual complaint is that the vast majority of people (including\n> supposed \"professionals\") don't RTFM; it never even occurs to them!\n>\n> Let's look at the message in question:\n>\n> To $uri_for_central_repo\n> ! [rejected] HEAD -> feature_0 (non-fast-forward)\n> error: failed to push some refs to '$uri_for_central_repo'\n> To prevent you from losing history, non-fast-forward updates were rejected\n> Merge the remote changes (e.g. 'git pull') before pushing again. See the\n> 'Note about fast-forwards' section of 'git push --help' for details.\n>\n> Not only does this already spoonfeed the reader with a suggested\n> command for getting back on track (i.e., 'git pull'), but it also\n> explicitly points out the relevant documentation and HOW to gain\n> immediate access to that information from the command line!\nLet's take it line by line.\n\n\"Rejected - mumble\" - the tool did not do what you asked.\n\"error: failed to mumble\" - your data is corrupt.\n\"To prevent you mumble mumble\" - you're not allowed to do what you want\n\nI stopped reading there.\n\nI'm not saying this is a correct interpretation. I'm offering it as a \ndata point from a sophisticated, although new, user.\n\nI've already offered a suggestion for rewording.\n\n--rich\n"},{"id":"190773","messageId":"4FA41B8B.8070000@palm.com","threadId":"30372","inReplyTo":"1336126182.3490.28.camel@beez.lab.cmartin.tk","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-04T18:10:19Z","receivedAt":"2012-05-04T18:10:19Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/4/12 03:09 , Carlos Martín Nieto wrote:\n> To $uri_for_central_repo\n> ! [rejected] HEAD -> feature_0 (non-fast-forward)\n>\n> error: failed to push some refs to '$uri_for_central_repo'\n>\n> Some updates which might rewrite history and lose someone else's\n> changes were rejected. Merge those changes (e.g. 'git pull') to\n> incorporate that history. See the 'Note about fast-forwards' section\n> of 'git push --help' for details.\n\nI'd like to suggest \"declined\" instead of \"failed\". \"error: failed\" \nsuggests an error in the data or in the tool rather than a default or a \nchoice on the part of a UI designer.\n\nThe first few times I got this error I presumed that it was telling me \nmy destination repository was corrupt. So I salvaged my changes with \ndiff and patch, trashed the repository, and cloned a fresh one, (which \ndidn't show this error when I pushed to it.)\n\n--rich\n"},{"id":"190776","messageId":"4FA41E8E.20900@palm.com","threadId":"30372","inReplyTo":"20120504155606.GB30130@sirena.org.uk","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-04T18:23:10Z","receivedAt":"2012-05-04T18:23:10Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/4/12 08:56 , Mark Brown wrote:\n> On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:\n>\n>> It's not just hg. It's other source code control systems as well.\n>> Check out any of the other daggy guys. So sure, I'll admit a bias\n>> for current technology over older tech.\n>\n> I'm still not sure what's missing here without a central server? The\n> other DVCSs I've used (which don't include hg) do require that the user\n> trigger a merge operation somehow; they don't magically go and merge\n> things without being asked.\n\nNor does hg. Rather, it allows the collision to be tracked within the \nsource code control tool so that anyone who wants to see it can do so, \nand so that anyone who wants to merge it can do so. The data flow paths \nfor collisions and proposed changes can follow precisely the same paths \nas any other code changes. No meta channel is required.\n\nThis is a different situation from either the one where I, specifically \nme, must merge or the one where I intend my changes to stay separated \nfrom other development, (a new \"branch\"). The situation with multiple \nheads allows the merge, the branch, even the decision about whether to \nmerge or branch, to be delayed indefinitely.\n\nThe fact that it allows for this also allows for a number of different \nrepository network architectures, all of which are blocked in git \nbecause of the push problem. In git, those decisions must be made \n_before_ the push.\n\nThere's also a possibility of nonterminating merges. That is, if my \nteam is making changes faster than you can merge them, then you'll never \nget to push your changes. With dual heads, you still can. And then \nanyone who wants to can merge them.\n\n--rich\n"},{"id":"190779","messageId":"20120504205707.119725f3@nemesis.grenouille.com","threadId":"30372","inReplyTo":"4FA2D8EA.7030809@palm.com","subject":"Re: Newbie grief","fromName":"Jérôme Benoit","fromEmail":"jerome.benoit@grenouille.com","sentAt":"2012-05-04T18:57:07Z","receivedAt":"2012-05-04T18:57:07Z","isPatch":false,"sender":{"key":"jerome.benoit@grenouille.com","avatar":null},"body":"On Thu, 03 May 2012 12:13:46 -0700\nRich Pixley wrote:\n\n \n> * the hg commands are simpler and have the defaults that we want, \n> primarily because no extra branches are required.\n\nYou can mimic them with a brand new porclain.\n\nFor example, the worklfow described here : \n\nhttp://nvie.com/posts/a-successful-git-branching-model/\n\nhave been implemented here : \n\nhttps://github.com/nvie/gitflow\n\nSince git do not have by design the multi HEAD hg design, you will\nstill not have it but all the glory command chains to mimic it can be\ndone with some shell scripts and a good knowledge of git internals. \n\nRegards, \n\n-- \nJérôme Benoit aka fraggle\nLa Météo du Net - http://grenouille.com\nOpenPGP Key ID : 9FE9161D\nKey fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D\n"},{"id":"190780","messageId":"CAMP44s34RDcPejbGXzThvE8VGGgZOQRx=0yMogk03D7T664+kw@mail.gmail.com","threadId":"30372","inReplyTo":"4FA2D565.1080806@palm.com","subject":"Re: Newbie grief","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-04T19:13:09Z","receivedAt":"2012-05-04T19:13:09Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 3, 2012 at 8:58 PM, Rich Pixley wrote:\n> On 5/1/12 16:30 , Felipe Contreras wrote:\n>>\n>> Show all the hg commands of what you are trying to do, and we can show\n>> you how you can achieve the same in git, but much more easily.\n>\n> hg init foo\n> for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg clone foo\n> foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci -m $d)); done\n> for i in foo-*; do (set -x ; (cd $i && hg push -f)); done\n\nWell, that's your problem right there; you are doing something totally stupid.\n\nEven the mercurial documentation tells you so:\n\n---\nBy default, push will not allow creation of new heads at the\ndestination, since multiple heads would make it unclear which head to\nuse. In this situation, it is recommended to pull and merge before\npushing.\n---\n\nThe git way (which happens to be the mercurial way too), is to fetch\nand merge (pull) before pushing:\n\ndo_commit() { (cd $1 && date +%N > bar && git add bar && git commit -m \"$2\") ;}\ngit init foo; do_commit foo \"Initial commit\"\nfor i in $(seq 1 10); do git clone foo foo-$i; do_commit foo-$i $i; done\nfor i in foo-*; do (set -x; (cd $i && git pull -s ours --no-edit; git\npush)); done\n\nDo you seriously think it makes sense to have 4000 people doing\nindependent development on 4000 different lines of development all\nignoring each other? Which of the 4000 heads would you pick to test\nthis \"branch\"? Who is going to do the merge of these 4000 heads?\n\nThis is a recipe for disaster.\n\nYou prefer a DVCS that allows you to do stupid stuff, well that's your\nchoice, but don't blame git for making it difficult for you to do\nstupid stuff. You should stop doing that and follow the git/mercurial\nway; fetch/pull, merge, and push.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"190781","messageId":"m3d36jrc74.fsf@localhost.localdomain","threadId":"30372","inReplyTo":"4FA41E8E.20900@palm.com","subject":"Re: Newbie grief","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-05-04T19:14:16Z","receivedAt":"2012-05-04T19:14:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Rich Pixley writes:\n> On 5/4/12 08:56 , Mark Brown wrote:\n> > On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:\n> >\n> > > It's not just hg. It's other source code control systems as well.\n> > > Check out any of the other daggy guys. So sure, I'll admit a bias\n> > > for current technology over older tech.\n> >\n> > I'm still not sure what's missing here without a central server? The\n> > other DVCSs I've used (which don't include hg) do require that the user\n> > trigger a merge operation somehow; they don't magically go and merge\n> > things without being asked.\n> \n> Nor does hg. Rather, it allows the collision to be tracked within the\n> source code control tool so that anyone who wants to see it can do so,\n> and so that anyone who wants to merge it can do so. The data flow\n> paths for collisions and proposed changes can follow precisely the\n> same paths as any other code changes. No meta channel is required.\n> \n> This is a different situation from either the one where I,\n> specifically me, must merge or the one where I intend my changes to\n> stay separated from other development, (a new \"branch\"). The\n> situation with multiple heads allows the merge, the branch, even the\n> decision about whether to merge or branch, to be delayed indefinitely.\n> \n> The fact that it allows for this also allows for a number of different\n> repository network architectures, all of which are blocked in git\n> because of the push problem. In git, those decisions must be made\n> _before_ the push.\n\nWell, perhaps Git doesn't support \"central repository\" workflow, where\nusers push to common repository, as well as Mercurial. The main\nworkflow is based on pairs of private (non-bare) + public (bare)\nrepositories, one pair for each developer. You push to own\nrepository, and pull from other public repositories.\n \nNote that there is no problem in Git in \"pull\" direction (at least for\npulling single branch): you either fast-forward (be updated), or be\nasked to perform a merge. Instead of anonymous heads you get\nautomatically named remote-tracking branches.\n\nWith respect to \"push\" direction Git assumes that you don't have shell\naccess to remote repository, so there is nobody to perform a merge;\nhence assymetry between \"git pull\" and \"git push\".\n\nBTW. can you get in Mercurial which anonymous head comes from which\nrepository?\n\n> There's also a possibility of nonterminating merges. That is, if my\n> team is making changes faster than you can merge them, then you'll\n> never get to push your changes. With dual heads, you still can. And\n> then anyone who wants to can merge them.\n\nWell, if you have that much activity, you better switch workflows away\nfrom \"central repository\" one, perhaps to maintainer + lieutenants\npull-based workflow.\n\nOr you can axplicitely push to side branch \n\n $ git push repo master:foo/master\n\nand ask in side channel to merge it.\n\n\nFor me using multi-tailed (multi-head) branches instead of\nremote-tracking branches serves to blur important distinction\n(assymetry) between pull and push directions.\n\n\nNow if I understand correctly what you wanted to have is a set of\nremote repositories, updated only by you (or at least updated in such\nway that fast-forward non-merge updates are more common than merges),\nand a way to fetch from those repositories so that branches gets\nupdated to most recent version from among the set of those\nrepositories, isn't it?\n\nThat's quite advanced workflow / requirement, isn't it?\n\n-- \nJakub Narebski\n"},{"id":"190782","messageId":"4FA42B7C.4010202@pileofstuff.org","threadId":"30372","inReplyTo":"CA+7g9Jxp859st6SrViizwOMrU9vsnmfy6P64SK9y_-ZEzEB6Mw@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Andrew Sayers","fromEmail":"andrew-20120504@pileofstuff.org","sentAt":"2012-05-04T19:18:20Z","receivedAt":"2012-05-04T19:18:20Z","isPatch":false,"sender":{"key":"andrew-20120504@pileofstuff.org","avatar":null},"body":"On 04/05/12 04:13, Nathan Gray wrote:\n> I just led a team of reasonably bright people through a transition\n> from SVN to git. Not one of them understood this message. Every one\n> of them thought something was broken. This is a very common\n> occurrence, so a short, simple message without jargon for this error\n> would be a big, big win.\n\nNow you come to mention it, I had the same experience a while back.\n\nThe message could certainly do with improvement, but I think this\nparticular case is more a side-effect of the push.default issue\ncurrently being worked through. Beginners expect `git push` to push a\nsingle branch, so they see \"error\" and assume the single branch they\npushed must have failed.\n\n\t- Andrew\n"},{"id":"190784","messageId":"CAMOZ1BtoEPJfBRobLv6Vq9ACec718HX3qxm60cuWJ_oSguFw=Q@mail.gmail.com","threadId":"30372","inReplyTo":"4FA418A7.2050100@palm.com","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2012-05-04T19:22:27Z","receivedAt":"2012-05-04T19:22:27Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, May 4, 2012 at 5:57 PM, Rich Pixley wrote:\n> On 5/3/12 21:35 , Michael Witten wrote:\n>>\n>> On Thu, 3 May 2012 20:13:01 -0700, Nathan Gray wrote:\n>>\n>>> On Thu, May 3, 2012 at 6:01 PM, Illia Bobyr  wrote:\n>>>>\n>>>> It is just a \"non-fast forward\" move of a branch tip.  This term\n>>>> describes what happens precisely :)\n>>>>\n>>>> It is true, that the term is non obvious to the new comers.\n>>>> One may google and get an explanation of the error pretty quickly.\n>>>> First hit for \"git non fast forward error\" gives an explanation from a\n>>>> new comer point of view for the simplest case.\n>>>\n>>> I just led a team of reasonably bright people through a transition\n>>> from SVN to git.  Not one of them understood this message.  Every one\n>>> of them thought something was broken.  This is a very common\n>>> occurrence, so a short, simple message without jargon for this error\n>>> would be a big, big win.\n>>\n>> Well, what is your suggestion?\n>>\n>> Nobody in this thread has yet provided an explicit improvement because\n>> the actual complaint is that the vast majority of people (including\n>> supposed \"professionals\") don't RTFM; it never even occurs to them!\n>>\n>> Let's look at the message in question:\n>>\n>>   To $uri_for_central_repo\n>>    ! [rejected]        HEAD ->  feature_0 (non-fast-forward)\n>>   error: failed to push some refs to '$uri_for_central_repo'\n>>   To prevent you from losing history, non-fast-forward updates were\n>> rejected\n>>   Merge the remote changes (e.g. 'git pull') before pushing again.  See\n>> the\n>>   'Note about fast-forwards' section of 'git push --help' for details.\n>>\n>> Not only does this already spoonfeed the reader with a suggested\n>> command for getting back on track (i.e., 'git pull'), but it also\n>> explicitly points out the relevant documentation and HOW to gain\n>> immediate access to that information from the command line!\n>\n> Let's take it line by line.\n>\n> \"Rejected - mumble\" - the tool did not do what you asked.\n> \"error: failed to mumble\"  - your data is corrupt.\n> \"To prevent you mumble mumble\" - you're not allowed to do what you want\n>\n> I stopped reading there.\n\nYou are not somebody worth helping.\n\n> I'm not saying this is a correct interpretation.  I'm offering it as a data\n> point from a sophisticated, although new, user.\n\nLOL\n"},{"id":"190785","messageId":"CAMP44s1a1=quz1Zs_VXnUfBt6n045u=BkV1+mE6Hyh3UJ=bfBg@mail.gmail.com","threadId":"30372","inReplyTo":"4FA30A68.5010002@palm.com","subject":"Re: Newbie grief","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-04T19:23:50Z","receivedAt":"2012-05-04T19:23:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, May 4, 2012 at 12:44 AM, Rich Pixley wrote:\n\n> Git clearly doesn't have much of that value in the community culture.\n\nAnd you are clearly delusional.\n\nYou don't like git, we get it, can you stop listing the ways git sucks\non every paragraph you write? Thanks.\n\nAnd here's a lesson about reality; reality doesn't care what you\nthink. When you say git is X, Y, and Z, that doesn't mean it's true;\nthat's what you *think*; but what you need to understand is that what\nyou *think* might be totally wrong.\n\nThese are called value judgments, and you should stop assuming your\nvalue judgments are truths, it would make it less annoying for people\nto discuss with you (specially on a mailing list about the thing you\nare constantly bashing), and it would help you save face when it turns\nout you are totally wrong.\n\ntl;dr: value judgments != truths\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"190787","messageId":"CAMP44s2yv6rfAfFUmGRS5b8=KwFpZ5yLxgL01V9W514PaLUJ9A@mail.gmail.com","threadId":"30372","inReplyTo":"CAMOZ1BuiznhrzEOHe0N+uu=mLEw5wWTQyDpnwG8PuF1f_aNaXw@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-04T19:30:38Z","receivedAt":"2012-05-04T19:30:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 2, 2012 at 12:56 AM, Michael Witten wrote:\n> On Tue, May 1, 2012 at 9:57 PM, Rich Pixley wrote:\n>\n>> In contrast, I was up and using mercurial in about a day and a half,\n>> including all of the stuff we've discussed, and all of the things I've even\n>> read about in git.  Learning mq's only took about 20 minutes.\n>\n> Fortunately, git is based on extremely simple principles.\n> Unfortunately, git grew out of really bright people hacking stuff\n> together in order to get sh!t dun; the result is not approachably or\n> even well documented, the UI is sometimes a bit of a kludge, the API\n> is probably nonexistent, and the terminology is so loosely thrown\n> about that it's easy to forget which way is up in discussions.\n> (Note, though, that Junio has done a laudable job of keeping the\n> whole experiment going strong).\n\nYou are a prime example of this experiment called 'life', also based\non extremely simple principles, mostly through trial and error. Design\nis overrated :)\n\n-- \nFelipe Contreras\n"},{"id":"190789","messageId":"CAMOZ1BvmBP2pfc_TxsyLBRtWGo5=vfiPu9N_cxLkj2x8oWEJ1w@mail.gmail.com","threadId":"30372","inReplyTo":"CAMP44s2yv6rfAfFUmGRS5b8=KwFpZ5yLxgL01V9W514PaLUJ9A@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2012-05-04T19:41:09Z","receivedAt":"2012-05-04T19:41:09Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, May 4, 2012 at 7:30 PM, Felipe Contreras\n wrote:\n> On Wed, May 2, 2012 at 12:56 AM, Michael Witten wrote:\n>> On Tue, May 1, 2012 at 9:57 PM, Rich Pixley wrote:\n>>\n>>> In contrast, I was up and using mercurial in about a day and a half,\n>>> including all of the stuff we've discussed, and all of the things I've even\n>>> read about in git.  Learning mq's only took about 20 minutes.\n>>\n>> Fortunately, git is based on extremely simple principles.\n>> Unfortunately, git grew out of really bright people hacking stuff\n>> together in order to get sh!t dun; the result is not approachably or\n>> even well documented, the UI is sometimes a bit of a kludge, the API\n>> is probably nonexistent, and the terminology is so loosely thrown\n>> about that it's easy to forget which way is up in discussions.\n>> (Note, though, that Junio has done a laudable job of keeping the\n>> whole experiment going strong).\n>\n> You are a prime example of this experiment called 'life', also based\n> on extremely simple principles, mostly through trial and error. Design\n> is overrated :)\n\nThere is no process other than trial and error, or more precisely,\nvariation and selection.\n\nNote, though, that the levels of sophistication involved with variation\nand selection differ among manifestations of this process.\n"},{"id":"190799","messageId":"20120504200051.GP14230@opensource.wolfsonmicro.com","threadId":"30372","inReplyTo":"4FA41E8E.20900@palm.com","subject":"Re: Newbie grief","fromName":"Mark Brown","fromEmail":"broonie@opensource.wolfsonmicro.com","sentAt":"2012-05-04T20:00:52Z","receivedAt":"2012-05-04T20:00:52Z","isPatch":false,"sender":{"key":"broonie@opensource.wolfsonmicro.com","avatar":"https://gravatar.com/avatar/5fb25e4e0de3255caa21123e2b518c314d26245069221ff55910d5c6ba3343c4?d=mp&s=160"},"body":"On Fri, May 04, 2012 at 11:23:10AM -0700, Rich Pixley wrote:\n\n> This is a different situation from either the one where I,\n> specifically me, must merge or the one where I intend my changes to\n> stay separated from other development, (a new \"branch\"). The\n> situation with multiple heads allows the merge, the branch, even the\n> decision about whether to merge or branch, to be delayed\n> indefinitely.\n\nSo, git does actually allow this quite happily - people can publish and\nmerge whatever they feel like. What seems to be missing (as far as I\ncan tell without having used hg) is the ability to associate random\nscratch branches from various places with each other and then do things\nwith that information. Like I said in another e-mail elsewhere in the\nthread this does make sense to me, though it's not a current workflow.\n\n> The fact that it allows for this also allows for a number of\n> different repository network architectures, all of which are blocked\n> in git because of the push problem. In git, those decisions must be\n> made _before_ the push.\n\nThey're only blocked if you don't want to create new branches; idiomatic\ngit is much more free and easy with that idea so a lot of the time what\npeople would say is that is to just create topic branches.\n\n> There's also a possibility of nonterminating merges. That is, if my\n> team is making changes faster than you can merge them, then you'll\n> never get to push your changes. With dual heads, you still can.\n> And then anyone who wants to can merge them.\n\nAgain, this only applies if everyone has to merge onto the same branch\nand do it regularly - in normal git workflows this doesn't really occur\nas the final merge branch requires some review/approval process and\nunmerged work branches are cheap to create and publish.\n"},{"id":"190800","messageId":"CAMP44s2w9B0Jvcn44R5_-ptC=x+5=OgGF0n0SkH+t0JjomXsGA@mail.gmail.com","threadId":"30372","inReplyTo":"4FA2D8EA.7030809@palm.com","subject":"Re: Newbie grief","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-04T20:03:18Z","receivedAt":"2012-05-04T20:03:18Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 3, 2012 at 9:13 PM, Rich Pixley wrote:\n\n> This is probably what I'm going to end up using.\n>\n> Just for comparison, here's a similar process in hg.\n>\n> Cache server:\n>\n>  $ hg clone $uri_for_central_repo\n\n% git clone $uri_for_central_repo\n\n> Machine A:\n>\n>  $ hg clone $uri_for_cache_repo\n\n% git clone $uri_for_cache_repo\n\n>  $ # ...do some work...\n>  $ hg push\n\n% git push\n\n> Machine B:\n>\n>  $ hg clone $uri_for_cache_repo\n\n% git clone $uri_for_cache_repo\n\n>  $ # ...do some work...\n>  $ hg push # assume this collides\n\n% git push\n\n>  pushing to $uri_for_cache_repo\n>  searching for changes\n>  abort: push creates new remote head 6d2eb0a6a278!\n>  (you should pull and merge or use push -f to force)\n>  $ hg push -f # the pull and merge case parallels git, so let's use push -f.\n\nThis is stupid, why make everybody else's life difficult? Let's merge here.\n\n% git pull\n% git push\n\n> Any repo:\n>\n>  $ hg pull # pulls in all changes including the dual heads\n\n% git pull\n\n>  $ hg merge # collapses the dual heads\n>  $ hg commit # commits the merge\n>  $ hg push\n\nNo need for this, the guy that diverged did this (Machine B).\n\nPlus, what happens if 3 other machines do this? You you have 3 merges,\n2 would conflict, and then you would have useless recursive merges, or\nsome people would have to revert. Why bother N people, when one guy\ncan do it at the origin (Machine B)?\n\n> Machine A:\n>\n>  $ hg pull # pulls in all changes so far\n>  $ hg up\n\n% git pull\n\n>  $ #... do some work ...\n>  $ hg push\n\n% git push\n\n> Machine B\n>\n>  $ hg pull\n>  $ hg up\n\n% git pull\n\n>  $ # ... do some work ...\n>  $ hg push\n\n% git push\n\n> Any repo:\n>\n>  $ hg pull $uri_to_central_repo\n>  $ hg merge\n\n% git pull $uri_to_central_repo\n\n>  $ hg push $uri_to_central_repo\n\n% git push $uri_to_central_repo\n\n>  $ hg push # default is cache repo\n\n% git push\n\n> Machine B:\n>\n>  $ hg pull\n\n% git pull\n\n> Some Conclusions:\n>\n> * the work flows are similar.\n>\n> * the hg commands are simpler and have the defaults that we want, primarily\n> because no extra branches are required.\n\nWrong.\n\n> * the hg error messages are straightforward, clear, and don't require any\n> deep knowledge of the source code control system or it's limitations.  (I\n> still don't understand what the git message on collision is saying.)\n\nWhatever. I don't care what the error message for a merge conflict\nactually says, all I need to know is that there was a conflict.\n\n> * hg has more options about how to handle the collisions or the merges.\n>  While git can mimic some of those options, doing so requires a priori\n> knowledge that isn't stored in the source code control system and therefor\n> requires a human exchange which is optional with hg.\n\nWTF? git handles collisions just fine.\n\nActually the git version has less commands. And if configured properly\nyou don't need to specify URLs.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"190802","messageId":"7v4nrvadzq.fsf@alter.siamese.dyndns.org","threadId":"30372","inReplyTo":"CAMP44s2w9B0Jvcn44R5_-ptC=x+5=OgGF0n0SkH+t0JjomXsGA@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-04T20:27:21Z","receivedAt":"2012-05-04T20:27:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Thu, May 3, 2012 at 9:13 PM, Rich Pixley wrote:\n> ...\n>> $ # ...do some work...\n>> $ hg push # assume this collides\n>\n> % git push\n>\n>> pushing to $uri_for_cache_repo\n>> searching for changes\n>> abort: push creates new remote head 6d2eb0a6a278!\n>> (you should pull and merge or use push -f to force)\n>> $ hg push -f # the pull and merge case parallels git, so let's use push -f.\n>\n> This is stupid, why make everybody else's life difficult? Let's merge here.\n\nDoing \"hg push -f\" _regularly_ is probably stupid, but you need to step\nback a bit. There is a valid situation where you may sometimes want to\npublish unmerged work for others to see.\n\nThe person who is trying to push here may be quite junior, and may not be\nyet familiar with the areas of the project outside what he has worked on.\nIn his attempt to \"pull and then push\", he can end up having to resolve a\nmerge conflict that he is not capable of handling correctly. Regardless of\nthe VCS used, you would want to give a way to this junior developer to ask\nfor help \"here is my work; while I was working on it, the baseline has\nbeen diverged greatly and I need help either merging it or rebasing it.\"\n\nIn that context, I can see that Hg's split head could be _one_ way to\nimplement it. You just push and force split the head at the remote,\nleaving others to sort out the resulting mess.\n\nBut that is not necessarily the _only_ way to implement it. A Git user\nwould probably push his work to either his own public repository, or in an\nenvironment like Rich illustrated, to refs/remotes/junior/need_help_xyzzy\nof the central repository of the organization, and ask other people to\nhelp him. And when he does so, he needs to tell them where they can find\nhis work, either the url to his own repository (and its branch), or his\nbranch at the shared place, and that is where the naming of branch becomes\nmeaningful. Instead of saying \"There is 6d2eb0a6a278 in the repo that I\nneed somebody to help merging\", the request-for-help message can say \"I\nplaced my WIP on junior/need_help_xyzzy branch; please take a look and\nhelp merging it.\"\n\nSuch a \"push -f\" to split heads (or pushing to need_help branch and ask\nothers to do the \"pull/push\" for him) shouldn't be a norm, and if a\nproject _relies_ on the ability to do so, there probably is a deeper\nproblem with the project (e.g. perhaps the codebase is not modularized\nenough to allow isolated parallel development by junior people on narrow\nsubparts of it).\n"},{"id":"190803","messageId":"CAMP44s0DwRZT2yEWVh89LeVPU1seu+SJwEdt-jy=4gssCedegg@mail.gmail.com","threadId":"30372","inReplyTo":"7v4nrvadzq.fsf@alter.siamese.dyndns.org","subject":"Re: Newbie grief","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-04T20:45:12Z","receivedAt":"2012-05-04T20:45:12Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, May 4, 2012 at 10:27 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> On Thu, May 3, 2012 at 9:13 PM, Rich Pixley wrote:\n>> ...\n>>>  $ # ...do some work...\n>>>  $ hg push # assume this collides\n>>\n>> % git push\n>>\n>>>  pushing to $uri_for_cache_repo\n>>>  searching for changes\n>>>  abort: push creates new remote head 6d2eb0a6a278!\n>>>  (you should pull and merge or use push -f to force)\n>>>  $ hg push -f # the pull and merge case parallels git, so let's use push -f.\n>>\n>> This is stupid, why make everybody else's life difficult? Let's merge here.\n>\n> Doing \"hg push -f\" _regularly_ is probably stupid, but you need to step\n> back a bit.  There is a valid situation where you may sometimes want to\n> publish unmerged work for others to see.\n>\n> The person who is trying to push here may be quite junior, and may not be\n> yet familiar with the areas of the project outside what he has worked on.\n> In his attempt to \"pull and then push\", he can end up having to resolve a\n> merge conflict that he is not capable of handling correctly. Regardless of\n> the VCS used, you would want to give a way to this junior developer to ask\n> for help \"here is my work; while I was working on it, the baseline has\n> been diverged greatly and I need help either merging it or rebasing it.\"\n\nSure, but is 'push -f' the right solution? If a junior really has no\nidea about what he is doing, I wouldn't want him pushing another\n'head' to the master branch. Can mercurial really do a rebase only on\na specific head of a branch? Even if mercurial can do that, the result\ncan be quite messy; one guy doing a rebase, another guy doing a merge,\nanother guy doing a different merge, another a different rebase; if\nthey know what they are doing, they will avoid 'push -f' and revert or\nrebase their changes when they notice somebody else tried to do\nsomething similar, but maybe one of them is a slightly more advanced\njunior and actually does 'push -f', and we go into yet another round\nof conflict resolving.\n\nIt doesn't matter how you look at it; 'push -f' is not ideal.\n\nIn the git world there's many ways to resolve this; push to another\nbranch, push to another repo, allow ssh access to your machine, send\nthe changes by mail, copy the git repo to a shared location, etc.\n*All* of those alternatives are better than 'push -f'.\n\nIt seems to me that this *huge* thread basically boils down to Rich\nwanting 'hg push -f', when clearly that just creates problems, even in\nmercurial.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"190804","messageId":"4FA44A38.1070704@palm.com","threadId":"30372","inReplyTo":"CAMP44s0DwRZT2yEWVh89LeVPU1seu+SJwEdt-jy=4gssCedegg@mail.gmail.com","subject":"Re: Newbie grief","fromName":"Rich Pixley","fromEmail":"rich.pixley@palm.com","sentAt":"2012-05-04T21:29:28Z","receivedAt":"2012-05-04T21:29:28Z","isPatch":false,"sender":{"key":"rich.pixley@palm.com","avatar":null},"body":"On 5/4/12 1:45 PM, Felipe Contreras wrote:\n> It doesn't matter how you look at it; 'push -f' is not ideal.\n\nPush -f offers an alternative that is available in other source code \ncontrol systems, (not just mercurial), but not in git. It's a bit of a \nculture shock to discover that it's not available in git.\n\n> In the git world there's many ways to resolve this; push to another\n> branch, push to another repo, allow ssh access to your machine, send\n> the changes by mail, copy the git repo to a shared location, etc.\n> *All* of those alternatives are better than 'push -f'.\n\nIn your opinion, and that's fine. I don't need to argue this point any \nlonger. All of those other solutions are also available in the other \nsource code control systems too.\n\n> It seems to me that this *huge* thread basically boils down to Rich\n> wanting 'hg push -f', when clearly that just creates problems, even in\n> mercurial.\n\nActually, I wanted a work flow that was functional for me and supported \na shared branch between multiple repositories. I think I have a process \nfor that now. The key things I've learned so far are:\n\n* Git can't cope with repository collisions, (in essence, because it's \nnot willing to ever create multiple heads, but also because it doesn't \ntrack the entire pedigree of a branch, and because destructive rewrites \non the repository are common in typical git usage).\n\nThe usual way to deal with this in the git world is to use geographical \nbranches and triangles everywhere, but using \"merge before push\" can \nprovide a way to use shared branches within git, (provided you can live \nwithin a fair number of restrictions, which I probably can.)\n\n* That that cryptic message means that git would need to cope with a \nrepository collision, which it can't do. It doesn't actually mean that \nthe repository is corrupt, which is what I took it to mean.\n\nFrankly, if the cryptic message had been clearer, I probably would never \nhave posted here. I'd likely have figured out that git had this \nrestriction and found a way to work around it on my own.\n\n--rich\n"},{"id":"190805","messageId":"CAMP44s0x5gomoYtF1-qdyGB2f1LnT_LYHhu8D4f-O-sSocK=gQ@mail.gmail.com","threadId":"30372","inReplyTo":"4FA44A38.1070704@palm.com","subject":"Re: Newbie grief","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-04T22:05:19Z","receivedAt":"2012-05-04T22:05:19Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, May 4, 2012 at 11:29 PM, Rich Pixley wrote:\n> On 5/4/12 1:45 PM, Felipe Contreras wrote:\n>>\n>> It doesn't matter how you look at it; 'push -f' is not ideal.\n>\n>\n> Push -f offers an alternative\n\nA crappy alternative.\n\n> that is available in other source code control systems, (not just mercurial),\n\nWhich other systems? monotone? That doesn't say much.\n\n> but not in git.  It's a bit of a culture\n> shock to discover that it's not available in git.\n\nIf you don't find a crappy problematic feature in git that you rely\non--that's your problem.\n\n>> In the git world there's many ways to resolve this; push to another\n>> branch, push to another repo, allow ssh access to your machine, send\n>> the changes by mail, copy the git repo to a shared location, etc.\n>> *All* of those alternatives are better than 'push -f'.\n>\n> In your opinion, and that's fine.  I don't need to argue this point any\n> longer.  All of those other solutions are also available in the other source\n> code control systems too.\n\nAnd they are preferred, even the mercurial documentation says you\nshould avoid 'push -f'.\n\nIt seems you are the only one that thinks 'push -f' is ideal.\n\n>> It seems to me that this *huge* thread basically boils down to Rich\n>> wanting 'hg push -f', when clearly that just creates problems, even in\n>> mercurial.\n>\n>\n> Actually, I wanted a work flow that was functional for me and supported a\n> shared branch between multiple repositories.  I think I have a process for\n> that now.  The key things I've learned so far are:\n>\n> * Git can't cope with repository collisions, (in essence, because it's not\n> willing to ever create multiple heads, but also because it doesn't track the\n> entire pedigree of a branch, and because destructive rewrites on the\n> repository are common in typical git usage).\n\nWrong. Git copes with collisions just fine; you don't need multiple\nheads, multiple heads are bad, even in mercurial, even mercurial\ndocumentation says so. You merge before you push; easy.\n\n> The usual way to deal with this in the git world is to use geographical\n> branches and triangles everywhere,\n\nAgain wrong. The usual way is to have feature branches:\n\n% git checkout -b rich-reorganize-foo\n% git push origin rich-reorganize-foo\n\n> but using \"mege before push\" can provide\n> a way to use shared branches within git, (provided you can live within a\n> fair number of restrictions, which I probably can.)\n\nThat's the preferred way in mercurial too; it's the sane way to do it.\n\n> * That that cryptic message means that git would need to cope with a\n> repository collision, which it can't do.  It doesn't actually mean that the\n> repository is corrupt, which is what I took it to mean.\n>\n> Frankly, if the cryptic message had been clearer, I probably would never\n> have posted here.  I'd likely have figured out that git had this restriction\n> and found a way to work around it on my own.\n\nStop thinking your opinion is truth, and stop playing with words.\nMercurial has the \"restriction\" that you can't push to a repository\nwhere you don't have permissions; that might be a restriction to\nsomebody, but using the word restriction to describe that situation\nwould be a cheap rhetorical device to be abrasiveness against\nmercurial.\n\nIn mercurial and in git you should merge before you pull, if you don't\nlike to be forced to do the sane thing; go use mercurial and be happy\nwith the pain you create to yourself.\n\nAnd BTW, this is the clear message from mercurial:\nabort: push creates new remote head 6d2eb0a6a278!\n\nNot cryptic at all!\n\nPersonally I don't care, I know a collision when I see it. If you want\nto help improve the error message, feel free to participate in the\nother thread that is meant for that. As for the workflow it's clear\nthat the git workflow is a bit simpler than mercurial one, you just\nwant to make your life difficult with 'hg push -f', and if you want to\nshoot yourself in the foot, you have mercurial for that (even though\nit's not recommended there either).\n\n-- \nFelipe Contreras\n"}]}