{"thread":{"id":"43301","subject":"Re: Missing features in git","startedAt":"2006-11-14T18:55:59Z","lastAt":"2006-11-15T16:50:26Z","messageCount":4,"participants":["linux@horizon.com","Edgar Toernig","Linus Torvalds","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295682","messageId":"20061114195559.40967ee4.froese@gmx.de","threadId":"43301","inReplyTo":"20061114134958.5326.qmail@science.horizon.com","subject":"Re: Missing features in git","fromName":"Edgar Toernig","fromEmail":"froese@gmx.de","sentAt":"2006-11-14T18:55:59Z","receivedAt":"2006-11-14T18:55:59Z","isPatch":false,"sender":{"key":"froese@gmx.de","avatar":null},"body":"linux@horizon.com wrote:\n>\n> Personally, I'd prefer if the requirement that HEAD point to\n> refs/heads were enforced when checking in rather than checking out.\n>   \n> Then you could check out an arbitrary version without any of the annoyance\n> above; I could \"git checkout tags/foo\" or even \"git checkout deadbeef~3\".\n> I wouldn't be on a current branch (which would necessitate changing\n> \"git branch\" output), so HEAD would simply contain an object ID directly\n> rather than being a symlink/symref.\n\nI wholeheartedly agree.  For the casual user it's IMHO the most\nannoying behaviour of git that you can't simply checkout an arbitrary\ncommit without creating a new (most of the time temporary) branch first.\nOften you don't plan to change the checked out tree and giving it a\nnew branch name ahead is cumbersome, especially as you know that you'll\nnever commit into it and have to delete the branch before checking out\nanother tag.  I would prefer this behaviour:\n\n\t$ git checkout v2.6.16\n\t... i.e. check whether it builds\n\t$ git checkout v2.6.17\n\t... test this one\n\t$ git checkout v2.6.18\n\t... change something\n\t$ git commit\n\terror: can't commit.  not on any branch.\n\tuse \"git commit -b <new-branch-name>\" to commit into a new one.\n\t$ git commit -b my-v2.6.18\n\n"},{"id":"294272","messageId":"20061114213800.28716.qmail@science.horizon.com","threadId":"43301","inReplyTo":"20061114195559.40967ee4.froese@gmx.de","subject":"Re: Missing features in git","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-11-14T21:38:00Z","receivedAt":"2006-11-14T21:38:00Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":">>> Another solution would be to be able to put non-head ref in HEAD,\n>>> but allow to commit only if the prefix is refs/heads/\n>> \n>> That's not a bad idea.  Then you can checkout a tag and have\n>> 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts\n>> $(git-symbolic-ref) calls into their PS1 will see \"refs/tags/v1.11\"\n>> as their current branch, reminding them they are looking at the past.\n\n> I agree. This would probably be a good way to do \"read-only branches\".\n> \n> Allowing people to do a \"git checkout\" on anything committish, but then \n> not allowing them to commit to that, is probably the right thing to do.\n> \n> Together with a nice readable error message from \"git commit\" (and merge, \n> and pull - although you might well allow \"fetch\" to update the thing that \n> current HEAD points to, though), this would be a lot easier to use for \n> people who just follow somebody elses branch.\n\nThis certainly seems like a popular idea.  I think the vote is to symlink\n(symref) to a non-refs/heads/ object if possible, but allow an arbitrary\nobject ID as well.  In either case, commits would be forbidden.\n\nThe only reason I had avoided symlinking before was in case the tag was\ndeleted, but that can be fixed easily enough.  (Either make git-tag -d/-f\nfail, or have it replace the HEAD symref with a raw hex object.\nActually, you could do the same with git branch -d.  Any opinions?)\n\nI can try to write the patch if there are no better volunteers, although\nit'll take me a lot longer that someone more comfortable with the code.\n\nUm.. for example, I'm not sure what the git fetch problem could\npossibly be.  It only updates heads, no?  Or are you thinking\nof the new refs/remotes thing that I'm not familiar with?\n\nI'll have to examine the callers of git-symbolic-ref to see what\nit should do.  Return the hex object ID and fail are the obvious\npossibilities.\n\n\nNote that NOT having any sort of bisect label (and just using HEAD\nitself as a raw pointer) solves the \"git reset --hard\" problem; I can\n\"git checkout HEAD^\" and have debug hacks preserved.\n\nIt also removes a paragraph of excuses from some \"using git\" docs\nI'm writing.  It's a lot easier to explain why you can't commit\nif you're not on a branch than to explain why you can't not be\non a branch.\n\nOh, and as I mentioned, not that \"git checkout -b <newbranch>\" is\nexactly painful, but I think a \"-b <newbranch>\" option to git-commit\nwould be a convenience.  (An interesting question is whether it should\ncreate the new branch even if there is nothing to.  I'm thinking \"yes\"\n"},{"id":"297825","messageId":"20061115073546.GD5453@diana.vm.bytemark.co.uk","threadId":"43301","inReplyTo":"20061114213800.28716.qmail@science.horizon.com","subject":"Re: Missing features in git","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-15T07:35:46Z","receivedAt":"2006-11-15T07:35:46Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-14 16:38:00 -0500, linux@horizon.com wrote:\n\n> It also removes a paragraph of excuses from some \"using git\" docs\n> I'm writing. It's a lot easier to explain why you can't commit if\n> you're not on a branch than to explain why you can't not be on a\n> branch.\n\nThis is precisely why writing documentation is such a good idea: It is\nin many cases easier to fix the warts than finding a pedagogical way\nto explain them. :-)\n\n(Well, then there's the secondary benefit that users can learn from\nthe docs ...)\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"297444","messageId":"Pine.LNX.4.64.0611150847400.3349@woody.osdl.org","threadId":"43301","inReplyTo":"20061115073546.GD5453@diana.vm.bytemark.co.uk","subject":"Re: Missing features in git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-15T16:50:26Z","receivedAt":"2006-11-15T16:50:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Nov 2006, Karl Hasselström wrote:\n\n> On 2006-11-14 16:38:00 -0500, linux@horizon.com wrote:\n> \n> > It also removes a paragraph of excuses from some \"using git\" docs\n> > I'm writing. It's a lot easier to explain why you can't commit if\n> > you're not on a branch than to explain why you can't not be on a\n> > branch.\n> \n> This is precisely why writing documentation is such a good idea: It is\n> in many cases easier to fix the warts than finding a pedagogical way\n> to explain them. :-)\n\nHeh. Pretty much all of the early git plumbing came about when I started \nto try to demonstrate git to others, and wrote some of the early \ntutorials. So yeah, trying to explain something to others (whether by \ndocumentation or through examples) is a good way to show what has bad \ninterfaces.\n\nEven if it's easy to use for yourself (I had my own scripts to do \neverything _I_ wanted to do), trying to explain why something is done some \nway to somebody who doesn't know the internals is always a good exercise.\n\n\t\tLinus"}]}