{"thread":{"id":"1177","subject":"Bootstrapping into git, commit gripes at me","startedAt":"2005-07-08T23:07:50Z","lastAt":"2005-08-12T01:26:10Z","messageCount":33,"participants":["Marc Singer","Junio C Hamano","Linus Torvalds","Matthias Urlichs","Petr Baudis","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5836","messageId":"20050708230750.GA23847@buici.com","threadId":"1177","inReplyTo":null,"subject":"Bootstrapping into git, commit gripes at me","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-08T23:07:50Z","receivedAt":"2005-07-08T23:07:50Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"In working through a usage example on my way to producing bonafide\npatches, I've found that commit is complaining. Here's what I've done.\n\n o Fetched and built cogito-0.12\n o Fetched (rsync) Linus' tree\n o Created a working directory, linux-2.6\n o linked .git in the working directory to the .git directory fetched\n from the net.\n o # git checkout -f v2.6.11\n o # cat ../old-patch-file | patch -p1\n\nThen, according to Jeff's instructions, I have to perform\nget-update-cache with the name of each file I changed. Is that really\nthe way?\n\n o # git-update-cache LIST_OF_CHANGED_FILES\n\nNow I commit.\n\n o # git commit\n\nI am presented with an editor session with the list of changed files\nalready present. IfI add a comment and leave the editor, I'm told\n\n fatal: 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is not a valid 'commit' object\n\nIf I don't edit the comment, it doesn't give an error but I don't\nthink the changes are committed because I can invoke git commit again.\n\nAm I off track?\n\nCheers.\n\nP.S. vger isn't letting me subscribe ATM. Please copy me with\n replies.\n"},{"id":"5841","messageId":"20050709011119.GA10981@buici.com","threadId":"1177","inReplyTo":"7v4qb46dff.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-09T01:11:19Z","receivedAt":"2005-07-09T01:11:19Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"> $ git checkout -f v2.6.11 ;# fixed one\n> warning: v2.6.11 is not a commit -- not updating your HEAD\n> $ git commit ;# to have his own baseline at v2.6.11\n> $ git-apply --index --stat --summary --apply <../old-patch-file\n> $ : do the usual tests\n> $ git commit ;# create a commit based on the baseline v2.6.11\n\nInteresting note. I tried the git-apply command and found that it\ncomplained and wouldn't succeed.\n\n elf@florence ~...embedded/linux-2.6 > git-apply --index --stat --summary --apply < ../ms16/ide.patch \n error: patch failed: drivers/ide/ide-io.c:129\n error: drivers/ide/ide-io.c: patch does not apply\n\nYet, patch does apply.\n\n elf@florence ~...embedded/linux-2.6 > patch -p1 < ../ms16/ide.patch\n patching file drivers/ide/arm/ide_arm.c\n patching file drivers/ide/arm/ide-lpd7952x.c\n patching file drivers/ide/arm/ide-lpd7a40x.c\n patching file drivers/ide/arm/Makefile\n patching file drivers/ide/ide-disk.c\n Hunk #1 succeeded at 282 (offset 41 lines).\n Hunk #2 succeeded at 294 (offset 41 lines).\n patching file drivers/ide/ide-io.c\n Hunk #1 succeeded at 96 with fuzz 2 (offset -33 lines).\n Hunk #2 succeeded at 1227 (offset 189 lines).\n Hunk #3 succeeded at 1388 (offset 189 lines).\n Hunk #4 succeeded at 1689 (offset 187 lines).\n patching file drivers/ide/ide-iops.c\n patching file drivers/ide/ide-probe.c\n Hunk #1 succeeded at 422 (offset 51 lines).\n Hunk #2 succeeded at 784 (offset 59 lines).\n Hunk #3 succeeded at 847 (offset 59 lines).\n Hunk #4 succeeded at 1112 (offset 64 lines).\n Hunk #5 succeeded at 1172 (offset 64 lines).\n patching file drivers/ide/Kconfig\n Hunk #1 succeeded at 272 (offset -1 lines).\n Hunk #2 succeeded at 781 (offset 5 lines).\n patching file drivers/ide/legacy/ht6560b.c\n patching file drivers/ide/legacy/qd65xx.c\n patching file drivers/ide/pci/ns87415.c\n patching file drivers/ide/pci/sl82c105.c\n patching file drivers/ide/pci/trm290.c\n patching file drivers/ide/ppc/pmac.c\n Hunk #1 succeeded at 572 (offset 61 lines).\n Hunk #2 succeeded at 596 (offset 61 lines).\n patching file include/linux/ide.h\n Hunk #1 succeeded at 961 (offset 1 line).\n Hunk #2 succeeded at 1497 (offset -14 lines).\n\nIt should be obvious that a patch that doesn't apply cleanly,\ni.e. without rejects, is still useful to apply so that I can fix the\nplaces where it fails.\n\n o Why does patch work and git-apply fail?\n o Is there a way to force git to apply and safe the rejects?\n"},{"id":"5842","messageId":"20050709011628.GA11253@buici.com","threadId":"1177","inReplyTo":"7v1x684wgr.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-09T01:16:28Z","receivedAt":"2005-07-09T01:16:28Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"On Fri, Jul 08, 2005 at 06:08:52PM -0700, Junio C Hamano wrote:\n> >>>>> \"MS\" == Marc Singer writes:\n> \n> MS> Does this preclude symlinking .git? I'd like to keep one .git which\n> MS> is mirrored from the net and allow for more than one working\n> MS> directory.\n> \n> I think people typically do this by symlinking .git/objects, not\n> .git/ itself.\n> \n> Presumably the reason you would want to have more than one\n> working tree is so that you can keep more than one topic of\n> development, one for each working tree, and make commits\n> independently, right? Which commit is the latest in each work\n> tree is, unsurprisingly, stored in .git/refs/heads/master file\n> in each work tree, so usually you would _not_ want to share\n> things other than .git/objects/ under .git/ directory across\n> work trees.\n> \n> One major downside of this, which I was burned once myself\n> (which is the reason for me to stop doing it), is that\n> git-fsck-cache and git-prune-script would not know anything\n> about the objects in the shared .git/objects reachable from\n> other work trees, and can happily garbage collect objects\n> necessary for other work trees.\n\nHmm. Seems, then, that this precludes any sharing at all. It isn't\nso serious with git as it was wth BK. The latter being disk hungry.\n\nI gather that the approved solution is to have complete replicas of\nthe git master from Linus for each line of development.\n"},{"id":"5845","messageId":"7vwto03gvb.fsf@assigned-by-dhcp.cox.net","threadId":"1177","inReplyTo":"20050709011628.GA11253@buici.com","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-09T01:31:04Z","receivedAt":"2005-07-09T01:31:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"MS\" == Marc Singer writes:\n\nMS> I gather that the approved solution is to have complete replicas of\nMS> the git master from Linus for each line of development.\n\nEither symlink .git/objects together, or GIT_OBJECT_DIRECTORY\nenvironment variable point at a shared repository, and just do\nnot run git-prune-script and you will be fine.\n"},{"id":"5848","messageId":"Pine.LNX.4.58.0507081842550.17536@g5.osdl.org","threadId":"1177","inReplyTo":"20050708230750.GA23847@buici.com","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-09T01:43:54Z","receivedAt":"2005-07-09T01:43:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 8 Jul 2005, Marc Singer wrote:\n>\n> In working through a usage example on my way to producing bonafide\n> patches, I've found that commit is complaining. Here's what I've done.\n> \n> o Fetched and built cogito-0.12\n> o Fetched (rsync) Linus' tree\n> o Created a working directory, linux-2.6\n> o linked .git in the working directory to the .git directory fetched\n> from the net.\n> o # git checkout -f v2.6.11\n\nThis won't work.\n\nv2.6.11 isn't a commit, it's a tree, and things will go downhill from \nthere. \n\nCan you base it on 2.6.12-rc2 or later? That's the earliest with some real \ngit history.\n\n\t\tLinus\n"},{"id":"5873","messageId":"pan.2005.07.09.21.04.29.263374@smurf.noris.de","threadId":"1177","inReplyTo":"20050709011119.GA10981@buici.com","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-09T21:04:37Z","receivedAt":"2005-07-09T21:04:37Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Marc Singer wrote:\n\n> Yet, patch does apply. [...]\n> patching file drivers/ide/ide-io.c\n> Hunk #1 succeeded at 96 with fuzz 2 (offset -33 lines).\n\ngit-apply cowardly (but sensibly) refuses to apply patches with fuzz\n(i.e., ignoring some supplied context lines). \n\nFuzz indicates problems.\n\nI'd suggest that you apply the patch to whatever version it is based on...\n\n> o Is there a way to force git to apply and safe the rejects?\n\nWell, you can use \"patch -p1 ...\" directly, and manually add the files it\ncreated to the object cache. Personally I wouldn't, if at all possible.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nI couldn't remember things until I took that Sam Carnegie course.\n\t\t-- Bill Peterson, former Houston Oiler football coach\n"},{"id":"5893","messageId":"20050710150609.GC24249@pasky.ji.cz","threadId":"1177","inReplyTo":"pan.2005.07.09.21.04.29.263374@smurf.noris.de","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-10T15:06:09Z","receivedAt":"2005-07-10T15:06:09Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 09, 2005 at 11:04:37PM CEST, I got a letter\nwhere Matthias Urlichs told me that...\n> > o Is there a way to force git to apply and safe the rejects?\n> \n> Well, you can use \"patch -p1 ...\" directly, and manually add the files it\n> created to the object cache. Personally I wouldn't, if at all possible.\n\nOr you can do cg-patch, which should handle that for you properly as\nwell. I think the \"no fuzz\" approach is hyper-paranoid. I deal with\nsmall or larger fuzz all the time when I'm reordering patches or\napplying them to a few hours younger version than they were based on. I\nthink the restriction it imposes is overly draconian here and doesn't\ntrust the developer to know what he is doing as much as it should. (And\nthat's why cg-patch doesn't use git-apply. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5974","messageId":"20050711222046.GA21376@buici.com","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507081842550.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-11T22:20:46Z","receivedAt":"2005-07-11T22:20:46Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"On Fri, Jul 08, 2005 at 06:43:54PM -0700, Linus Torvalds wrote:\n> \n> \n> On Fri, 8 Jul 2005, Marc Singer wrote:\n> >\n> > In working through a usage example on my way to producing bonafide\n> > patches, I've found that commit is complaining. Here's what I've done.\n> > \n> > o Fetched and built cogito-0.12\n> > o Fetched (rsync) Linus' tree\n> > o Created a working directory, linux-2.6\n> > o linked .git in the working directory to the .git directory fetched\n> > from the net.\n> > o # git checkout -f v2.6.11\n> \n> This won't work.\n> \n> v2.6.11 isn't a commit, it's a tree, and things will go downhill from \n> there. \n> \n> Can you base it on 2.6.12-rc2 or later? That's the earliest with some real \n> git history.\n\nI picked 2.6.12\n\n # git checkout -f v2.6.12\n\napplied the patch and was greeted with an error about being unable to\ncommit telling me that I LONG_HEX_NUMBER is not a valid commit object.\nIsn't 2.6.12 later than 2.6.12-rcX?\n"},{"id":"5976","messageId":"7vll4dndwu.fsf@assigned-by-dhcp.cox.net","threadId":"1177","inReplyTo":"20050711222046.GA21376@buici.com","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-11T23:03:45Z","receivedAt":"2005-07-11T23:03:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Singer writes:\n\n> I picked 2.6.12\n>\n> # git checkout -f v2.6.12\n>\n> applied the patch and was greeted with an error about being unable to\n> commit telling me that I LONG_HEX_NUMBER is not a valid commit object.\n> Isn't 2.6.12 later than 2.6.12-rcX?\n\nAha. Marc is not doing anything wrong --- he is doing as he is\ntold.\n\nLinus, there is a bad interaction between tag objects and\ncommits right now. For example:\n\n - we allow git-checkout-script with a tag; I think we store the tag\n object without dereferencing in .git/HEAD;\n\n - git-commit-tree says check_valid(\"commit\") and barfs.\n\nI think other things are covered already and the above two are\nthe only remaining major ones. The merge-base command dereferences tags\nand produces a commit as its result. The rev-list command also\nderefs tags, so log and whatchanged would work sensibly.\n\nMy current preference is to keep .git/refs/heads tag free. At\nleast, I do not think we should ever write non commits to\n.git/*_HEAD.\n\nWhat do you think? An alternative would be to allow tags\n(recursively) pointing at a commit as a commit parent, but I do\nnot think we would want to go that route.\n"},{"id":"5977","messageId":"7v8y0dndd8.fsf@assigned-by-dhcp.cox.net","threadId":"1177","inReplyTo":"7vll4dndwu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-11T23:15:31Z","receivedAt":"2005-07-11T23:15:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>\n> - git-commit-tree says check_valid(\"commit\") and barfs.\n>\n> My current preference is to keep .git/refs/heads tag free. At\n> least, I do not think we should ever write non commits to\n> .git/*_HEAD.\n>\n> What do you think? An alternative would be to allow tags\n> (recursively) pointing at a commit as a commit parent, but I do\n> not think we would want to go that route.\n\nOr, just dereferencing tags for commit parents in commit-tree\nwould be fine as well.\n\n------------\nDereference tags given as commit-tree -p parameters.\n\nMarc Singer noticed that when he has a tag instead of a commit\nin his .git/HEAD (this happens after git checkout -f ), git\ncommit barfs. This patch makes commit-tree dereference tags\nlike everybody else does.\n\nSigned-off-by: Junio C Hamano \n---\n\ncd /opt/packrat/playpen/public/in-place/git/git.junio/\njit-diff\n# - master: [PATCH] git-cvsimport-script: add \"import only\" option\n# + (working tree)\ndiff --git a/commit-tree.c b/commit-tree.c\n--- a/commit-tree.c\n+++ b/commit-tree.c\n@@ -8,6 +8,7 @@\n #include \n #include \n #include \n+#include \"commit.h\"\n \n #define BLOCKING (1ul << 14)\n \n@@ -133,10 +134,14 @@ int main(int argc, char **argv)\n \tcheck_valid(tree_sha1, \"tree\");\n \tfor (i = 2; i < argc; i += 2) {\n \t\tchar *a, *b;\n+\t\tstruct commit *commit;\n \t\ta = argv[i]; b = argv[i+1];\n \t\tif (!b || strcmp(a, \"-p\") || get_sha1(b, parent_sha1[parents]))\n \t\t\tusage(commit_tree_usage);\n-\t\tcheck_valid(parent_sha1[parents], \"commit\");\n+\t\tcommit = lookup_commit_reference(parent_sha1[parents]);\n+\t\tif (!commit)\n+\t\t\tusage(commit_tree_usage);\n+\t\tmemcpy(parent_sha1[parents], commit->object.sha1, 20);\n \t\tif (new_parent(parents))\n \t\t\tparents++;\n \t}\n\nCompilation finished at Mon Jul 11 16:12:36\n"},{"id":"5980","messageId":"Pine.LNX.4.58.0507111636030.17536@g5.osdl.org","threadId":"1177","inReplyTo":"20050711222046.GA21376@buici.com","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-11T23:45:22Z","receivedAt":"2005-07-11T23:45:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Marc Singer wrote:\n> \n> I picked 2.6.12\n> \n> # git checkout -f v2.6.12\n> \n> applied the patch and was greeted with an error about being unable to\n> commit telling me that I LONG_HEX_NUMBER is not a valid commit object.\n> Isn't 2.6.12 later than 2.6.12-rcX?\n\nYes.\n\nHowever, that's not how \"git checkout\" ends up working, which is probably \n(almost certainly) a misfeature of git checkout. In particular, when you \nuse a tag to checkout something, it will checkout the _state_ at that \npoint (ie v2.6.12), but it won't have reset your HEAD to point to it.\n\nAnd your earlier adventures made your HEAD be something that isn't a\ncommit (although I quite frankly don't know quite how you succeeded at\nthat: \"git checkout\" should refuse to write a HEAD unless you check out a\nspecific branch, and all branch pointers are proper commit points).\n\nAnyway, here's how you fix it right now, and I'll have to figure out how \nto make a nice interface:\n\n\t#\n\t# Reset the \"master\" branch to v2.6.12\n\t#\n\tgit-rev-list --max-count=1 v2.6.12 > .git/refs/heads/master\n\n\t#\n\t# Switch to the master branch\n\t#\n\tgit checkout -f master\n\nwhich should get you to be at a known point (which is v2.6.12).\n\n\t\tLinus\n"},{"id":"5995","messageId":"Pine.LNX.4.58.0507111646000.17536@g5.osdl.org","threadId":"1177","inReplyTo":"7vll4dndwu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T00:57:54Z","receivedAt":"2005-07-12T00:57:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Junio C Hamano wrote:\n> \n> - we allow git-checkout-script with a tag; I think we store the tag\n> object without dereferencing in .git/HEAD;\n\nNo, git-checkout-script _shouldn't_ have done that. It will do the \nread-tree on the tag (which will do the right thing), but it won't change \nthe HEAD itself.\n\nBut I think Marc has/had an older git-checkout-script. The original one\ndidn't do branches at all, and indeed just blindly wrote its result into\n.git/HEAD.\n\n> My current preference is to keep .git/refs/heads tag free. At\n> least, I do not think we should ever write non commits to\n> .git/*_HEAD.\n\nAnd we don't. Not any more. \n\nHowever, right now we don't update .git/HEAD at _all_ unless we checked \nout a specific branch. Part of that is that we don't really know what we \nshould change. Should we reset the current branch to that tag? Should we \nswitch to the \"master\" branch, and switch _that_ to that tag? Should we \ncreate a totally new branch for just this thing?\n\nCreating a new branch ends up being the only _safe_ option, but what \nshould we choose as the branch name? \n\n\t\tLinus\n"},{"id":"295839","messageId":"Pine.LNX.4.58.0507111833380.17536@g5.osdl.org","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507111646000.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T01:43:23Z","receivedAt":"2005-07-12T01:43:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Linus Torvalds wrote:\n>\n> No, git-checkout-script _shouldn't_ have done that. It will do the \n> read-tree on the tag (which will do the right thing), but it won't change \n> the HEAD itself.\n\nIn preparation of actually updating the HEAD, I just made \"git checkout\" \nverify that it only checks out a commit, not a tree tag or something like \nthat. Too late for Marc, but next time around a \"git checkout v2.6.11\" \nwill result in\n\n\t[torvalds@g5 linux]$ git checkout v2.6.11\n\terror: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit\n\tNeeded a single revision\n\nThat's not exactly _obvious_ either, but hey, it's at least a half-way\nreadable and understandable error, and it's obviously correct to somebody\nwho knows how git works.\n\nThat still leaves the question about what to do when you do\n\n\tgit checkout v2.6.12\n\nwhich _is_ a valid operation. Right now it will \"check out\" that tag, in \nthe sense that it will make the working tree correspond to v2.6.12, but it \nwon't actually touch HEAD at all. The question is, what _should_ it do to \nhead?\n\nShould it just reset HEAD to point to .git/refs/master, and then write the\ncommit ID to it? That may actually sometimes be exactly what you want, and\nat least it will result in a consistent state (ie the next commit will\nhave the right parent). On the other hand, it will blow away whatever the\nold \"master\" branch contained, and thus likely leave an unreachable\ncommit.\n\nOn the other hand, creating a new branch might be a but surprising to \npeople: \"But I just wanted to check it out\". But as far as I can see, it's \nthe only safe thing to do, and it has the advantage that you can then go \nback to the old state with a simple \"git checkout master\".\n\nBut what about the branch name? Should we just ask the user? Together with \na flag, like\n\n\tgit checkout -b new-branch v2.6.12\n\nfor somebody who wants to specify the branch name? Or should we pick a \nrandom name and add a helper function to rename a branch later?\n\nOpinions?\n\n"},{"id":"5999","messageId":"20050712021004.GA27576@buici.com","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507111833380.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-12T02:10:04Z","receivedAt":"2005-07-12T02:10:04Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"On Mon, Jul 11, 2005 at 06:43:23PM -0700, Linus Torvalds wrote:\n> \n> \n> On Mon, 11 Jul 2005, Linus Torvalds wrote:\n> >\n> > No, git-checkout-script _shouldn't_ have done that. It will do the \n> > read-tree on the tag (which will do the right thing), but it won't change \n> > the HEAD itself.\n> \n> In preparation of actually updating the HEAD, I just made \"git checkout\" \n> verify that it only checks out a commit, not a tree tag or something like \n> that. Too late for Marc, but next time around a \"git checkout v2.6.11\" \n\n:-) \n\n> will result in\n> \n> \t[torvalds@g5 linux]$ git checkout v2.6.11\n> \terror: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit\n> \tNeeded a single revision\n> \n> On the other hand, creating a new branch might be a but surprising to \n> people: \"But I just wanted to check it out\". But as far as I can see, it's \n> the only safe thing to do, and it has the advantage that you can then go \n> back to the old state with a simple \"git checkout master\".\n> \n> But what about the branch name? Should we just ask the user? Together with \n> a flag, like\n> \n> \tgit checkout -b new-branch v2.6.12\n> \n> for somebody who wants to specify the branch name? Or should we pick a \n> random name and add a helper function to rename a branch later?\n> \n> Opinions?\n\n>From my POV, what I want is a branch with the tag v2.6.12 as the basis\nof the branch. I'm guessing that -b means \"make me a branch and call\nit this\".\n\n # git checkout -b BRANCH_NAME [TAG]\n\nIf the TAG is omitted, the branch is made from the current HEAD or\nsome other reasonable point defined by the current working directory.\n\nAre uncommitted changes present in the working directory maintained?\nDiscarded? I wont't care since I'll never be doing that. At least,\nnot on purpose.\n"},{"id":"6000","messageId":"7voe98g3ws.fsf@assigned-by-dhcp.cox.net","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507111833380.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-12T02:21:39Z","receivedAt":"2005-07-12T02:21:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> But what about the branch name? Should we just ask the user? Together with \n> a flag, like\n>\n> \tgit checkout -b new-branch v2.6.12\n>\n> for somebody who wants to specify the branch name? Or should we pick a \n> random name and add a helper function to rename a branch later?\n>\n> Opinions?\n\nHow about treating \"master\" a temporary thing --- \"whatever I\nhappen to be working on right now\"?\n\n - git branch ;# copies master to branch-name;\n\t\t\t\t if branch-name exists in refs/heads,\n warn and refuse. Override\n\t\t\t\t with --force flag.\n\n - git checkout ;# copies branch-name to master; but\n if master does not match any\n of the other refs/heads/, warn\n and refuse. Override with\n --force flag.\n\nYes I realize that you have to be careful when to push to your\npublic repository if you take this route, but this is only\nrelevant to people like Jeff with multiple heads, and I think he\npublicly stated that his \"refs/heads/master\" aka .git/HEAD does\nnot mean much and what matters are his branch heads. People who\ndo not use multiple branches but just checks out various tags,\nthe above would be reasonably convenient.\n"},{"id":"6003","messageId":"Pine.LNX.4.58.0507112005540.17536@g5.osdl.org","threadId":"1177","inReplyTo":"20050712021004.GA27576@buici.com","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T03:09:08Z","receivedAt":"2005-07-12T03:09:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Marc Singer wrote:\n> \n> From my POV, what I want is a branch with the tag v2.6.12 as the basis\n> of the branch. I'm guessing that -b means \"make me a branch and call\n> it this\".\n\nYup. That would be the interface.\n\n> # git checkout -b BRANCH_NAME [TAG]\n> \n> If the TAG is omitted, the branch is made from the current HEAD or\n> some other reasonable point defined by the current working directory.\n\nThat would be the most natural thing that would fall out of this kind of \ninterface.\n\n> Are uncommitted changes present in the working directory maintained?\n> Discarded? I wont't care since I'll never be doing that. At least,\n> not on purpose.\n\nThey'd be maintained. If they clash with the target being checked out (ie\nthe checked-out tag would have changes to those files) it would error out\nwith a \"I can't do that, Dave\".\n\nUnless you give the \"-f\" flag, in which case they're all thrown out, and\n\"git checkout\" will force the new state and throw away any old state\nentirely.\n\n\t\t\tLinus\n"},{"id":"6004","messageId":"Pine.LNX.4.58.0507112010120.17536@g5.osdl.org","threadId":"1177","inReplyTo":"7voe98g3ws.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T03:18:28Z","receivedAt":"2005-07-12T03:18:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Junio C Hamano wrote:\n>\n> > Opinions?\n> \n> How about treating \"master\" a temporary thing --- \"whatever I\n> happen to be working on right now\"?\n\nI'd not mind with this in theory, but it has the fundamental problem that \nwe can end up losing sight of commits we have, and then have no way to \nreach them.\n\nWhich is ok per se - sometimes you simply don't care about them, and I\noccasionally drop some commits on purpose when I've done something I\ndecide to undo and then do a \"git prune\" to get rid of the objects.\n\nBut I don't want this to happen _easily_.\n\nYour examples aren't actually very interesting:\n\n> - git branch ;# copies master to branch-name;\n> \t\t\t\t if branch-name exists in refs/heads,\n> warn and refuse. Override\n> \t\t\t\t with --force flag.\n> \n> - git checkout ;# copies branch-name to master; but\n> if master does not match any\n> of the other refs/heads/, warn\n> and refuse. Override with\n> --force flag.\n\nbecause those two examples end up avoiding the _real_ issue, which is the\n\n\tgit checkout v2.6.12\n\ncase, which is exactly the case that would need a \"--force\" flag, since \nmaster is what you're working on before. And --force would drop that \ninformation. \n\nSo I want something that naturally works with this (very reasonable) way \nof working, and does _not_ force people to drop information.\n\nIn your world, you'd have to first save the old master with\n\n\tgit branch work-branch\n\nand then you could do\n\n\tgit checkout v2.6.12\n\nto start on \"master\" anew. That's fair, but it's conceptually very wrong: \nit rquires you to name the _old_ thing, which to me just sounds very \nconfusing indeed. You don't care about the old thing, it's the _new_ thing \nyou care about.\n\nSo at least to me it makes much more sense to say \"ok, I'll start\nsomething new, and call it xyzzy\", than \"ok, I'll start something new, and\nI'll save the old under 'old'\".\n\nThe \"old\" thing might not even be anything you worked on (it might be\nsomething you just cloned from somebody else), so you giving it a name \nisn't very logical. In contrast, you're clearly doing something active \nwith the new thing, so naming _that_ makes sense.\n\n\t\tLinus\n"},{"id":"6007","messageId":"7v8y0cg07c.fsf@assigned-by-dhcp.cox.net","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507112010120.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-12T03:41:43Z","receivedAt":"2005-07-12T03:41:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> So at least to me it makes much more sense to say \"ok, I'll start\n> something new, and call it xyzzy\", than \"ok, I'll start something new, and\n> I'll save the old under 'old'\".\n>\n> The \"old\" thing might not even be anything you worked on (it might be\n> something you just cloned from somebody else), so you giving it a name \n> isn't very logical. In contrast, you're clearly doing something active \n> with the new thing, so naming _that_ makes sense.\n\nWhat I had mind was ``If you do not care about the current\n\"master\", just say \"checkout --force\"''.\n\nWhen I start working on something I often do not know what the\nthing I am going to work on ends up to be. So I would start\nfrom v2.6.12 tag, do random hacking, and when I got into a\nreasonable shape, I would say ``Ok, this is worth saving. Let's\nname it \"foobar\" branch and continue.'' And I would probably\nswitch to some other subproject when an urgent bugfix comes in,\nand I would not want to lose my \"master\" _then_. So (the\n\"branch\" one has been revised):\n\n checkout [--force] \n\n In addition to reading the tree and updating the work tree,\n stores \"^0\" in .git/refs/heads/master. However,\n if the current \"master\" is not something that matches a\n refs/*/*, then the user will be losing the trail between\n \"master\" before checkout and what is recorded in refs/, so\n the user needs to allow me explicitly to do it.\n\n branch \n\n Save the current \"master\" to branch-name. If the user makes\n a mistake and tries to store the \"master\" head into a wrong\n branch, that would lose development trail of the branch being\n overwritten, so if the named branch exists and \"master\" is\n not a descendent of it, the user needs to explicitly tell me\n that it is OK to do so.\n\nI do not quite follow your objections. I do not think I am\nforcing anybody to name an old thing. Do you mean that \"I've\nbeen working on A and now I want to switch to B; so I'll save\nthe current state in A and switch to B\" is too redundant, and I\nshould just let the user say \"I've been working on something I\ndo not care to remember, now I want to switch to B, so just take\nme to B and you should remember where I was and save it to A\nautomatically\"? That sort of makes sense to me.\n"},{"id":"6008","messageId":"Pine.LNX.4.58.0507112045420.17536@g5.osdl.org","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507112005540.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T03:49:14Z","receivedAt":"2005-07-12T03:49:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Linus Torvalds wrote:\n> On Mon, 11 Jul 2005, Marc Singer wrote:\n> > \n> > From my POV, what I want is a branch with the tag v2.6.12 as the basis\n> > of the branch. I'm guessing that -b means \"make me a branch and call\n> > it this\".\n> \n> Yup. That would be the interface.\n> \n> > # git checkout -b BRANCH_NAME [TAG]\n> > \n> > If the TAG is omitted, the branch is made from the current HEAD or\n> > some other reasonable point defined by the current working directory.\n> \n> That would be the most natural thing that would fall out of this kind of \n> interface.\n\nOk, done. \n\nNow, if you try to do\n\n\tgit checkout v2.6.12\n\ngit will complain with\n\n\tgit checkout: you need to specify a new branch name\n\nand some day (when I can get my act together and have man-pages that \nwork), there would even be documentation for the \"-b\" flag to specify the \nbranch name. And indeed, if you only specify the branch name, it will \njust create it and switch to it from the current HEAD.\n\nSo while there are no docs, the checkin comment hopefully says it all:\n\n\t\tLinus\n---\ncommit 91dcdfd3b5331d955cfb60edf8930f1b5c142905\nAuthor: Linus Torvalds \nDate: Mon Jul 11 20:44:20 2005 -0700\n\n Make \"git checkout\" create new branches on demand\n\n In particular, if we check out something that isn't an old branch, it\n now requires a new branch-name to check the thing out into.\n\n So, for example:\n\n git checkout -b my-branch v2.6.12\n\n will create the new branch \"my-branch\", and start it at v2.6.12, while\n\n git checkout master\n\n will just switch back to the master branch.\n\n Of course, if you want to create a new branch \"my-branch\" and _not_\n check it out, you could have done so with just\n\n git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch\n\n which I think I will codify as \"git branch\".\n"},{"id":"6009","messageId":"Pine.LNX.4.58.0507112050300.17536@g5.osdl.org","threadId":"1177","inReplyTo":"7v8y0cg07c.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T03:52:05Z","receivedAt":"2005-07-12T03:52:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Junio C Hamano wrote:\n> \n> I do not quite follow your objections. I do not think I am\n> forcing anybody to name an old thing.\n\nSure you are. You're forcing them to make a choice, where both choices \nare bad. Either:\n\n - name an old thing (that you may not even have worked on - \"master\" from \n a newly cloned repo)\n\n - throw the old master state away (\"--force\")\n\nEither choice is bad.\n\n\t\tLinus\n"},{"id":"6010","messageId":"20050712035315.GA6630@buici.com","threadId":"1177","inReplyTo":"7v8y0cg07c.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-12T03:53:15Z","receivedAt":"2005-07-12T03:53:15Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"On Mon, Jul 11, 2005 at 08:41:43PM -0700, Junio C Hamano wrote:\n> When I start working on something I often do not know what the\n> thing I am going to work on ends up to be. So I would start\n> from v2.6.12 tag, do random hacking, and when I got into a\n> reasonable shape, I would say ``Ok, this is worth saving. Let's\n> name it \"foobar\" branch and continue.'' And I would probably\n> switch to some other subproject when an urgent bugfix comes in,\n> and I would not want to lose my \"master\" _then_. So (the\n> \"branch\" one has been revised):\n\nIsn't that what a tag is for?\n\n o Make a sandbox\n o Commit cool changes\n o Tag the last commit object\n o Throw sandbox away.\n o Push changes or generate patch based on the tag\n\nThe change is that we can create a sandbox by giving it a starting\npoint, a tag. If we decide we want to keep working on this branch,\nall we'd have to do is go back to that tag, although I admit it may\nseem sloppy to have to create a new branch from a tag'd commit that we\noriginally part of a branch.\n"},{"id":"6011","messageId":"Pine.LNX.4.58.0507112132170.17536@g5.osdl.org","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507112045420.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T04:34:33Z","receivedAt":"2005-07-12T04:34:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Linus Torvalds wrote:\n> \n> Of course, if you want to create a new branch \"my-branch\" and _not_\n> check it out, you could have done so with just\n> \n> git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch\n> \n> which I think I will codify as \"git branch\".\n\nAnd now we have that \"git branch\". It's a trivial one-liner, except with\nthe setup and error checking it's actually more like six lines.\n\n\t\tLinus\n\n---\ncommit 37f1a519f2ea0ce912ccd7c623aea992147c3900\nAuthor: Linus Torvalds \nDate: Mon Jul 11 21:30:23 2005 -0700\n\n Add \"git branch\" script\n\n You can use it as\n\n git branch [start-point]\n\n and it creates a new branch of name . If a starting point\n is specified, that will be where the branch is created, otherwise it\n will be created at the current HEAD.\n\n The sequence\n\n git branch xyz abc\n git checkout xyz\n\n can also be written as\n\n git checkout -b xyz abc\n\n as per the previous commit.\n"},{"id":"6013","messageId":"20050712044352.GA9919@buici.com","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507112132170.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-12T04:43:53Z","receivedAt":"2005-07-12T04:43:53Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"On Mon, Jul 11, 2005 at 09:34:33PM -0700, Linus Torvalds wrote:\n> \n> \n> On Mon, 11 Jul 2005, Linus Torvalds wrote:\n> > \n> > Of course, if you want to create a new branch \"my-branch\" and _not_\n> > check it out, you could have done so with just\n> > \n> > git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch\n> > \n> > which I think I will codify as \"git branch\".\n> \n> And now we have that \"git branch\". It's a trivial one-liner, except with\n> the setup and error checking it's actually more like six lines.\n\nDoes it make sense to think about this branch as an flow of commits?\nOr is it just a starting point for a line of development? If I make a\nbranch, check it out, commit changes to it, and then clobber the\nworking directory, can I later resume that branch of development\nwithout creating a new branch? Do I need to set a tag to mark the\nlast commit on that branch?\n"},{"id":"6015","messageId":"Pine.LNX.4.58.0507112149290.17536@g5.osdl.org","threadId":"1177","inReplyTo":"20050712044352.GA9919@buici.com","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T04:59:25Z","receivedAt":"2005-07-12T04:59:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Marc Singer wrote:\n> \n> Does it make sense to think about this branch as an flow of commits?\n> Or is it just a starting point for a line of development?\n\nIt's really a flow of commits. Nothing will ever really remember what the \nstarting point was at some later date if you have done commits, and the \nbranch will always follow the _head_ of development on that branch.\n\nSo if you need to remember the starting point as a _static_ entity, you\nneed to create a tag pointing to that place. You can do that at any point,\nvery much including after you've already done development (but before you\nforget what to tag ;)\n\n> If I make a branch, check it out, commit changes to it, and then clobber\n> the working directory, can I later resume that branch of development\n> without creating a new branch?\n\nAbsolutely. You can create a branch, commit to it, switch to another \nbranch, commit to that one, switch back to the branch you created, and \njust go on. A branch will always follow the development.\n\n> Do I need to set a tag to mark the last commit on that branch?\n\nNo, but as mentioned, _if_ you care about remembering where you _started_ \nthe branch, you may want to tag that.\n\nOf course, most of the time you really really don't care. It will be\nlargely obvious from the global commit history, which you can trivially\nvisualize with \"gitk --all\". You'll see where your branch \"split off\" the\nmain branch, and the only case where that is ambiguous is if you started\nyour branch at the tip of another branch, and no other development has\ngone on in that other branch - then you don't see a \"fork\".\n\nOf course, the other reason you usually don't care where you started is\nthat you simply don't care. When you use CVS, you usually need to know\nwhere the branch was started (and each point it was merged at) just so\nthat you can sanely merge it by doing diffs etc. With git, since we have\nall the proper history, that's not necessary at all.\n\nSo I _suspect_ that most of the time when you create a branch, you don't \nneed to tag where you started. Others will see what is your development \nsimply by virtue of it being in your tree and not in other peoples tree, \nwhether you created a branch for that or not ;)\n\n\t\tLinus\n"},{"id":"6017","messageId":"20050712051235.GA10930@buici.com","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507112149290.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2005-07-12T05:12:35Z","receivedAt":"2005-07-12T05:12:35Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"On Mon, Jul 11, 2005 at 09:59:25PM -0700, Linus Torvalds wrote:\n> \n> \n> On Mon, 11 Jul 2005, Marc Singer wrote:\n> > \n> > Does it make sense to think about this branch as an flow of commits?\n> > Or is it just a starting point for a line of development?\n> \n> It's really a flow of commits. Nothing will ever really remember what the \n> starting point was at some later date if you have done commits, and the \n> branch will always follow the _head_ of development on that branch.\n\nThat's the important detail.\n\nAs an aside, we (a vary large set of developers) have been using SCM\ntools for how-many-freakin-years and only now am I seeing something\nsane. Cheers.\n"},{"id":"6025","messageId":"20050712074801.GD6363@pasky.ji.cz","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507112132170.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-12T07:48:01Z","receivedAt":"2005-07-12T07:48:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Jul 12, 2005 at 06:34:33AM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> On Mon, 11 Jul 2005, Linus Torvalds wrote:\n> > \n> > Of course, if you want to create a new branch \"my-branch\" and _not_\n> > check it out, you could have done so with just\n> > \n> > git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch\n> > \n> > which I think I will codify as \"git branch\".\n> \n> And now we have that \"git branch\". It's a trivial one-liner, except with\n> the setup and error checking it's actually more like six lines.\n\nCould we please have the branch name written to .git/head-name in case\nwe switch the branch? The reason is that .git/HEAD may not be always a\nsymlink. Specifically, I do this - there's a command cg-seek, which will\nseek your working tree to a given commit, while staying on the branch\n(committing and some other operations are blocked). In that case, I\nremove .git/HEAD and replace it with ID of the commit I'm seeked at, and\nwhen I'm \"unseeking\" back to the top, I replace it with the symlink\nagain. With some heuristics, I could create .git/head-name at the time\nof seek and hope, but I think it'd be cleaner to just always set it\n(except when we are on the master branch), if you agree.\n\nNote that even though Cogito won't let you create/change a local branch\nyet, it will understand .git/head-name and hopefully behave properly\n(although it's totally untested, of course).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"6029","messageId":"7vy88c5r4w.fsf@assigned-by-dhcp.cox.net","threadId":"1177","inReplyTo":"20050712074801.GD6363@pasky.ji.cz","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-12T09:07:43Z","receivedAt":"2005-07-12T09:07:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I do want to see various Porcelains to agree on how to store\nstate information in $GIT_DIR for doing common operations, when\nthey are conceptually compatible. The way they handle branches\nmay fall into that category. With the barebone GIT Porcelain,\n\"seek\" like operation may simply be done by creating another\nbranch or tag and jumping to it, so there may not be the concept\nof \"seek\", in which case they may not be compatible after all.\n\nHaving said that, I do like the concept of keeping track of\n\"which development line are we on, and what's most recent in\nit\". The way I read your description of cg-seek, you currently\nhave that information is either in .git/head-name and\n.git/refs/heads/ pair (when .git/head-name exists),\nor .git/HEAD.\n\nIf you block certain operations while you have seeked to non-top\nanyway, wouldn't it be cleaner to have .git/seeked-to that\nrecords the commit ID you are at, which at the same time\nindicates that you are in a special situation, and not touching\nHEAD at all? Then .git/HEAD will always have that line of\ndevelopment information.\n\nWell, that was half tongue-in-cheek suggestion; I have a feeling\nthat you may feel it is a bit too late to change this kind of\nthing easily.\n\nBut if we are going to agree on using .git/head-name, I'd rather\nsee it exist all times, so that cat \"$GIT_DIR/head-name\" would\nalways tell us which branch we are working in.\n"},{"id":"6041","messageId":"pan.2005.07.12.16.29.24.715453@smurf.noris.de","threadId":"1177","inReplyTo":"7vy88c5r4w.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-12T16:29:26Z","receivedAt":"2005-07-12T16:29:26Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Junio C Hamano wrote:\n\n> Having said that, I do like the concept of keeping track of\n> \"which development line are we on, and what's most recent in\n> it\". The way I read your description of cg-seek, you currently\n> have that information is either in .git/head-name and\n> .git/refs/heads/ pair (when .git/head-name exists),\n> or .git/HEAD.\n\nPersonally, I'd rather have as few invariants as possible, so that various\nPorcelains can agree on semantics.\n\nWhat I would expect from a sane .git tree is that\n* .git/HEAD contains the commit that is currently checked out.\n* If HEAD is not a symlink, then switching to a branch HEAD is not a part\n of should emit a warning.\n (\"fsck to find the dangling commits\" is not an answer ;-)\n\nIdeas like\n* remember the branch to un-seek back to\nor\n* treat HEAD as read-only when there's a seek active\n\nseem to be optional / Porcelain-specific.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\n\"We'll strategically withdraw to previously prepared position.\"\n\"Who prepared them?\"\n\"we'll prepare them when we get there.\"\n\t\t-- Terry Pratchett (Reaper Man)\n"},{"id":"6042","messageId":"Pine.LNX.4.58.0507120938240.17536@g5.osdl.org","threadId":"1177","inReplyTo":"20050712074801.GD6363@pasky.ji.cz","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T16:48:50Z","receivedAt":"2005-07-12T16:48:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 12 Jul 2005, Petr Baudis wrote:\n> \n> Could we please have the branch name written to .git/head-name in case\n> we switch the branch?\n\nI wouldn't mind per se, but on the other hand I really _hate_ having \n\"parallel\" information that can get out of sync. If you have two places \nholding the same information, they had better match. And this is something \nthat sounds like it could very easily start to not match, and then we're \nscrewed.\n\nSo I'd _much_ rather see instead:\n\n - .git/head-name is a cogito-specific thing that is only active while \n cogito is _seeking_. So then \"cg-unseek\" ends up being pretty much \n equivalent to\n\n\t[ -e .git/head-name ] || die \"You weren't seeking\"\n\tgit checkout $(cat .git/head-name)\n\trm .git/head-name\n\n This way \"head-name\" is really never even supposed to be \"in sync\" with \n .git/HEAD, and there are no synchronization issues. \n\n - in order for a \"git checkout\" to not get confused and possibly throwing \n a cogito temporary head away (and so that git-fsck-cache is happy \n during a seek), would it be possible to make \"seek\" use a real \n temporary branch instead? Ie, \"cg-seek\" would be something like\n\n\t[ -e .git/head-name ] && die \"You are already seeking\"\n\treadlink .git/HEAD > .git/head-name\n\techo $seekpoint > .git/refs/heads/cg-seek-point\n\tgit checkout -f cg-seek-point\n\n or similar?\n\nThen \"cg-seek\" and \"cg-unseek\" would continue to work, but the core git \nlayer would never be confused because they're really using normal \nbranches?\n\n\t\tLinus\n"},{"id":"6061","messageId":"Pine.LNX.4.21.0507121240120.2876-100000@iabervon.org","threadId":"1177","inReplyTo":"7voe98g3ws.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-07-12T17:04:01Z","receivedAt":"2005-07-12T17:04:01Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 11 Jul 2005, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > But what about the branch name? Should we just ask the user? Together with \n> > a flag, like\n> >\n> > \tgit checkout -b new-branch v2.6.12\n> >\n> > for somebody who wants to specify the branch name? Or should we pick a \n> > random name and add a helper function to rename a branch later?\n> >\n> > Opinions?\n> \n> How about treating \"master\" a temporary thing --- \"whatever I\n> happen to be working on right now\"?\n\nThat conflicts with my usage, where I have a single repository for all of\nmy working directories, with .git/refs and .git/objects being symlinks to \nit, but .git/HEAD being different for each branch. The stuff in objects/\nand refs/ really shouldn't depend on what you're currently doing for this\nreason.\n\nMy way of thinking of \"master\" is that it's a real branch, which is for\nall of the situations where you aren't using a specially-designated\nbranch. For many people, they only do stuff that's not designated\nspecially; Jeff only does stuff that is designated specially. But if you\ndo both, you'll want master to be left alone while you work on the side\nbranch.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"6409","messageId":"20050724085757.GB7601@pasky.ji.cz","threadId":"1177","inReplyTo":"7vy88c5r4w.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-24T08:57:57Z","receivedAt":"2005-07-24T08:57:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Jul 12, 2005 at 11:07:43AM CEST, I got a letter\nwhere Junio C Hamano told me that...\n> If you block certain operations while you have seeked to non-top\n> anyway, wouldn't it be cleaner to have .git/seeked-to that\n> records the commit ID you are at, which at the same time\n> indicates that you are in a special situation, and not touching\n> HEAD at all? Then .git/HEAD will always have that line of\n> development information.\n> \n> Well, that was half tongue-in-cheek suggestion; I have a feeling\n> that you may feel it is a bit too late to change this kind of\n> thing easily.\n\nThe thing is, _everything_ assumes .git/HEAD is the current commit\nchecked out in the index. All the Cogito (that wouldn't be hard to\nchange at all), all the other Porcelains, the core GIT tools. So\nchanging that would be difficult and it's much easier this way.\n\n> But if we are going to agree on using .git/head-name, I'd rather\n> see it exist all times, so that cat \"$GIT_DIR/head-name\" would\n> always tell us which branch we are working in.\n\nAfter some thought, I like Linus' approach more now, having head-name\nonly when it's really necessary.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone. -- Alan Cox\n"},{"id":"6411","messageId":"7v4qakdve3.fsf@assigned-by-dhcp.cox.net","threadId":"1177","inReplyTo":"20050724085757.GB7601@pasky.ji.cz","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-24T16:24:52Z","receivedAt":"2005-07-24T16:24:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> After some thought, I like Linus' approach more now, having head-name\n> only when it's really necessary.\n\nI agree 100%. That makes much more sense.\n\nThe message from Linus reminded me that the way he tackles a\nproblem is (as always) simpler, consistent and more elegant than\nmine. I have been practicing thinking things through more than\nthree times before I open my mouth, but still...\n"},{"id":"7098","messageId":"20050812012610.GN25280@pasky.ji.cz","threadId":"1177","inReplyTo":"Pine.LNX.4.58.0507120938240.17536@g5.osdl.org","subject":"Re: Bootstrapping into git, commit gripes at me","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-08-12T01:26:10Z","receivedAt":"2005-08-12T01:26:10Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Jul 12, 2005 at 06:48:50PM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> Then \"cg-seek\" and \"cg-unseek\" would continue to work, but the core git \n> layer would never be confused because they're really using normal \n> branches?\n\nThat makes sense, I just did exactly that.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone. -- Alan Cox\n"}]}