{"thread":{"id":"13951","subject":"Document clone of clone loosing branches?","startedAt":"2008-06-14T13:05:48Z","lastAt":"2008-06-15T20:14:34Z","messageCount":20,"participants":["Vaclav Hanzl","Jeff King","Jakub Narebski","Lea Wiemann","Junio C Hamano","Robin Rosenberg","Wincent Colaiuta","Miklos Vajna"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"79854","messageId":"20080614.150548.71104932.hanzl@noel.feld.cvut.cz","threadId":"13951","inReplyTo":null,"subject":"Document clone of clone loosing branches?","fromName":"Vaclav Hanzl","fromEmail":"hanzl@noel.feld.cvut.cz","sentAt":"2008-06-14T13:05:48Z","receivedAt":"2008-06-14T13:05:48Z","isPatch":false,"sender":{"key":"hanzl@noel.feld.cvut.cz","avatar":null},"body":"I wander whether man git-clone is correct when it says \"creates\nremote-tracking branches for each branch in the cloned repository\".\n\nIMHO remote-tracking branches in the original repository _are_\nbranches and they are _not_ cloned (when using git-clone with no\noptions) - maybe this is worth noting very explicitly?\n\nWhen git newby like me converts a CVS repository, containing just few\nshort old branches (stable release bug fixes) and then clones it\naround, with naive belief that clone is a 1:1 copy or something close,\nnasty surprise can happen:\n\n - converted repository has those branches, OK\n - clone of it also has them, but as a remote tracking branches\n - clone of clone has it as dangling objects only (can go away later)\n\nTrying to play it safe, I used git-clone many times while starting\nwith git, and I got really nervous when I first discovered that my old\nstable release bug fix branch is not visible in some repositories :-)\n\nIs it just my failure to read those few hundred man pages carefully\nenough (I did my best :-) ), or something worth fixing in man\ngit-clone and tutorials?\n\nRegards,\n\nVaclav Hanzl\n"},{"id":"79855","messageId":"20080614143117.GA8640@sigill.intra.peff.net","threadId":"13951","inReplyTo":"20080614.150548.71104932.hanzl@noel.feld.cvut.cz","subject":"Re: Document clone of clone loosing branches?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-14T14:31:17Z","receivedAt":"2008-06-14T14:31:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 14, 2008 at 03:05:48PM +0200, Vaclav Hanzl wrote:\n\n> I wander whether man git-clone is correct when it says \"creates\n> remote-tracking branches for each branch in the cloned repository\".\n> \n> IMHO remote-tracking branches in the original repository _are_\n> branches and they are _not_ cloned (when using git-clone with no\n> options) - maybe this is worth noting very explicitly?\n\nThe new repository has remote tracking branches of the _regular_\nbranches that are in the original repository. So the statement is\ncorrect; git-clone creates remote-tracking branches, and it makes one\nsuch branch for each branch in the cloned repository.\n\nUnless you are complaining that it makes one for each non-remote branch\nin the cloned repository. But I think it is the general pattern to refer\nto things in refs/heads/ as simply unadorned \"branch\". If you want to\nsay \"all refs, including remote-tracking branches\", you would typically\nsay \"refs\" (which would also include tags).\n\n> When git newby like me converts a CVS repository, containing just few\n> short old branches (stable release bug fixes) and then clones it\n> around, with naive belief that clone is a 1:1 copy or something close,\n> nasty surprise can happen:\n\nIn that sense, clone is a bit of a misnomer, because the two _are_\ndifferent. The cloned repo has its origin pointing to the original repo,\nand the origin of the original repo (and its associated tracking\nbranches) are forgotten.\n\n> - converted repository has those branches, OK\n> - clone of it also has them, but as a remote tracking branches\n> - clone of clone has it as dangling objects only (can go away later)\n\nThe clone of clone does not have dangling objects; either it sees a ref\n(because it is a branch in the clone) and it grabs the objects, or it\ndoes not see it, in which case it does not download those objects.\n\n> Trying to play it safe, I used git-clone many times while starting\n> with git, and I got really nervous when I first discovered that my old\n> stable release bug fix branch is not visible in some repositories :-)\n\nYes, this is sometimes annoying if what you _really_ want is another\nclone of the clone's origin. For me, this happens because I want to\nclone Junio's git.git (to do some experimentation that might trash the\nrepo), but:\n\n - I am too lazy to type Junio's git URL\n - I want the hard-link space-saving of cloning my local repo\n\nSo I do something like:\n\n ref=/path/to/my/git/repo\n git clone --reference $ref `cd $ref && git config remote.origin.url`\n\nwhich you can easily put in an alias.\n\n-Peff\n"},{"id":"79856","messageId":"m31w30qe9x.fsf@localhost.localdomain","threadId":"13951","inReplyTo":"20080614.150548.71104932.hanzl@noel.feld.cvut.cz","subject":"Re: Document clone of clone loosing branches?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-14T14:31:29Z","receivedAt":"2008-06-14T14:31:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Vaclav Hanzl writes:\n\n> I wander whether man git-clone is correct when it says \"creates\n> remote-tracking branches for each branch in the cloned repository\".\n> \n> IMHO remote-tracking branches in the original repository _are_\n> branches and they are _not_ cloned (when using git-clone with no\n> options) - maybe this is worth noting very explicitly?\n[...]\n\nThe idea is for git-clone to clone (by default) _your_ work, not sb\nelse work. Think about two repositories, fetching from each other:\nyou don't want for branches to proliferate like mad, remote of remote,\nthen remote of remote of remote, and ad infinitum.\n\nBesides there is I think implicit assumption that public repositories\none might want to clone are _bare_ repositories, 1:1 or mirror\nrefspecs, which simply do not contain remote tracking branches.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"79858","messageId":"4853D967.5080903@gmail.com","threadId":"13951","inReplyTo":"20080614.150548.71104932.hanzl@noel.feld.cvut.cz","subject":"Re: Document clone of clone loosing branches?","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-06-14T14:44:55Z","receivedAt":"2008-06-14T14:44:55Z","isPatch":false,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"Vaclav Hanzl wrote:\n> with naive belief that clone is a 1:1 copy or something close,\n> nasty surprise can happen:\n\nI got bitten by that, too. Perhaps the intro paragraph of git-clone.txt \n(man git-clone) could mention that remote branches are not cloned or so. \n (I don't know git-clone well enough to be able to phrase it \naccurately, but perhaps someone else wants to send a documentation patch...)\n\n-- Lea\n"},{"id":"79880","messageId":"20080614.221511.74741328.hanzl@noel.feld.cvut.cz","threadId":"13951","inReplyTo":"20080614143117.GA8640@sigill.intra.peff.net","subject":"Re: Document clone of clone ... bug??","fromName":"Vaclav Hanzl","fromEmail":"hanzl@noel.feld.cvut.cz","sentAt":"2008-06-14T20:15:11Z","receivedAt":"2008-06-14T20:15:11Z","isPatch":false,"sender":{"key":"hanzl@noel.feld.cvut.cz","avatar":null},"body":"> The clone of clone does not have dangling objects; either it sees a ref\n> (because it is a branch in the clone) and it grabs the objects, or it\n> does not see it, in which case it does not download those objects.\n\nYes, there should not be a dangling object, but I actually got one. I\nwas surprised, but I thought it is just an undocumented benign behavior\n(optimization overkill - clone rather gets those objects instead of\nthinking what it needs). Now I think it may be a bug.\n\nCan someone with deeper knowledge and fresh git please try this:\n\n rm -rf A B C\n mkdir A B C\n (cd A; mkdir X; cd X; git init; echo x>x; git add x; git commit -m xxx;\n git checkout -b br; echo y>y; git add y; git commit -m yyy;\n git checkout master)\n (cd B; git clone ../A/X)\n (cd C; git clone ../B/X; cd X; git fsck --full)\n\nWith my 11 days old version of git, I get:\n\n dangling commit ...\n\nand 'git show ...' reveals that this commit it that otherwise\n(rightfully) lost branch 'br'.\n\nSHA1 is changing when I repeat this (due to dates in reflogs??).\n\nWhen I omit 'git checkout master', no dangling commit appears. Strange.\n\nIs it my faulty thinking, benign undocumented thing, or a bug?\n\nVaclav Hanzl\n"},{"id":"79881","messageId":"m3skvfpxgp.fsf@localhost.localdomain","threadId":"13951","inReplyTo":"20080614.221511.74741328.hanzl@noel.feld.cvut.cz","subject":"Re: Document clone of clone ... bug??","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-14T20:34:35Z","receivedAt":"2008-06-14T20:34:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Vaclav Hanzl writes:\n\n> > The clone of clone does not have dangling objects; either it sees a ref\n> > (because it is a branch in the clone) and it grabs the objects, or it\n> > does not see it, in which case it does not download those objects.\n> \n> Yes, there should not be a dangling object, but I actually got one. I\n> was surprised, but I thought it is just an undocumented benign behavior\n> (optimization overkill - clone rather gets those objects instead of\n> thinking what it needs).\n[...]\n> (cd B; git clone ../A/X)\n\n_Local_ clone? This is result of optimization; in cloning over local\nfilesystem case git-clone simply hardlinks object database (if\npossible) instead of transferring objects. This was only on request\nin earlier versions of git.\n\nYou can use filr:// protocol to force generating of pack-file and\nactual transfer of objects.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"79882","messageId":"20080614.224840.41641579.hanzl@noel.feld.cvut.cz","threadId":"13951","inReplyTo":"m3skvfpxgp.fsf@localhost.localdomain","subject":"Re: Document clone of clone ... bug??","fromName":"Vaclav Hanzl","fromEmail":"hanzl@noel.feld.cvut.cz","sentAt":"2008-06-14T20:48:40Z","receivedAt":"2008-06-14T20:48:40Z","isPatch":false,"sender":{"key":"hanzl@noel.feld.cvut.cz","avatar":null},"body":"> _Local_ clone? This is result of optimization; in cloning over local\n> filesystem case git-clone simply hardlinks object database (if\n> possible) instead of transferring objects. This was only on request\n> in earlier versions of git.\n>\n> You can use filr:// protocol to force generating of pack-file and\n> actual transfer of objects.\n\n\nStill dangling even with 'file:', using (in my case) this:\n\n pwd\n rm -rf A B C\n mkdir A B C\n (cd A; mkdir X; cd X; git init; echo x>x; git add x; git commit -m xxx;\n git checkout -b y; echo y>y; git add y; git commit -m yyy;\n git checkout master)\n (cd B; git clone file:///home/kroupa/tmp/gittest/A/X; cd X; git branch -a)\n (cd C; git clone file:///home/kroupa/tmp/gittest/B/X; cd X; git branch -a; git fsck --full)\n\n\nThe actual result of pasting this to shell is:\n\n~/tmp/gittest>pwd\n/home/kroupa/tmp/gittest\n~/tmp/gittest>rm -rf A B C\n~/tmp/gittest>mkdir A B C\n~/tmp/gittest>(cd A; mkdir X; cd X; git init; echo x>x; git add x; git commit -m xxx;\n> git checkout -b y; echo y>y; git add y; git commit -m yyy;\n> git checkout master)\nInitialized empty Git repository in .git/\nCreated initial commit ec59a7e: xxx\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 x\nSwitched to a new branch \"y\"\nCreated commit 2be193d: yyy\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 y\nSwitched to branch \"master\"\n~/tmp/gittest>(cd B; git clone file:///home/kroupa/tmp/gittest/A/X; cd X; git branch -a)\nInitialized empty Git repository in /home/kroupa/tmp/gittest/B/X/.git/\nremote: Counting objects: 6, done.\nremote: Compressing objects: 100% (3/3), done.\nremote: Total 6 (delta 0), reused 0 (delta 0)\nReceiving objects: 100% (6/6), done.\n* master\n origin/HEAD\n origin/master\n origin/y\n~/tmp/gittest>(cd C; git clone file:///home/kroupa/tmp/gittest/B/X; cd X; git branch -a; git fsck --full)\nInitialized empty Git repository in /home/kroupa/tmp/gittest/C/X/.git/\nremote: Counting objects: 6, done.\nremote: Compressing objects: 100% (3/3), done.\nremote: Total 6 (delta 0), reused 6 (delta 0)\nReceiving objects: 100% (6/6), done.\n* master\n origin/HEAD\n origin/master\ndangling commit 2be193dc7dc3e1051dcf5af9d03f7587b61f9fc3\n\n\nAnd the dangling object is:\n\n\n~/tmp/gittest>cd C/X; git show 2be193d\ncommit 2be193dc7dc3e1051dcf5af9d03f7587b61f9fc3\nAuthor: kroupa \nDate: Sat Jun 14 22:47:46 2008 +0200\n\n yyy\n\ndiff --git a/y b/y\nnew file mode 100644\nindex 0000000..975fbec\n--- /dev/null\n+++ b/y\n@@ -0,0 +1 @@\n+y\n\n\n\nAny thoughts?\n\nVaclav\n"},{"id":"79884","messageId":"20080614.233645.71097102.hanzl@noel.feld.cvut.cz","threadId":"13951","inReplyTo":"4853D967.5080903@gmail.com","subject":"Re: Document clone of clone loosing branches?","fromName":"Vaclav Hanzl","fromEmail":"hanzl@noel.feld.cvut.cz","sentAt":"2008-06-14T21:36:45Z","receivedAt":"2008-06-14T21:36:45Z","isPatch":false,"sender":{"key":"hanzl@noel.feld.cvut.cz","avatar":null},"body":"Lea Wiemann wrote:\n> I got bitten by that, too. Perhaps the intro paragraph of git-clone.txt \n> (man git-clone) could mention that remote branches are not cloned or so. \n> (I don't know git-clone well enough to be able to phrase it \n> accurately, but perhaps someone else wants to send a documentation patch...)\n\nThis is exactly what I would like to happen. (If nobody seems\ninterested, I might propose my own bad very first patch few days or\nweeks later...)\n\nJeff King wrote:\n> The new repository has remote tracking branches of the _regular_\n> branches that are in the original repository. So the statement is\n> correct; git-clone creates remote-tracking branches, and it makes one\n> such branch for each branch in the cloned repository.\n> \n> Unless you are complaining that it makes one for each non-remote branch\n> in the cloned repository. But I think it is the general pattern to refer\n> to things in refs/heads/ as simply unadorned \"branch\". If you want to\n> say \"all refs, including remote-tracking branches\", you would typically\n> say \"refs\" (which would also include tags).\n\nI am not sure that the term 'branch' can be reasonably expected to\nmean 'regular branch' unless specified otherwise. For example, 'man\ngit' says:\n\n git-branch(1)\n List, create, or delete branches.\n\nIt can also list remote-tracking branches, cannot it? Or:\n\n git-show-branch(1)\n Show branches and their commits.\n\nCan also show remote-tracking branches, cannot it?\n\nEven if 'branch' were very well known to mean 'regular branch', I\nwould still argue that 'man clone' is a very good place to define\nthese vocabulary conventions.\n\nSo I still think that 'man clone' is wrong as it stands now. It is not\ntrue that all 'branches' are cloned. It would be better to say quite\nexplicitly that regular branches are cloned and remote tracking\nbranches are not.\n\n\nJakub Narebski wrote:\n> The idea is for git-clone to clone (by default) _your_ work, not sb\n> else work. Think about two repositories, fetching from each other:\n> you don't want for branches to proliferate like mad, remote of remote,\n> then remote of remote of remote, and ad infinitum.\n> \n> Besides there is I think implicit assumption that public repositories\n> one might want to clone are _bare_ repositories, 1:1 or mirror\n> refspecs, which simply do not contain remote tracking branches.\n\n\nYes. It would be no shame if an explanation like this made it to 'man\nclone'?\n\nAfter all, how many other commands do distinguish regular branches and\nremote tracking branches? Even if there are any other (I do not know),\ngit-clone is likely the most prominent of them and 'man git-clone' is\nquite good place to document this. Unless it is explained in 'man git'\nitself (I think it is not now).\n\n(Thought I am quite happy with UNIX tradition of very exact and very\ncondensed man pages, up to the point of being a hard puzzle, and I\nagree that man pages are no tutorial, in this case I would be happy to\nsee 'regular branches' and 'remote tracking branches' clearly\ndistinguished in 'man git-clone' itself, without an implicit reference\nto 'usual' meaning of words among geeks.)\n\nRegards,\n\nVaclav Hanzl\n\nP.S. Sorry for screwing up mail threads by this synthetic answer but I\nthought it is not worth 3 messages (?)\n"},{"id":"79887","messageId":"7vr6azfyov.fsf@gitster.siamese.dyndns.org","threadId":"13951","inReplyTo":"20080614.233645.71097102.hanzl@noel.feld.cvut.cz","subject":"Re: Document clone of clone loosing branches?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-14T22:18:08Z","receivedAt":"2008-06-14T22:18:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Vaclav Hanzl writes:\n\n> I am not sure that the term 'branch' can be reasonably expected to\n> mean 'regular branch' unless specified otherwise. For example, 'man\n> git' says:\n>\n> git-branch(1)\n> List, create, or delete branches.\n>\n> It can also list remote-tracking branches, cannot it? Or:\n>\n> git-show-branch(1)\n> Show branches and their commits.\n>\n> Can also show remote-tracking branches, cannot it?\n\nThese fall into \"quibbling\" category, but that judgement can only be made\nby people who know the history.\n\nUpdates to glossary and other introductory documents might be necessary.\nFor example, the entry about \"tracking branch\" in the glossary still talks\nabout the ancient convention of copying 'master' to 'origin' as a regular\nbranch:\n\n [[def_tracking_branch]]tracking branch::\n A regular git <> that is used to follow changes from\n another <>. A tracking\n branch should not contain direct modifications or have local commits\n made to it. A tracking branch can usually be\n identified as the right-hand-side <> in a Pull:\n <>.\n\nThis does _not_ reflect post v1.3.0 reality at all. No git more recent\nthan Apr 2006 has used a \"regular git branch\" for tracking.\n\nIt probably is enough to say:\n\n A ref that is used to follow changes from another repository.\n\tIn modern git, they are found in `refs/remotes/` hierarchy.\n\nbecause you cannot add \"direct modifications or have local commits\" to\nthem anymore.\n"},{"id":"79891","messageId":"200806150103.02260.jnareb@gmail.com","threadId":"13951","inReplyTo":"20080614.233645.71097102.hanzl@noel.feld.cvut.cz","subject":"Re: Document clone of clone loosing branches?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-14T23:03:01Z","receivedAt":"2008-06-14T23:03:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Vaclav Hanzl wrote:\n> Jakub Narebski wrote:\n>>\n>> The idea is for git-clone to clone (by default) _your_ work, not sb\n>> else work. Think about two repositories, fetching from each other:\n>> you don't want for branches to proliferate like mad, remote of remote,\n>> then remote of remote of remote, and ad infinitum.\n>> \n>> Besides there is I think implicit assumption that public repositories\n>> one might want to clone are _bare_ repositories, 1:1 or mirror\n>> refspecs, which simply do not contain remote tracking branches. \n> \n> Yes. It would be no shame if an explanation like this made it to 'man\n> clone'?\n\nThe question of course is _what_ to put into git-clone(1), what to\ngeneric documentation in git(1), and what in \"Git User's Manual\".\n\n> After all, how many other commands do distinguish regular branches and\n> remote tracking branches?\n\nErrr... many of them? git-branch treats regular branches (refs/heads/*)\nand remote-tracking branches (refs/remotes//*) differently\n(compare \"git branch\" and \"git branch -r\", and \"git branch -a\").\ngit-checkout treats regular branches (can checkout) different from\nother refs, including remote-tracking branches (result in detached\nHEAD).\n\n> Even if there are any other (I do not know), \n> git-clone is likely the most prominent of them and 'man git-clone' is\n> quite good place to document this. Unless it is explained in 'man git'\n> itself (I think it is not now).\n\nI'm not sure how it is put in documentation, but I wouldn't wonder\nif it is not dicumented, because most of gitters who can write this\ndocumentation do know the difference between regular branches and\nremote-tracking branches, and know recoomended workflows and best\npractices.\n \n> (Thought I am quite happy with UNIX tradition of very exact and very\n> condensed man pages, up to the point of being a hard puzzle, and I\n> agree that man pages are no tutorial, in this case I would be happy to\n> see 'regular branches' and 'remote tracking branches' clearly\n> distinguished in 'man git-clone' itself, without an implicit reference\n> to 'usual' meaning of words among geeks.)\n\nSo, what should be mentioned ar two facts, I think. (a) that git-clone\ncopies only regular branches and tags; it does not copy remote-tracking\nbranches, it does not copy stash, it does not copy reflogs, it does not\ncopy StGIT stacks... (b) that recommended workflow (best practice) is\nto have public published repository which is bare clone\n(1:1 correspondnce) of interesting subset of refs.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"79909","messageId":"20080615.091827.74736349.hanzl@noel.feld.cvut.cz","threadId":"13951","inReplyTo":"7vr6azfyov.fsf@gitster.siamese.dyndns.org","subject":"Re: Document clone of clone loosing branches?","fromName":"Vaclav Hanzl","fromEmail":"hanzl@noel.feld.cvut.cz","sentAt":"2008-06-15T07:18:27Z","receivedAt":"2008-06-15T07:18:27Z","isPatch":false,"sender":{"key":"hanzl@noel.feld.cvut.cz","avatar":null},"body":"> These fall into \"quibbling\" category, but that judgement can only be made\n> by people who know the history.\n\nI allowed myself to quibble much more than usually as I think it\nserves a good technical purpose. I am a new git user but quite\npervasive in getting all the info I can (I have bound copy of all git\nman pages and about ten tutorials, diligently devoting much of my time\nlast month to reading it all; generally I am not scared by strange\nthings like plain Tex, FORTH, Prolog etc.) so I might serve as a good\nexample of user who tried hard and still did not get it with current\ndocs.\n\nBut it is a thin border, so please do not hesitate to shut me up if my\njudgement of technical merit is wrong.\n\n> Updates to glossary and other introductory documents might be necessary.\n> For example, the entry about \"tracking branch\" in the glossary still talks\n> about the ancient convention of copying 'master' to 'origin' as a regular\n> branch:\n\nI would appreciate this update ;-)\n\nRegards (and big thanks for git!),\n\nVaclav\n"},{"id":"79911","messageId":"m3od63ozuf.fsf@localhost.localdomain","threadId":"13951","inReplyTo":"20080614.150548.71104932.hanzl@noel.feld.cvut.cz","subject":"Re: Document clone of clone loosing branches?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-15T08:40:45Z","receivedAt":"2008-06-15T08:40:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Vaclav Hanzl writes:\n\n> I wander whether man git-clone is correct when it says \"creates\n> remote-tracking branches for each branch in the cloned repository\".\n> \n> IMHO remote-tracking branches in the original repository _are_\n> branches and they are _not_ cloned (when using git-clone with no\n> options) - maybe this is worth noting very explicitly?\n\nIt probably should read \"for each _regular_ branch in the cloned\nrepository\".\n\nAnd of course if you are creating bare clone it does mirror regular\nbranches (1:1 mapping) instead of remote-tracking branches (mappping\nfrom refs/heads/* into refs/remotes/origin/* namespace).\n\n[...]\n> Is it just my failure to read those few hundred man pages carefully\n> enough (I did my best :-) ), or something worth fixing in man\n> git-clone and tutorials?\n\nEven if it is just your failure it would be worh correcting\n(enhancing) documentation to make it more clear.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"79927","messageId":"200806151505.27686.robin.rosenberg.lists@dewire.com","threadId":"13951","inReplyTo":"m3od63ozuf.fsf@localhost.localdomain","subject":"[PATCH] Documentation: Note about the meaning of \"clone\"","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-06-15T13:05:27Z","receivedAt":"2008-06-15T13:05:27Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Clarify that a clone is not an exact copy.\n\nSigned-off-by: Robin Rosenberg \n---\n Documentation/git-clone.txt | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex 7973e6a..c9bc627 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -31,7 +31,12 @@ This default configuration is achieved by creating references to\n the remote branch heads under `$GIT_DIR/refs/remotes/origin` and\n by initializing `remote.origin.url` and `remote.origin.fetch`\n configuration variables.\n-\n++\n+*NOTE*: Although this command is called clone, the clone is not identical\n+in all respects. Local branches in the repository being cloned\n+becomes remote tracking branches in the clone and remote tracking\n+branches are not cloned at all. For security reasone the config sections\n+and triggers are not cloned either.\n \n OPTIONS\n -------\n-- \n1.5.5.1.178.g1f811\n"},{"id":"79926","messageId":"200806151505.28987.robin.rosenberg.lists@dewire.com","threadId":"13951","inReplyTo":"m3od63ozuf.fsf@localhost.localdomain","subject":"PATCH] cvsimport: Clarification on the use of -r","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-06-15T13:05:28Z","receivedAt":"2008-06-15T13:05:28Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\nSigned-off-by: Robin Rosenberg \n---\n Documentation/git-cvsimport.txt | 10 +++++++---\n 1 files changed, 7 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\nindex 2f9b35f..b873882 100644\n--- a/Documentation/git-cvsimport.txt\n+++ b/Documentation/git-cvsimport.txt\n@@ -28,8 +28,12 @@ You should *never* do any work of your own on the branches that are\n created by git-cvsimport. By default initial import will create and populate a\n \"master\" branch from the CVS repository's main branch which you're free\n to work with; after that, you need to 'git merge' incremental imports, or\n-any CVS branches, yourself. It is advisable to specify a named remote via\n--r to separate and protect the incoming branches.\n+any CVS branches, yourself.\n+\n+It is advisable to specify a named remote via -r to separate and protect\n+the incoming branches if you intend to do your work in the same repository. If\n+you want to have a cvs import-only repostory which you clone to your work\n+repository, then do not use the -r option.\n \n \n OPTIONS\n@@ -56,7 +60,7 @@ OPTIONS\n -r ::\n \tThe git remote to import this CVS repository into.\n \tMoves all CVS branches into remotes//\n-\takin to the git-clone --use-separate-remote option.\n+\takin what git clone does when cloning a repository.\n \n -o ::\n \tWhen no remote is specified (via -r) the 'HEAD' branch\n-- \n1.5.5.1.178.g1f811\n"},{"id":"79931","messageId":"200806151539.17967.jnareb@gmail.com","threadId":"13951","inReplyTo":"200806151505.27686.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Documentation: Note about the meaning of \"clone\"","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-15T13:39:17Z","receivedAt":"2008-06-15T13:39:17Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robin Rosenberg wrote:\n>\n> Clarify that a clone is not an exact copy.\n\n> +*NOTE*: Although this command is called clone, the clone is not identical\n> +in all respects. Local branches in the repository being cloned\n> +becomes remote tracking branches in the clone and remote tracking\n> +branches are not cloned at all. For security reasone the config sections\n> +and triggers are not cloned either.\n\nOne nitpick, one comment, one historical comment.\n\nNitpick: Actually biological clone is usually not identical in\nphenotype, and we know now that due to different gene expression\nit can have different genotype as well. ;-)\n\nCOMMENT: when you do \"git clone --bare\" it mirrors local (regular)\nbranches in 1:1 correspondence; but it still doesn't clone anything\noutside refs/heads/ and refs/remotes (and HEAD).\n\nHistorical comment: git-clone used to do 1:1 mapping even for non-bare\nclone, with exception of -> origin mapping, before\nbehavior provided by --use-separate-remotes was made default (thanks\nCarl!).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"79932","messageId":"D6D7C2A1-C755-4564-AB85-B893FA3000D0@wincent.com","threadId":"13951","inReplyTo":"200806151505.27686.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Documentation: Note about the meaning of \"clone\"","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-15T13:52:38Z","receivedAt":"2008-06-15T13:52:38Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 15/6/2008, a las 15:05, Robin Rosenberg escribió:\n\n> Clarify that a clone is not an exact copy.\n>\n> Signed-off-by: Robin Rosenberg \n> ---\n> Documentation/git-clone.txt | 7 ++++++-\n> 1 files changed, 6 insertions(+), 1 deletions(-)\n>\n> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n> index 7973e6a..c9bc627 100644\n> --- a/Documentation/git-clone.txt\n> +++ b/Documentation/git-clone.txt\n> @@ -31,7 +31,12 @@ This default configuration is achieved by \n> creating references to\n> the remote branch heads under `$GIT_DIR/refs/remotes/origin` and\n> by initializing `remote.origin.url` and `remote.origin.fetch`\n> configuration variables.\n> -\n> ++\n> +*NOTE*: Although this command is called clone, the clone is not \n> identical\n> +in all respects. Local branches in the repository being cloned\n> +becomes remote tracking branches in the clone and remote tracking\n\nGrammar: \"become\", not \"becomes\"\n\n>\n> +branches are not cloned at all. For security reasone the config \n> sections\n> +and triggers are not cloned either.\n\nTypo: \"security reasons\", not \"security reasone\"\n\nYou might also want to mention that the clone is not necessarily a \nredundant _copy_ of the original repo, because at least for local \nclones on the same file system clone will use hard links rather than \nactually making a copy, unless you explicitly tell it not to.\n\nW\n"},{"id":"79939","messageId":"20080615.183150.74717434.hanzl@noel.feld.cvut.cz","threadId":"13951","inReplyTo":"D6D7C2A1-C755-4564-AB85-B893FA3000D0@wincent.com","subject":"Re: [PATCH] Documentation: Note about the meaning of \"clone\"","fromName":"Vaclav Hanzl","fromEmail":"hanzl@noel.feld.cvut.cz","sentAt":"2008-06-15T16:31:50Z","receivedAt":"2008-06-15T16:31:50Z","isPatch":true,"sender":{"key":"hanzl@noel.feld.cvut.cz","avatar":null},"body":"> You might also want to mention that the clone is not necessarily a \n> redundant _copy_ of the original repo, because at least for local \n> clones on the same file system clone will use hard links rather than \n> actually making a copy, unless you explicitly tell it not to.\n\nAt the moment this is covered in description of the --local option\n(I personally found it very easy to get this knowledge, dislike other\ndifferences from 1:1)\n\nVaclav\n"},{"id":"79940","messageId":"20080615.190304.41663135.hanzl@noel.feld.cvut.cz","threadId":"13951","inReplyTo":"200806151505.27686.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Documentation: Note about the meaning of \"clone\"","fromName":"Vaclav Hanzl","fromEmail":"hanzl@noel.feld.cvut.cz","sentAt":"2008-06-15T17:03:04Z","receivedAt":"2008-06-15T17:03:04Z","isPatch":true,"sender":{"key":"hanzl@noel.feld.cvut.cz","avatar":null},"body":"> +*NOTE*: Although this command is called clone, the clone is not identical\n> +in all respects. Local branches in the repository being cloned\n> +becomes remote tracking branches in the clone and remote tracking\n> +branches are not cloned at all. For security reasone the config sections\n> +and triggers are not cloned either.\n\nIn order to better specify what gets cloned and what does not, one\nmight also replace \"active branch\" (under DESCRIPTION) with \"current\nbranch\".\n\nAccording to grep in Documentation/*.txt, \"current branch\" is used\nmuch more often than \"active branch\". Most frequent use of term\n\"active branch\" is found in git-fast-import.txt and it seems to mean\nsomething else there.\n\n(The fact that tiny volatile detail - which branch happens to be\nchecked out at the moment of clone - has profound influence on the\nresult of clone was quite a surprise for me, so I would like to\nsee this described as exactly as possible.)\n\nRegards\n\nVaclav\n"},{"id":"79948","messageId":"20080615191208.GS29404@genesis.frugalware.org","threadId":"13951","inReplyTo":"200806151505.27686.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Documentation: Note about the meaning of \"clone\"","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-06-15T19:12:08Z","receivedAt":"2008-06-15T19:12:08Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sun, Jun 15, 2008 at 03:05:27PM +0200, Robin Rosenberg wrote:\n> +*NOTE*: Although this command is called clone, the clone is not identical\n> +in all respects. Local branches in the repository being cloned\n> +becomes remote tracking branches in the clone and remote tracking\n> +branches are not cloned at all. For security reasone the config sections\n> +and triggers are not cloned either.\n\ns/triggers/hooks/?\n"},{"id":"79952","messageId":"7vskvecv6d.fsf@gitster.siamese.dyndns.org","threadId":"13951","inReplyTo":"200806151505.27686.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Documentation: Note about the meaning of \"clone\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-15T20:14:34Z","receivedAt":"2008-06-15T20:14:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Rosenberg writes:\n\n> Clarify that a clone is not an exact copy.\n>\n> Signed-off-by: Robin Rosenberg \n> ---\n> Documentation/git-clone.txt | 7 ++++++-\n> 1 files changed, 6 insertions(+), 1 deletions(-)\n>\n> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n> index 7973e6a..c9bc627 100644\n> --- a/Documentation/git-clone.txt\n> +++ b/Documentation/git-clone.txt\n> @@ -31,7 +31,12 @@ This default configuration is achieved by creating references to\n> the remote branch heads under `$GIT_DIR/refs/remotes/origin` and\n> by initializing `remote.origin.url` and `remote.origin.fetch`\n> configuration variables.\n> -\n> ++\n> +*NOTE*: Although this command is called clone, the clone is not identical\n> +in all respects. Local branches in the repository being cloned\n> +becomes remote tracking branches in the clone and remote tracking\n> +branches are not cloned at all. For security reasone the config sections\n> +and triggers are not cloned either.\n\nThanks.\n\nBut the above will not lose any information content if \"Although... clone,\"\nis dropped. It in fact, dropping that would make it even clearer. \n\nSaying only \"beware that neither X nor Y nor Z is done\" leaves readers\nwondering \"why not\". Saying \"you may assume W but that is not the case\"\nis the same. How about expressing it a bit differently and in a more\npositive way? Documentation is not a place to express your frustration\nyou felt immediately after you found out that your initial assumption did\nnot match reality.\n\nAnd there is no triggers in git. If you are improving documentation,\nplease get your terminology straight.\n\nI think the first three paragraphs of this manual page need major\noverhaul. There were not much difference between bare and non-bare clone\nwhen historical layout was used, but exactly because a clone with a\nworking tree always use separate remotes layout, what they do is vastly\ndifferent these days.\n\nPoints to stress, and the order to present them, in the rewritten first\nparagraphs would be:\n\n - There are two different kind of clones. A bare one and non bare one.\n\n - A non-bare one is a way to prepare where you work in. It is assumed\n that you will want to keep updating the resulting repository from the\n source of the cloning operation from time to time, so 'origin' is set\n up for you automatically to track its branches in remotes/origin.\n\n - A bare one is a way to prepare where you push into so that others can\n fetch from it. IOW, it is a place people meet to exchange history, not\n a place where somebody actually works in to build history. It is\n expected that people will push into the resulting repository from\n elsewhere to update it, rather than somebody will fetch into it further\n from any 'origin'. No 'origin' is made, and branches are copied 1:1.\n\n - In either case, only the information from the originating repository\n that are designed to be shared are propagated. That includes branches\n and tags, but not things that are specific for working in the\n originating repository such as config, stash, hooks and remote tracking\n branches.\n"}]}