{"thread":{"id":"6437","subject":"Decoding git show-branch output","startedAt":"2007-01-19T13:12:35Z","lastAt":"2007-01-19T22:26:50Z","messageCount":5,"participants":["Bill Lear","Santi Béjar","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"32066","messageId":"17840.50115.999227.260259@lisa.zopyra.com","threadId":"6437","inReplyTo":null,"subject":"Decoding git show-branch output","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-19T13:12:35Z","receivedAt":"2007-01-19T13:12:35Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"If this is an inappropriate forum for this question, please let me know\nand I will redirect it elsewhere.\n\nWe have converted from cvs to git recently and one of our developers\nseems to have made a terrific mess of things.\n\nHe is seeing \"fatal: protocol error: bad line length character\" when\npushing from a one of his work repositories to our main company\nrepository.  He is seeing his git merges vanish (he can't find his\ncode where he thinks it should be) and is apparently having trouble\ndoing things we thought should be very simple.  Personally, I have\nhad little trouble with git, but now I'm trying to figure out what\nit was he has done to get himself in this mess.\n\nWe are running the latest git 1.4.4.1, under Linux (a few flavors,\nCentos 4.3, Redhat 4, etc.).  Our company repository is on Fedora Core\n6.\n\nI thought I would use git-show-branch to try to unravel some of this\nmystery.\n\nAfter doing several commits, our company repository looks like this:\n\n% GIT_DIR=fus git-show-branch --more=20 --topo-order\n[master] Merge branch 'master' of source:/repos/git/fus\n[master^2] Add more timing of Tbar components.\n[master^2^] Add more timing of Tbar components.\n[master^] Tell git to ignore more stuff.\n[master~2] fix to pass on gcc\n[master~3] Merge branch 'master' of ssh+git://source/repos/git/fus\n[master~3^2] Merge branch 'master' of source:/repos/git/fus\n[master~3^2^2] placeholders for 1.0 release\n[master~3^2^] recursive_binomial branch merged to master.\n[master~3^2~2] More Tbar timing statistics.\n[master~4] with this you will be able to do help on any command\n[master~5] help for commands\n[master~6] add echo to try and track down intermittent failure\n[master~7] fix stupid typo\n[master~8] fix stupid error\n[master~9] add removal of files to prevent affecting future test runs\n[master~10] Merge branch 'master' of ssh+git://source/repos/git/fus\n[master~10^2] Merge branch 'master' of ssh+git://source/repos/git/fus\n[master~10^2^] update to report output when gen_run.tcl fails\n[master~11] Merge branch 'master' of ssh+git://source/repos/git/fus\n[master~10^2^2] Integer type fixups to suppress warnings.\n\nI'm very confused by the syntax above.  What does \"[master^2^]\" mean?\nDitto with things like \"[master~3^2^2]\" and \"[master~3^2~2]\".  Why\nis the order \n\n[master]\n[master^2]\n[master^2^]\n[master^]\n\n?  I would have thought [master] would be followed by [master^], not\n[master^2].  Obviously I'm confused.\n\nI have read the May 2006 article in Linux Magazine, \"Embrace The Git\nIndex\" by Jon Loeliger, and tried to make sense of the \"HOW TO READ\nCOMMIT SHORT-HAND NAMES\" box on the sixth page, but can't seem to.\n\nI'm used to visual representations that show things in chronological order,\nfrom left to right, say as\n\n                                   H---I---J  second\n                                  /\n                         E---F---G---K---L  first\n                        /\n                       /       O---P---Q  third\n                      /       /\n         A---B---C---D---M---N  master\n\nor:\n\n                                   H---I---J  second\n                                  /         \\\n                         E---F---G---K---L---R  first\n                        /                     \\\n                       /       O---P---Q  third \\\n                      /       /         \\         \\\n         A---B---C---D---M---N-----------S---------T  master\n\n(third merged onto master, second onto first, first onto master)\n\nBut I can't seem to make the mental leap to map the show-branch output\nto something I understand such as the above.\n\nSo, If someone could help me grok this, I'd appreciate it.\n\nAgain, apologies if this is not the appropriate forum.\n\n\nBill\n"},{"id":"32067","messageId":"8aa486160701190613j6493daccofc259a8b17c0f1d1@mail.gmail.com","threadId":"6437","inReplyTo":"17840.50115.999227.260259@lisa.zopyra.com","subject":"Re: Decoding git show-branch output","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-01-19T14:13:30Z","receivedAt":"2007-01-19T14:13:30Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 1/19/07, Bill Lear <rael@zopyra.com> wrote:\n\n[...]\n\n> I'm very confused by the syntax above.  What does \"[master^2^]\" mean?\n> Ditto with things like \"[master~3^2^2]\" and \"[master~3^2~2]\".\n\nThey explain the relation between commits:\n\n^ -> first parent\n^n -> n-th parent\n~n -> <n>th generation parent, following only the first parent.\n\nSee the manual page of git-rev-parse (or the tutorial for some simple examples).\n\n>  Why is the order\n>\n> [master]\n> [master^2]\n> [master^2^]\n> [master^]\n>\n> ?  I would have thought [master] would be followed by [master^], not\n> [master^2].  Obviously I'm confused.\n\nThe order of the parents is not important.\n\n> I'm used to visual representations that show things in chronological order,\n> from left to right, say as\n>\n>                                    H---I---J  second\n>                                   /\n>                          E---F---G---K---L  first\n>                         /\n>                        /       O---P---Q  third\n>                       /       /\n>          A---B---C---D---M---N  master\n>\n> or:\n>\n>                                    H---I---J  second\n>                                   /         \\\n>                          E---F---G---K---L---R  first\n>                         /                     \\\n>                        /       O---P---Q  third \\\n>                       /       /         \\         \\\n>          A---B---C---D---M---N-----------S---------T  master\n>\n> (third merged onto master, second onto first, first onto master)\n>\n\nThen, use gitk to visualize the graph.\n\n> Again, apologies if this is not the appropriate forum.\n\nYour are welcome.\n\nSanti\n"},{"id":"32085","messageId":"17841.13791.627478.602602@lisa.zopyra.com","threadId":"6437","inReplyTo":"8aa486160701190613j6493daccofc259a8b17c0f1d1@mail.gmail.com","subject":"Re: Decoding git show-branch output","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-19T21:19:27Z","receivedAt":"2007-01-19T21:19:27Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Friday, January 19, 2007 at 15:13:30 (+0100) Santi Béjar writes:\n>On 1/19/07, Bill Lear <rael@zopyra.com> wrote:\n>\n>[...]\n>\n>> I'm very confused by the syntax above.  What does \"[master^2^]\" mean?\n>> Ditto with things like \"[master~3^2^2]\" and \"[master~3^2~2]\".\n>\n>They explain the relation between commits:\n>\n>^ -> first parent\n>^n -> n-th parent\n>~n -> <n>th generation parent, following only the first parent.\n>\n>See the manual page of git-rev-parse (or the tutorial for some simple examples).\n\nI did.  Still don't understand.  So, following your explanation,\n\nmaster~3 ^2 ~2\n\nMeans the 2nd (first generation) parent of the second parent of the\n3rd (first generation) parent?  Is there a way to simply state this in\nplain words, say in terms of commits/merges?  I'm unsure how to\ninterpret the above, especially since none of us has been developing\non a branch (I see no other branch names except master, also).\n\nI'm currently running qgit/gitk to try to figure this all out.  It\nappears that somehow we generated way more branches than we thought we\nwere.\n\nOur basic work-flow for a developer is to set up one or more \"private\"\nrepositories on our machines, by issuing a git-clone of our company repo.\n\nThen we set up a \"public\" repo on our machine by issuing a \"git --bare\ninit-db --shared\".  We then push into this repo when ready, and from\nthere other developers pull.\n\nThen, it seems that we push to our company repository both from our\nprivate repos and our public ones, as we see fit.\n\nI'm not sure if this is sane: is it ok to clone the company repo,\nthen push from that clone into a bare repo, then from there to\nthe company one?  Is git doing some sort of weird, silent pseudo-merge\nthat we don't understand, thus generated what appears to be a very\ntangled, albeit brief, history, when we examine it?\n\nI have read about 8 documents on git, experimented with it\nextensively, and, at our company, I am arguably the \"git expert\"; I\nthought that I had done all of my work on my local repo's master\nbranch, and only pushed from that branch up to our company repo.  Yet,\nqgit shows that one of my first commits (to fix a few simply typos in\ndocumentation) goes off onto another branch.  git-show-branch shows\n\"[master~3^2~9] Fix a few typos\" for this.  I'm very confused how this\ncould have happened, and I want to ensure we are doing things in a way\nthat is predictable...\n\nThank you again.\n\n\nBill\n"},{"id":"32090","messageId":"eorg06$f1o$1@sea.gmane.org","threadId":"6437","inReplyTo":"17841.13791.627478.602602@lisa.zopyra.com","subject":"Re: Decoding git show-branch output","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-19T22:17:19Z","receivedAt":"2007-01-19T22:17:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: git@vger.kernel.org]\n\nBill Lear wrote:\n\n> I'm not sure if this is sane: is it ok to clone the company repo,\n> then push from that clone into a bare repo, then from there to\n> the company one?  Is git doing some sort of weird, silent pseudo-merge\n> that we don't understand, thus generated what appears to be a very\n> tangled, albeit brief, history, when we examine it?\n\nIt is quite sane, I think, to use bare repositories as \"gateways\".\n \n> I have read about 8 documents on git, experimented with it\n> extensively, and, at our company, I am arguably the \"git expert\"; I\n> thought that I had done all of my work on my local repo's master\n> branch, and only pushed from that branch up to our company repo.  Yet,\n> qgit shows that one of my first commits (to fix a few simply typos in\n> documentation) goes off onto another branch.  git-show-branch shows\n> \"[master~3^2~9] Fix a few typos\" for this.  I'm very confused how this\n> could have happened, and I want to ensure we are doing things in a way\n> that is predictable...\n\nNether push nor fetch does do merges. What can do merges (if not in\nfast-forward case, i.e. in case where only one side did any changes), is\npull (but it doesn;t do this silently). I suspect that pulling from\ndifferent repositories (probably into different tracking branches, or\nwithout use of tracking branches) might be the culprit.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32095","messageId":"7v64b2fyad.fsf@assigned-by-dhcp.cox.net","threadId":"6437","inReplyTo":"17841.13791.627478.602602@lisa.zopyra.com","subject":"Re: Decoding git show-branch output","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-19T22:26:50Z","receivedAt":"2007-01-19T22:26:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bill Lear <rael@zopyra.com> writes:\n\n> master~3 ^2 ~2\n>\n> Means the 2nd (first generation) parent of the second parent of the\n> 3rd (first generation) parent?  Is there a way to simply state this in\n> plain words, say in terms of commits/merges?\n\nYou had one commit (master~3^2~2).  You built one commit on top\nof it (master~3^2~1) and another (master~3^2).\n\nThat one was merged into something else as the second parent,\nand the merge result is master~3 (that \"something else\" is\nmaster~4 aka master~3^ aka master~3^1).\n\nYou built three commits on top of that, and that is where your\nmaster currently is.\n\n> I'm unsure how to\n> interpret the above, especially since none of us has been developing\n> on a branch (I see no other branch names except master, also).\n\nBut you are.  Each repository are independent and the branches\nyour developers have, even though each of them have only one,\nare separate branches.  You are exercising the distributedness\nof git development model.\n\n> I'm not sure if this is sane: is it ok to clone the company repo,\n> then push from that clone into a bare repo, then from there to\n> the company one?\n\nThat's essentially everybody doing distributed development does\nin git land -- it is very sane.\n\n> Is git doing some sort of weird, silent pseudo-merge\n> that we don't understand, thus generated what appears to be a very\n> tangled, albeit brief, history, when we examine it?\n\nI do not think so, but the person creating a commit may first be\npulling from the central location, which needs a merge and\nresults in one.  That's very common in centralized workflow\nmodelled after how CVS is used.\n\nLet's say you have the central (perhaps bare but it does not\nmatter if it is bare or not) repository and two workers, Alice\nand Bob.  They both clone from it and make one commit each in\ntheir repositories.  The commit ancestries in the entire world\nwould look like this:\n\n          .---o Alice's 'master'\n         /\n ---o---o-------o Bob's 'master'\n        ^\n        central repo's 'master'\n\nThen Bob pushes to the central repo.  Since it is a\nfast-forward, his push is accpeted and the picture would become\nlike this:\n\n          .---o Alice's 'master'\n         /\n ---o---o-------o Bob's 'master'\n                ^\n                central repo's 'master'\n\nWhen Alice wants to push her changes back to the central repo,\nit is not a fast-forward and is refused.  We currently suggest\nAlice to first pull from the central repo (this is how CVS is\nused -- you try \"cvs commit\" and get complaints, then you say\n\"cvs update\" and retry).\n\nWhat happens is that in Alice's repository, if Bob's change and\nAlice's change does not conflict, this \"pull\" creates a merge\ncommit.\n\n          .---o---o Alice's 'master'\n         /       /\n ---o---o-------o Bob's 'master'\n                ^\n                central repo's 'master'\n\nThen Alice can push out her changes.\n\n          .---o---o Alice's 'master' == central repo's 'master'\n         /       /\n ---o---o-------o Bob's 'master'\n                \nIf Bob pulls from the central repo at this point, it will also\nfast-forward and these three repositories end up with\n\n\n          .---o---o Alice's 'master' == central repo's 'master'\n         /       /  == Bob's 'master'\n ---o---o-------o\n\nOne thing you _could_ do is to train your users to rebase after\npush fails, if you do not want these merges.\n\nAfter her push fails here...\n\n          .---o Alice's 'master'\n         /\n ---o---o-------o Bob's 'master'\n                ^\n                central repo's 'master'\n\nAlice could rebase by:\n\n\t$ git fetch\n\t$ git rebase origin\n\nThe first \"git fetch\" (if Alice is using the default\nconfiguration created by recent \"git clone\") fetches from the\ncentral repo and stores the 'master' branch at the central repo\nas her tracking branch (.git/refs/remotes/origin/master).  This\ncan be referenced on the command line as 'origin' (again, if\nAlice is using the default configuration created by recent \"git\nclone\").  What these commands do is:\n\n(1) git-fetch makes central repo's 'master' locally available to\n    Alice as 'origin'\n\n          .---o Alice's 'master'\n         /\n ---o---o-------o Bob's 'master'\n                ^\n                central repo's 'master' == Alice's 'origin'\n\n(2) git-rebase forward ports the commits on Alice's 'master'\n    since it forked from the central repo, and creates this\n    graph:\n\n\n                  .---o Alice's 'master', updated\n                 /\n ---o---o-------o Bob's 'master'\n                ^\n                central repo's 'master' == Alice's 'origin'\n\nAfter these, 'master' in Alice's repository is a fast-forward\nand she can now push to update the central repository.\n\nIt would be usually a good idea to rebase if Alice's work is\ntrivial since she synchronized with the central repository the\nlast time.  If it is a very involved changes, however, it often\nis not worth worrying about keeping merges out of the history.\nYour developers _are_ working in parallel and there is not much\npoint in insisting to lineralize the history too much.\n"}]}