{"thread":{"id":"203","subject":"Pasky problem with 'git init URL'","startedAt":"2005-04-21T16:21:58Z","lastAt":"2005-04-22T12:44:45Z","messageCount":7,"participants":["Martin Schlemmer","Petr Baudis","John Stoffel","Fabian Franz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1140","messageId":"1114100518.17551.31.camel@nosferatu.lan","threadId":"203","inReplyTo":null,"subject":"Pasky problem with 'git init URL'","fromName":"Martin Schlemmer","fromEmail":"azarah@nosferatu.za.org","sentAt":"2005-04-21T16:21:58Z","receivedAt":"2005-04-21T16:21:58Z","isPatch":false,"sender":{"key":"azarah@nosferatu.za.org","avatar":null},"body":"Hi,\n\nJust pulled linux-2.6.git, and got this:\n\n----\nNew branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320\nTracked branch, applying changes...\nMerging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 -> 3a6fd752a50af92765853879f4a11cc0cfcd0320\n to a2755a80f40e5794ddc20e00f781af9d6320fafb...\n\nEnter commit message, terminated by ctrl-D on a separate line:\nMerge with 3a6fd752a50af92765853879f4a11cc0cfcd0320\n----\n\nWeird thing was that I made no changes.\n\nDigging a bit deeper, I saw that .git/HEAD was a symlink\nto .git/heads/master, and the tracked branch was 'origin'. Due to the\nfact that Linus only have a .git/heads/master on his rsync, and this\nthus updated to the new sha1, but the 'origin' (and tracked) head is\nstill pointing to an older sha1 caused this confusion.\n\nI replicated the linux tree via:\n\n----\ngit init URL\n----\n\nSo I had a look at gitinit.sh, which first creates the .git/heads/master\nand symlinks HEAD to it, then on seeing a URL was supplied, creates\na .git/heads/origin, track it, but do *not* change the .git/HEAD\nsymlink ... Is this intended? I see also that gittrack.sh do not update\nthe HEAD symlink ... Is this also intended?\n\nI guess a solution is to either just use 'master', and do not do the\n'origin' head, or to update the HEAD symlink. I however do not think\nthis is very generic, especially if the remote repo do not call their\nmain head 'master' - so it might be better to check what it have\nin .git/heads, and if only one, use that as the main and tracked head,\nelse do nothing and tell the user to decide what head to track, etc.\n\nThe last option however brings a problem or two. First, how do you do\nthe multi-head thing? Maybe add a command 'git lsheads' (and while at\nit, also add 'git lstags'?)? Secondly, if there was more than one head,\nthe local copy needs to be checked out ... don't know if 'git cancel' is\nthe logical thing the user will think to do ('git clone' perhaps?) ...\n\nI think it might be a good time to start thinking and putting to text\nwhat commands is really needed, what they should be called, and how\nexactly they should behave before it gets much later in the game.\n\nAnyhow, suggestions/comments welcome.\n\n\nThanks,\n\n-- \nMartin Schlemmer\n\n"},{"id":"1187","messageId":"20050421202928.GH7443@pasky.ji.cz","threadId":"203","inReplyTo":"1114100518.17551.31.camel@nosferatu.lan","subject":"Re: Pasky problem with 'git init URL'","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-21T20:29:28Z","receivedAt":"2005-04-21T20:29:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 21, 2005 at 06:21:58PM CEST, I got a letter\nwhere Martin Schlemmer told me that...\n> Hi,\n\nHi,\n\n> Just pulled linux-2.6.git, and got this:\n> \n> ----\n> New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320\n> Tracked branch, applying changes...\n> Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 -> 3a6fd752a50af92765853879f4a11cc0cfcd0320\n> to a2755a80f40e5794ddc20e00f781af9d6320fafb...\n> \n> Enter commit message, terminated by ctrl-D on a separate line:\n> Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320\n> ----\n> \n> Weird thing was that I made no changes.\n\ndid you compensate for the renamed hashes? Didn't you before update from\nsome very old git-pasky version?\n\nActually, did you do that git init _after_ the unsuccessful pull, or\nbefore?\n\n> Digging a bit deeper, I saw that .git/HEAD was a symlink\n> to .git/heads/master, and the tracked branch was 'origin'. Due to the\n> fact that Linus only have a .git/heads/master on his rsync, and this\n> thus updated to the new sha1, but the 'origin' (and tracked) head is\n> still pointing to an older sha1 caused this confusion.\n\nDuh. The remote branch always grabs the HEAD over there; you don't need\nto care about the various branches over there, and you really do not\n*want* to care. Actually I might add some ^branchname to the rsync URL,\nto be able to refer to particular branches inside of the repository.\n\n> I replicated the linux tree via:\n> \n> ----\n> git init URL\n> ----\n> \n> So I had a look at gitinit.sh, which first creates the .git/heads/master\n> and symlinks HEAD to it, then on seeing a URL was supplied, creates\n> a .git/heads/origin, track it, but do *not* change the .git/HEAD\n> symlink ... Is this intended? I see also that gittrack.sh do not update\n> the HEAD symlink ... Is this also intended?\n\nYes.\n\nYou never work directly on the remote branch. Ever. That's what this\ntracking stuff is for; you set up a local branch which follows the\nremote one.\n\nOtherwise, you fork to two trees, one is remote branch, second is local\nbranch, and you do git pull remotebranch in the second. You are in\ntrouble now. Also, if you do some local commit on the remote branch,\nwhat would happen? This kind of stuff is why I decided that you just\ncannot work on remote branches directly.\n\n> The last option however brings a problem or two. First, how do you do\n> the multi-head thing? Maybe add a command 'git lsheads' (and while at\n> it, also add 'git lstags'?)? Secondly, if there was more than one head,\n\nPerhaps it would be useful to have some \"command classes\" (with at least\ncg-*-(add|ls|rm)), like:\n\n\tcg-branch-ls\n\tcg-remote-rm\n\tcg-tag-add\n\n> the local copy needs to be checked out ... don't know if 'git cancel' is\n> the logical thing the user will think to do ('git clone' perhaps?) ...\n\nI don't know what do you mean here.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1194","messageId":"17000.6154.748117.967898@smtp.charter.net","threadId":"203","inReplyTo":"20050421202928.GH7443@pasky.ji.cz","subject":"Re: Pasky problem with 'git init URL'","fromName":"John Stoffel","fromEmail":"john@stoffel.org","sentAt":"2005-04-21T21:15:54Z","receivedAt":"2005-04-21T21:15:54Z","isPatch":false,"sender":{"key":"john@stoffel.org","avatar":null},"body":">>>>> \"Petr\" == Petr Baudis writes:\n\nPetr> Perhaps it would be useful to have some \"command classes\" (with at least\nPetr> cg-*-(add|ls|rm)), like:\n\nPetr> \tcg-branch-ls\nPetr> \tcg-remote-rm\nPetr> \tcg-tag-add\n\nJust speaking of consistency, can we make it so that all the commands\nare just variations with out the damm dashes in them? Something like:\n\n git lsbranch\n git lstag\n ...\n\nOr something mildly along those lines. I don't even care what ORDER\nthey are, whether the 'ls' comes before or after the object type it\nworks on. But make it the same every where, so that ls, rm, add,\ncheck, foo, barzle, ... all use the same format. \n\nMakes it much much easier to extrapolate what command syntax to use\nwhen new objects to be acted upon are added.\n\nDoes a standard like:\n\n git [ ...]\n\nmake sense? Easy to script, easy to remember. Even munging\n into a single word is ok.\n\nJohn\n"},{"id":"1193","messageId":"1114118223.29271.5.camel@nosferatu.lan","threadId":"203","inReplyTo":"20050421202928.GH7443@pasky.ji.cz","subject":"Re: Pasky problem with 'git init URL'","fromName":"Martin Schlemmer","fromEmail":"azarah@nosferatu.za.org","sentAt":"2005-04-21T21:17:03Z","receivedAt":"2005-04-21T21:17:03Z","isPatch":false,"sender":{"key":"azarah@nosferatu.za.org","avatar":null},"body":"On Thu, 2005-04-21 at 22:29 +0200, Petr Baudis wrote:\n> Dear diary, on Thu, Apr 21, 2005 at 06:21:58PM CEST, I got a letter\n> where Martin Schlemmer told me that...\n> > Hi,\n> \n> Hi,\n> \n> > Just pulled linux-2.6.git, and got this:\n> > \n> > ----\n> > New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320\n> > Tracked branch, applying changes...\n> > Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 -> 3a6fd752a50af92765853879f4a11cc0cfcd0320\n> > to a2755a80f40e5794ddc20e00f781af9d6320fafb...\n> > \n> > Enter commit message, terminated by ctrl-D on a separate line:\n> > Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320\n> > ----\n> > \n> > Weird thing was that I made no changes.\n> \n> did you compensate for the renamed hashes? Didn't you before update from\n> some very old git-pasky version?\n> \n> Actually, did you do that git init _after_ the unsuccessful pull, or\n> before?\n> \n\nI re-pulled it from scratch after the sha1 changes, so not that. Just\nthe next pull that went wonky.\n\n> > Digging a bit deeper, I saw that .git/HEAD was a symlink\n> > to .git/heads/master, and the tracked branch was 'origin'. Due to the\n> > fact that Linus only have a .git/heads/master on his rsync, and this\n> > thus updated to the new sha1, but the 'origin' (and tracked) head is\n> > still pointing to an older sha1 caused this confusion.\n> \n> Duh. The remote branch always grabs the HEAD over there; you don't need\n> to care about the various branches over there, and you really do not\n> *want* to care. Actually I might add some ^branchname to the rsync URL,\n> to be able to refer to particular branches inside of the repository.\n> \n\nWell, I just did a quick peek. I thought it just changed the local head\nto the sha1 of the remote, and then updated the local files - haven't\nyet looked at gitmerge.sh.\n\n> > I replicated the linux tree via:\n> > \n> > ----\n> > git init URL\n> > ----\n> > \n> > So I had a look at gitinit.sh, which first creates the .git/heads/master\n> > and symlinks HEAD to it, then on seeing a URL was supplied, creates\n> > a .git/heads/origin, track it, but do *not* change the .git/HEAD\n> > symlink ... Is this intended? I see also that gittrack.sh do not update\n> > the HEAD symlink ... Is this also intended?\n> \n> Yes.\n> \n> You never work directly on the remote branch. Ever. That's what this\n> tracking stuff is for; you set up a local branch which follows the\n> remote one.\n> \n\nOk, but for some weird reason it wanted to commit the merge between\nremote and local.\n\n> Otherwise, you fork to two trees, one is remote branch, second is local\n> branch, and you do git pull remotebranch in the second. You are in\n> trouble now. Also, if you do some local commit on the remote branch,\n> what would happen? This kind of stuff is why I decided that you just\n> cannot work on remote branches directly.\n> \n> > The last option however brings a problem or two. First, how do you do\n> > the multi-head thing? Maybe add a command 'git lsheads' (and while at\n> > it, also add 'git lstags'?)? Secondly, if there was more than one head,\n> \n> Perhaps it would be useful to have some \"command classes\" (with at least\n> cg-*-(add|ls|rm)), like:\n> \n> \tcg-branch-ls\n> \tcg-remote-rm\n> \tcg-tag-add\n> \n\nMight make things more sane.\n\n> > the local copy needs to be checked out ... don't know if 'git cancel' is\n> > the logical thing the user will think to do ('git clone' perhaps?) ...\n> \n> I don't know what do you mean here.\n> \n\nDon't worry, no biggy.\n\n-- \nMartin Schlemmer\n\n"},{"id":"1197","messageId":"20050421212648.GM7443@pasky.ji.cz","threadId":"203","inReplyTo":"17000.6154.748117.967898@smtp.charter.net","subject":"Re: Pasky problem with 'git init URL'","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-21T21:26:49Z","receivedAt":"2005-04-21T21:26:49Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 21, 2005 at 11:15:54PM CEST, I got a letter\nwhere John Stoffel told me that...\n> >>>>> \"Petr\" == Petr Baudis writes:\n> \n> Petr> Perhaps it would be useful to have some \"command classes\" (with at least\n> Petr> cg-*-(add|ls|rm)), like:\n> \n> Petr> \tcg-branch-ls\n> Petr> \tcg-remote-rm\n> Petr> \tcg-tag-add\n> \n> Does a standard like:\n> \n> git [ ...]\n\nIsn't this basically what I was proposing? (Modulo the UI changes\nrelated to git-pasky -> Cogito.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1202","messageId":"200504212357.48483.FabianFranz@gmx.de","threadId":"203","inReplyTo":"17000.6154.748117.967898@smtp.charter.net","subject":"Re: Pasky problem with 'git init URL'","fromName":"Fabian Franz","fromEmail":"fabianfranz@gmx.de","sentAt":"2005-04-21T21:57:45Z","receivedAt":"2005-04-21T21:57:45Z","isPatch":false,"sender":{"key":"fabianfranz@gmx.de","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAm Donnerstag, 21. April 2005 23:15 schrieb John Stoffel:\n> >>>>> \"Petr\" == Petr Baudis writes:\n>\n> Petr> Perhaps it would be useful to have some \"command classes\" (with at\n> least Petr> cg-*-(add|ls|rm)), like:\n>\n> Petr> \tcg-branch-ls\n> Petr> \tcg-remote-rm\n> Petr> \tcg-tag-add\n>\n> Just speaking of consistency, can we make it so that all the commands\n> are just variations with out the damm dashes in them? \n\nI think the dashes are especially useful, because of \"tab-completion\".\n\n> git [ ...]\n>\n\nI think thats exactly like above:\n\ncg--\n\ncu\n\nFabian\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.2.4 (GNU/Linux)\n\niD8DBQFCaCHbI0lSH7CXz7MRAuSXAJ40v4yNgS13BIExfYTwPv8zbj2HcACdG7G6\nYiLFD8u8Guh3xppaa14uD+I=\n=dkN/\n-----END PGP SIGNATURE-----\n\n"},{"id":"1263","messageId":"17000.61885.545203.936684@smtp.charter.net","threadId":"203","inReplyTo":"20050421212648.GM7443@pasky.ji.cz","subject":"Re: Pasky problem with 'git init URL'","fromName":"John Stoffel","fromEmail":"john@stoffel.org","sentAt":"2005-04-22T12:44:45Z","receivedAt":"2005-04-22T12:44:45Z","isPatch":false,"sender":{"key":"john@stoffel.org","avatar":null},"body":"\nPetr> Dear diary, on Thu, Apr 21, 2005 at 11:15:54PM CEST, I got a letter\nPetr> where John Stoffel told me that...\n>> >>>>> \"Petr\" == Petr Baudis writes:\n>> \nPetr> Perhaps it would be useful to have some \"command classes\" (with at least\nPetr> cg-*-(add|ls|rm)), like:\n>> \nPetr> cg-branch-ls\nPetr> cg-remote-rm\nPetr> cg-tag-add\n>> \n>> Does a standard like:\n>> \n>> git [ ...]\n\nPetr> Isn't this basically what I was proposing? (Modulo the UI\nPetr> changes related to git-pasky -> Cogito.)\n\nI'm not quite upto speed on git, I was away on vacation when the list\nstarted up and didn't catch it until just recently... \n\nAnd it is close to what you were proposing, but instead of dashes (-)\nbetween the command and the object, I'm proposing just a space.\nActually, I'm proposing that we decide on a grammar and it's syntax\nand to try and make it orthagonal and consistent. Principal of least\nsurprises, etc.\n\nThanks,\nJohn\n"}]}