{"thread":{"id":"12008","subject":"Re: Upcoming memcached releases + rambling.","startedAt":"2008-02-10T11:05:04Z","lastAt":"2008-02-10T15:39:49Z","messageCount":4,"participants":["Jeff King","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68194","messageId":"20080210110504.GA27314@coredump.intra.peff.net","threadId":"12008","inReplyTo":"5222C3B4-5E2C-45D2-8DF3-A85D69DDA2CF@spy.net","subject":"Re: Upcoming memcached releases + rambling.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-10T11:05:04Z","receivedAt":"2008-02-10T11:05:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[I'm not on the list, so please cc me in replies]\n\nOn Fri, Feb 08, 2008 at 09:21:16PM -0800, Dustin Sallings wrote:\n\n> I've seen lots of people using git for their own work, but not enough\n> using it in a distributed fashion. I've been asking questions about how\n> to collaborate with git, but I can't seem to find any git experts who will\n> answer questions.\n\nPlease, if you have git questions, feel free to ask them on the git list\n(which I am cc'ing here).\n\n> serve, bundle, export, import, incoming, and outgoing don't seem\n> to have equivalences in git.\n\nI don't know hg well at all, but I will attempt to translate (please\ncorrect me if I'm wrong on any hg behavior).\n\n\"hg serve\" runs a web repo browser and a pull server. In git, these\nduties are split. Depending on what you want, you can:\n - for allowing people to pull from you, you can use git-daemon\n - for repository browsing, run an instance of gitweb. There is a\n git-instaweb script for doing one-off \"I just need to set this up\n for a minute\" versions.\n - you can also allow people to pull via http; just copy your '.git'\n directory somewhere that is accessible by the web server\n - you can also allow people to pull via ssh; just give them an ssh\n account and point them to host:/path/to/repo\n\n\"hg bundle\" has an equivalent in git: \"git bundle\"\n\n\"hg export\" seems to generate the commit message + patch for a set of\ncommits. The git equivalent is \"git format-patch\" which puts each patch\nin its own mbox file (you can also use \"git format-patch --stdout >mbox\"\nto put them all in one mbox.\n\n\"hg import\" presumably applies the results of \"hg export\". In git, this\nis \"git am\" (where am stands for apply mailbox), which applies the\nchanges from an entire mbox one by one.\n\n\"incoming\" and \"outgoing\" seem to basically be diffs against remote\nrepositories (i.e., \"what do I have that he doesn't\" and vice versa). In\ngit, you would do a \"git fetch\" to say \"contact the remote repository\nand get what he has, but don't update any of my branches\" followed by\n\"git log origin..HEAD\" (what does I have that he doesn't) or \"git log\nHEAD..origin\" (the opposite). You can also use the symmetric difference\nwith a graphical browser like gitk: \"gitk origin...HEAD\" which will show\neverything that he has and everything you have, down to the point where\nthe two histories last diverged.\n\n> \tI've contributed changes to both git and hg projects and haven't had \n> good luck submitting changes upstream. I'd be interesting in talking to \n> people who collaborate on projects using git both as first and \n> second-level contributors to see if their experiences are any better than \n> mine. I don't doubt that I may be doing it wrong.\n\nAgain, if you have specific questions, please feel free to ask on the\ngit list. We are more than happy to help out if we can.\n\n> \tShould memcached choose git, it may be as simple as putting up a page \n> that says, ``this is how you clone, this is how you work, this is how you \n> submit your changes back.''\n\nI don't know hg very well, but my impression is that the implementation\nis quite similar to git and that writing a document \"translating\"\ncommands from one system to the other would be feasible.\n\n-Peff\n"},{"id":"68195","messageId":"20080210111557.GA27348@coredump.intra.peff.net","threadId":"12008","inReplyTo":"47AD643D.3040800@rydia.net","subject":"Re: Upcoming memcached releases + rambling.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-10T11:15:57Z","receivedAt":"2008-02-10T11:15:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 09, 2008 at 12:28:45AM -0800, dormando wrote:\n\n> If I _think_ I understand these right, you can actually sometimes git\n> diff with the second repo as an argument. That'll show the differences\n> since the target repo/branch (git diff . /path/to/other/repo#branch),\n> which will be incoming or outgoing.\n\nNo, that doesn't work. It will literally diff the two directories.\n\nWhat you have probably seen is:\n\n git diff origin HEAD\n\nwhich means \"diff my current branch with the branch origin\". Now\n\"origin\" is typically the name of your upstream remote. However, we also\nuse the same name to store \"tracking branches\" that keep tabs on the\nremote's state. So the branch \"origin\" stores the state of the remote's\ncurrent branch (as of the last time you did a \"git fetch\" of course).\n\nBut \"git diff HEAD \" does not work. You would want \"git fetch\n && git diff HEAD FETCH_HEAD\".\n\n> That'll show the raw changes... for showing the difference in changeset,\n> you can do a: git log --since HEAD origin\n> ... if origin were the remote repo. If you don't have the latest\n> changes, fetch more, rebase your repo on top of that, then git log\n> --since will show you what you have to upload.\n\nThat --since is not necessary. You want \"git log HEAD..origin\" (where\n\"A..B\" means \"what's in B, but not in A\"). \"--since\" is for\ndate-limiting, and the syntax is like \"--since=2.weeks.ago\".\n\n> I think my knowledge on how to do this in git is a bit dated, so I'll go\n> read (I started with git in 0.99 series, where it was missing most of\n> these fancy \"usability features\", so sometimes I do things the hard way\n> still).\n\nPre-1.5 and 1.5 have quite a few interface differences (and of course\nthere were many changes from 0.99 to 1.5 :) ).\n\n> Otherwise you can use git fetch to \"pull\" the remote changes into a\n> branch but not apply anywhere, then use git log with relative commit ids\n> to show the changesets (with -p to show the full changes!)\n\nYes, although I would say that git fetch \"fetches\" changes, so as not to\nconfuse it with the \"pull\" command which does something different.\n\n> Unless I'm getting my wires crossed and this is a patch management\n> thinger, in that case it's 'git format-patch' and 'git am' (although\n> there's an alternative to am).\n\nActually \"am\" is the new alternative to \"applymbox\" which is now\nofficially gone in 1.5.4.\n\n-Peff\n"},{"id":"68216","messageId":"m31w7khmhq.fsf@localhost.localdomain","threadId":"12008","inReplyTo":"20080210110504.GA27314@coredump.intra.peff.net","subject":"Re: Upcoming memcached releases + rambling.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-10T15:14:58Z","receivedAt":"2008-02-10T15:14:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King writes:\n\n> [I'm not on the list, so please cc me in replies]\n> \n> On Fri, Feb 08, 2008 at 09:21:16PM -0800, Dustin Sallings wrote:\n> \n> > I've seen lots of people using git for their own work, but not enough\n> > using it in a distributed fashion. I've been asking questions about how\n> > to collaborate with git, but I can't seem to find any git experts who will\n> > answer questions.\n> \n> Please, if you have git questions, feel free to ask them on the git list\n> (which I am cc'ing here).\n\nDid they at least asked (tried to ask) on #git channel on FreeNode?\n \n> > serve, bundle, export, import, incoming, and outgoing don't seem\n> > to have equivalences in git.\n> \n> I don't know hg well at all, but I will attempt to translate (please\n> correct me if I'm wrong on any hg behavior).\n\nI have tried to follow hg(1), from\n http://www.selenic.com/mercurial/hg.1.html\n\n> \"hg serve\" runs a web repo browser and a pull server. In git, these\n> duties are split. Depending on what you want, you can:\n> - for allowing people to pull from you, you can use git-daemon\n> - for repository browsing, run an instance of gitweb. There is a\n> git-instaweb script for doing one-off \"I just need to set this up\n> for a minute\" versions.\n\nOr you can use one of the history viewers: gitk (Tcl/Tk), qgit (Qt),\nGiggle or GitView (GTK+), or tig (ncurses).\n\n> - you can also allow people to pull via http; just copy your '.git'\n> directory somewhere that is accessible by the web server\n\nNote that you have to run git-update-server-info to update auxiliary\ninfo file to help dumb servers (which includes HTTP server),\npreferably in 'update' (for publishing repos) or 'post-commit' (for\nworking repos) hook.\n\n> - you can also allow people to pull via ssh; just give them an ssh\n> account and point them to host:/path/to/repo\n\nYou can use git-shell as shell to lomit access to only pulling /\npushing changes.\n\nIMHO it is better to leave serving web pages to web server, instead of\ntrying to do that in an SCM... even if Python has support for creating\nbasic HTTP server easily. (We could add bare-bones gitweb and git\nonly, written in Perl HTTP server in gitweb/, but what for...).\n\n\n> \"hg bundle\" has an equivalent in git: \"git bundle\"\n\nMinor difference: it is \"git bundle create\" and \"git bundle unbundle\"\n(or \"git pull \") versus \"hg bundle\" and \"hg unbundle\".\n\n> \"hg export\" seems to generate the commit message + patch for a set of\n> commits. The git equivalent is \"git format-patch\" which puts each patch\n> in its own mbox file (you can also use \"git format-patch --stdout >mbox\"\n> to put them all in one mbox.\n\nIt looks like there is no exact equivalent. \"git format-patch\" is used\nto generate series of patches, but it doesn't for example saves\nparent(s) of a commit; not that it makes much sense. It is meant to\nsend patches for review (and then applying).\n\nBy the way, for binary files git would send binary diff, which can be\napplied _only_ if you have exact preimage, so this is no problem:\n\nhg export:\n\n Without the -a option, export will avoid generating diffs of files\n it detects as binary. With -a, export will generate a diff anyway,\n probably with undesirable results.\n\n> \"hg import\" presumably applies the results of \"hg export\". In git, this\n> is \"git am\" (where am stands for apply mailbox), which applies the\n> changes from an entire mbox one by one.\n\nNote that \"git format-patch\" / \"git am\" is meant for mail driven\nworkflow, with patches send for _review_ to maintainer or [public]\nmailing list, and applied by maintainer on case by case basis. This\nmeans for example that commit from patch might be applied in different\nplace of revision graph than original; \"git am --3way\" fallbacks on\n3-way merge (based on embedded original pre-image blob (file)\nidentifier) if patch cannot be applied cleanly.\n\nIt is not meant as a transport mechanism: use interactive protocols\n(ssh, git, http) for that, or git-bundle if it is impossible.\n\n> \"incoming\" and \"outgoing\" seem to basically be diffs against remote\n> repositories (i.e., \"what do I have that he doesn't\" and vice versa). In\n> git, you would do a \"git fetch\" to say \"contact the remote repository\n> and get what he has, but don't update any of my branches\" followed by\n> \"git log origin..HEAD\" (what does I have that he doesn't) or \"git log\n> HEAD..origin\" (the opposite). You can also use the symmetric difference\n> with a graphical browser like gitk: \"gitk origin...HEAD\" which will show\n> everything that he has and everything you have, down to the point where\n> the two histories last diverged.\n\nHere (and in neighbour post about diff between branches) we come to\nthe main difference between Git and Mercurial, namely that Git uses\nmultiple-branches in repository workflow extensively[*1*], while in\nMercurial multiple branches in single repository are still (from what\nI have read) secondary citizens; main workflow is still one branch per\nrepository.\n\n(I'm not sure if Mercurial gets correctly the difference between tags\nand branches, but that is just me spreading FUD ;-)).\n\nGit uses concept of remote tracking branches to track changes in\nremote repository. By default after cloning repository which has for\nexample branches 'master' (stable branch) and 'next' (development\nbranch) you have local branch 'master' (fullname: refs/heads/master)\nfor your own work, and 'origin/master' and 'origin/next' (where\n'origin' is default name for origin-al repository you by default fetch\nfrom) remote tracking branches (fullname: refs/remotes/origin/master,\nrefs/remotes/origin/next). You have also symbolic ref 'HEAD' which\ndenotes current branch; points which branch you are currently work\nwith, and ref 'origin' (fullname: refs/remotes/origin/HEAD) denoting\ndefault branch on remote repository.\n\nIn Git \"pull\" consists of two steps: 'fetch' which downloads objects\n(changes) and updates refs, and 'merge' which joins the histories (or\ndoes fast-forward) and updates current branch. From what I understand\nfrom Mercurial documentation hg it has those actions split in a\ndifferent way: \"hg incoming\" to examine changes, and \"hg pull;\nhg update\" to join histories.\n\nSo to examine some defined repository one would do a \"git fetch \", \nwhere is shortcut repository name, and then examine\n/ remote tracking branches. Note that it looks like\n\"hg incoming\" can deal sensibly only with one branch per repository\nrepositories (further FUD spreading ;-)). If you want to preview some\nforeign repo you can use \"git fetch \" or \"git fetch \n\" and examine FETCH_HEAD.\n\nNote that the fact that some branch in remote repository and\nrespective remote-tracking branch differ might mean many things:\n a.) remote repository has avanced wrt. our repository\n b.) remote repository lags behind our repository\n (e.g. both are sister repositories cloned from the same repo)\n c.) histories diverged, or were rewound / rewritten\nI wonder how Mercurial deals with cases b.) and c.) (further anti-hg\nFUD ;-))\n\nNow to examine what changed you can use _generic_ revision list\nspecification in some history browser (git-log, gitk, git-show-branch,\netc.). Here you can use \"A..B\" syntax (what's in B, excluding what is\nin A, which in the case of linear history is: what is between A and\nB), and \"A...B\" syntax (what's in A and B, excluding what's in common\nancestor (merge base) of both of them). A and/or B can be: HEAD\n(current branch), 'origin' or for default remote repository\nbranch, FETCH_HEAD for what was just fetched, or even\norigin@{1}..origin to show what fetch brought to 'origin/HEAD'.\n\nIf Git ever would want to have a command which would show which\nbranches differ in some remote repository, I think it would be added\nto \"git remote\" (which I recommend checking).\n\n> > \tI've contributed changes to both git and hg projects and haven't had \n> > good luck submitting changes upstream. I'd be interesting in talking to \n> > people who collaborate on projects using git both as first and \n> > second-level contributors to see if their experiences are any better than \n> > mine. I don't doubt that I may be doing it wrong.\n> \n> Again, if you have specific questions, please feel free to ask on the\n> git list. We are more than happy to help out if we can.\n\nWell, there are around 250 contributors to git which have more than\none commit to his/her name. Even excluding some fuzz factor due to\nwrong / changed credentials.\n\nMasukomi (Kate Rhodes) wrote in her blog in \"Some thoughts about Git\"\nhttp://weblog.masukomi.org/2008/2/4/some-thoughts-about-git\n\n And then I joined the Git mailing list. Linus mentioned that it had\n a high signal to noise ratio but... *holy shit*. I have been on a\n lot of mailing lists for open source projects over the years and I\n have never seen anything like this. Almost every e-mail is a patch,\n or a good discussion of a patch, or a good discussion of some new\n feature and how to go about implementing it.\n\n> > \tShould memcached choose git, it may be as simple as putting up a page \n> > that says, ``this is how you clone, this is how you work, this is how you \n> > submit your changes back.''\n> \n> I don't know hg very well, but my impression is that the implementation\n> is quite similar to git and that writing a document \"translating\"\n> commands from one system to the other would be feasible.\n\nActualy while ideas and workflows might be similar, implementation\ndiffers quite a bit.\n\nGit is snapshot based[*2*]; in git repository is object database, with\ncommits being points in DAG (Directed Acyclic Graph) of revisions,\npointing to their parent commits and to snapshot of a repository state\nat given revision. Branches, remote tracking branches and tags are\n[named] pointers to points (staring points) in DAG of revisions. There\nHEAD which is pointer to pointer, or simply something which names\ncurrent branch (symbolic reference to current branch name). File\nstructure is reflected in object database using hierchical tree object\nstructure; file name and parts of permissions are stored in tree\nobjects. This structure allows for fast merges (and fast warm-cache\nperformance, supposedly).\n\nMercurial I know only secondhand, from the discussion on #revctrl IRC\nchannel, and from Mercurial documentation. It is AFAICT\nchangeset-based, with changesets stored \"hashed\" in per [current]\nfilename buckeds, tied together in flat manifest like file which ties\nfiles together, tied together in revlog changeset-log file which\nstores commits. Branches and tags are stored as in-tree file (inside\nworking directory of repository), similarly to .gitignore / .hgignore\nfile, with (for tags at least) some complicated rule of updating it\nwhen switching branches and going to given revision (further anti-hg\nFUD; I hope that changed...). The pref-file-bucket structure allows\nfor fast patch applying (and fast cold-cache performance, supposedly).\n\n\nFootnotes:\n==========\n[*1*] Junio C Hamano (current git maintainer), wrote in his blog\nin \"FLOSS weekly #19 follow-up (3)\" entry:\n http://gitster.livejournal.com/9970.html \n\n \"The very basic structure and idea behind git has not changed since\n Linus wrote the initial implementation\".\n\n Well, while that is not _untrue_, that statement itself may lead to\n confusion unless clarified.\n\n [...]\n\n * We did not envision that multiple branches in a single repository\n would turn out to be such a useful way to work, and did not have\n support for switching branches;\n\n\n[*2*] Even if in packed form it is stored as delta chains; but that is\n just [transparent] engine.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"68217","messageId":"fon5s6$kff$1@ger.gmane.org","threadId":"12008","inReplyTo":"m31w7khmhq.fsf@localhost.localdomain","subject":"Re: Upcoming memcached releases + rambling.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-10T15:39:49Z","receivedAt":"2008-02-10T15:39:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[I hate subscribe-only default-DROP mailing lists for a OSS project,\n where you don't get even: waiting for moderator approval for not\n subscribed. I'm trying to resend it via GMane. I'm not subscribed\n to memcached mailing list]\n\nJeff King writes:\n\n> [I'm not on the list, so please cc me in replies]\n> \n> On Fri, Feb 08, 2008 at 09:21:16PM -0800, Dustin Sallings wrote:\n> \n> > I've seen lots of people using git for their own work, but not enough\n> > using it in a distributed fashion. I've been asking questions about how\n> > to collaborate with git, but I can't seem to find any git experts who will\n> > answer questions.\n> \n> Please, if you have git questions, feel free to ask them on the git list\n> (which I am cc'ing here).\n\nDid they at least asked (tried to ask) on #git channel on FreeNode?\n \n> > serve, bundle, export, import, incoming, and outgoing don't seem\n> > to have equivalences in git.\n\n> I don't know hg well at all, but I will attempt to translate (please\n> correct me if I'm wrong on any hg behavior).\n\nI have tried to follow hg(1), from\n http://www.selenic.com/mercurial/hg.1.html\n\n> \"hg serve\" runs a web repo browser and a pull server. In git, these\n> duties are split. Depending on what you want, you can:\n> - for allowing people to pull from you, you can use git-daemon\n> - for repository browsing, run an instance of gitweb. There is a\n> git-instaweb script for doing one-off \"I just need to set this up\n> for a minute\" versions.\n\nOr you can use one of the history viewers: gitk (Tcl/Tk), qgit (Qt),\nGiggle or GitView (GTK+), or tig (ncurses).\n\n> - you can also allow people to pull via http; just copy your '.git'\n> directory somewhere that is accessible by the web server\n\nNote that you have to run git-update-server-info to update auxiliary\ninfo file to help dumb servers (which includes HTTP server),\npreferably in 'update' (for publishing repos) or 'post-commit' (for\nworking repos) hook.\n\n> - you can also allow people to pull via ssh; just give them an ssh\n> account and point them to host:/path/to/repo\n\nYou can use git-shell as shell to lomit access to only pulling /\npushing changes.\n\nIMHO it is better to leave serving web pages to web server, instead of\ntrying to do that in an SCM... even if Python has support for creating\nbasic HTTP server easily. (We could add bare-bones gitweb and git\nonly, written in Perl HTTP server in gitweb/, but what for...).\n\n\n> \"hg bundle\" has an equivalent in git: \"git bundle\"\n\nMinor difference: it is \"git bundle create\" and \"git bundle unbundle\"\n(or \"git pull \") versus \"hg bundle\" and \"hg unbundle\".\n\n> \"hg export\" seems to generate the commit message + patch for a set of\n> commits. The git equivalent is \"git format-patch\" which puts each patch\n> in its own mbox file (you can also use \"git format-patch --stdout >mbox\"\n> to put them all in one mbox.\n\nIt looks like there is no exact equivalent. \"git format-patch\" is used\nto generate series of patches, but it doesn't for example saves\nparent(s) of a commit; not that it makes much sense. It is meant to\nsend patches for review (and then applying).\n\nBy the way, for binary files git would send binary diff, which can be\napplied _only_ if you have exact preimage, so this is no problem:\n\nhg export:\n\n Without the -a option, export will avoid generating diffs of files\n it detects as binary. With -a, export will generate a diff anyway,\n probably with undesirable results.\n\n> \"hg import\" presumably applies the results of \"hg export\". In git, this\n> is \"git am\" (where am stands for apply mailbox), which applies the\n> changes from an entire mbox one by one.\n\nNote that \"git format-patch\" / \"git am\" is meant for mail driven\nworkflow, with patches send for _review_ to maintainer or [public]\nmailing list, and applied by maintainer on case by case basis. This\nmeans for example that commit from patch might be applied in different\nplace of revision graph than original; \"git am --3way\" fallbacks on\n3-way merge (based on embedded original pre-image blob (file)\nidentifier) if patch cannot be applied cleanly.\n\nIt is not meant as a transport mechanism: use interactive protocols\n(ssh, git, http) for that, or git-bundle if it is impossible.\n\n> \"incoming\" and \"outgoing\" seem to basically be diffs against remote\n> repositories (i.e., \"what do I have that he doesn't\" and vice versa). In\n> git, you would do a \"git fetch\" to say \"contact the remote repository\n> and get what he has, but don't update any of my branches\" followed by\n> \"git log origin..HEAD\" (what does I have that he doesn't) or \"git log\n> HEAD..origin\" (the opposite). You can also use the symmetric difference\n> with a graphical browser like gitk: \"gitk origin...HEAD\" which will show\n> everything that he has and everything you have, down to the point where\n> the two histories last diverged.\n\nHere (and in neighbour post about diff between branches) we come to\nthe main difference between Git and Mercurial, namely that Git uses\nmultiple-branches in repository workflow extensively[*1*], while in\nMercurial multiple branches in single repository are still (from what\nI have read) secondary citizens; main workflow is still one branch per\nrepository.\n\n(I'm not sure if Mercurial gets correctly the difference between tags\nand branches, but that is just me spreading FUD ;-)).\n\nGit uses concept of remote tracking branches to track changes in\nremote repository. By default after cloning repository which has for\nexample branches 'master' (stable branch) and 'next' (development\nbranch) you have local branch 'master' (fullname: refs/heads/master)\nfor your own work, and 'origin/master' and 'origin/next' (where\n'origin' is default name for origin-al repository you by default fetch\nfrom) remote tracking branches (fullname: refs/remotes/origin/master,\nrefs/remotes/origin/next). You have also symbolic ref 'HEAD' which\ndenotes current branch; points which branch you are currently work\nwith, and ref 'origin' (fullname: refs/remotes/origin/HEAD) denoting\ndefault branch on remote repository.\n\nIn Git \"pull\" consists of two steps: 'fetch' which downloads objects\n(changes) and updates refs, and 'merge' which joins the histories (or\ndoes fast-forward) and updates current branch. From what I understand\nfrom Mercurial documentation hg it has those actions split in a\ndifferent way: \"hg incoming\" to examine changes, and \"hg pull;\nhg update\" to join histories.\n\nSo to examine some defined repository one would do a \"git fetch \", \nwhere is shortcut repository name, and then examine\n/ remote tracking branches. Note that it looks like\n\"hg incoming\" can deal sensibly only with one branch per repository\nrepositories (further FUD spreading ;-)). If you want to preview some\nforeign repo you can use \"git fetch \" or \"git fetch \n\" and examine FETCH_HEAD.\n\nNote that the fact that some branch in remote repository and\nrespective remote-tracking branch differ might mean many things:\n a.) remote repository has avanced wrt. our repository\n b.) remote repository lags behind our repository\n (e.g. both are sister repositories cloned from the same repo)\n c.) histories diverged, or were rewound / rewritten\nI wonder how Mercurial deals with cases b.) and c.) (further anti-hg\nFUD ;-))\n\nNow to examine what changed you can use _generic_ revision list\nspecification in some history browser (git-log, gitk, git-show-branch,\netc.). Here you can use \"A..B\" syntax (what's in B, excluding what is\nin A, which in the case of linear history is: what is between A and\nB), and \"A...B\" syntax (what's in A and B, excluding what's in common\nancestor (merge base) of both of them). A and/or B can be: HEAD\n(current branch), 'origin' or for default remote repository\nbranch, FETCH_HEAD for what was just fetched, or even\norigin@{1}..origin to show what fetch brought to 'origin/HEAD'.\n\nIf Git ever would want to have a command which would show which\nbranches differ in some remote repository, I think it would be added\nto \"git remote\" (which I recommend checking).\n\n> > I've contributed changes to both git and hg projects and haven't had \n> > good luck submitting changes upstream. I'd be interesting in talking to \n> > people who collaborate on projects using git both as first and \n> > second-level contributors to see if their experiences are any better than \n> > mine. I don't doubt that I may be doing it wrong.\n> \n> Again, if you have specific questions, please feel free to ask on the\n> git list. We are more than happy to help out if we can.\n\nWell, there are around 250 contributors to git which have more than\none commit to his/her name. Even excluding some fuzz factor due to\nwrong / changed credentials.\n\nMasukomi (Kate Rhodes) wrote in her blog in \"Some thoughts about Git\"\nhttp://weblog.masukomi.org/2008/2/4/some-thoughts-about-git\n\n And then I joined the Git mailing list. Linus mentioned that it had\n a high signal to noise ratio but... *holy shit*. I have been on a\n lot of mailing lists for open source projects over the years and I\n have never seen anything like this. Almost every e-mail is a patch,\n or a good discussion of a patch, or a good discussion of some new\n feature and how to go about implementing it.\n\n> > Should memcached choose git, it may be as simple as putting up a page \n> > that says, ``this is how you clone, this is how you work, this is how you \n> > submit your changes back.''\n> \n> I don't know hg very well, but my impression is that the implementation\n> is quite similar to git and that writing a document \"translating\"\n> commands from one system to the other would be feasible.\n\nActualy while ideas and workflows might be similar, implementation\ndiffers quite a bit.\n\nGit is snapshot based[*2*]; in git repository is object database, with\ncommits being points in DAG (Directed Acyclic Graph) of revisions,\npointing to their parent commits and to snapshot of a repository state\nat given revision. Branches, remote tracking branches and tags are\n[named] pointers to points (staring points) in DAG of revisions. There\nHEAD which is pointer to pointer, or simply something which names\ncurrent branch (symbolic reference to current branch name). File\nstructure is reflected in object database using hierchical tree object\nstructure; file name and parts of permissions are stored in tree\nobjects. This structure allows for fast merges (and fast warm-cache\nperformance, supposedly).\n\nMercurial I know only secondhand, from the discussion on #revctrl IRC\nchannel, and from Mercurial documentation. It is AFAICT\nchangeset-based, with changesets stored \"hashed\" in per [current]\nfilename buckeds, tied together in flat manifest like file which ties\nfiles together, tied together in revlog changeset-log file which\nstores commits. Branches and tags are stored as in-tree file (inside\nworking directory of repository), similarly to .gitignore / .hgignore\nfile, with (for tags at least) some complicated rule of updating it\nwhen switching branches and going to given revision (further anti-hg\nFUD; I hope that changed...). The pref-file-bucket structure allows\nfor fast patch applying (and fast cold-cache performance, supposedly).\n\n\nFootnotes:\n==========\n[*1*] Junio C Hamano (current git maintainer), wrote in his blog\nin \"FLOSS weekly #19 follow-up (3)\" entry:\n http://gitster.livejournal.com/9970.html \n\n \"The very basic structure and idea behind git has not changed since\n Linus wrote the initial implementation\".\n\n Well, while that is not _untrue_, that statement itself may lead to\n confusion unless clarified.\n\n [...]\n\n * We did not envision that multiple branches in a single repository\n would turn out to be such a useful way to work, and did not have\n support for switching branches;\n\n\n[*2*] Even if in packed form it is stored as delta chains; but that is\n just [transparent] engine.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}