threads / discuss / 43301

Re: Missing features in git

Subject: Re: Missing features in git

## tl;dr

4 messages between Nov 14, 2006 and Nov 15, 2006.

replies: 3people: 4as markdown or json

Edgar Toernig· Nov 14, 2006, 18:55 UTC · lore
linux@horizon.com wrote:
Show 9 quoted lines
>
> Personally, I'd prefer if the requirement that HEAD point to
> refs/heads were enforced when checking in rather than checking out.
>   
> Then you could check out an arbitrary version without any of the annoyance
> above; I could "git checkout tags/foo" or even "git checkout deadbeef~3".
> I wouldn't be on a current branch (which would necessitate changing
> "git branch" output), so HEAD would simply contain an object ID directly
> rather than being a symlink/symref.

I wholeheartedly agree. For the casual user it's IMHO the most annoying behaviour of git that you can't simply checkout an arbitrary commit without creating a new (most of the time temporary) branch first. Often you don't plan to change the checked out tree and giving it a new branch name ahead is cumbersome, especially as you know that you'll never commit into it and have to delete the branch before checking out another tag. I would prefer this behaviour:

	$ git checkout v2.6.16
	... i.e. check whether it builds
	$ git checkout v2.6.17
	... test this one
	$ git checkout v2.6.18
	... change something
	$ git commit
	error: can't commit.  not on any branch.
	use "git commit -b <new-branch-name>" to commit into a new one.
	$ git commit -b my-v2.6.18
linux@horizon.com· Nov 14, 2006, 21:38 UTC · re: Edgar Toernig · lore
Show 7 quoted lines
>>> Another solution would be to be able to put non-head ref in HEAD,
>>> but allow to commit only if the prefix is refs/heads/
>> 
>> That's not a bad idea.  Then you can checkout a tag and have
>> 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
>> $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
>> as their current branch, reminding them they are looking at the past.
Show 9 quoted lines
> I agree. This would probably be a good way to do "read-only branches".
> 
> Allowing people to do a "git checkout" on anything committish, but then 
> not allowing them to commit to that, is probably the right thing to do.
> 
> Together with a nice readable error message from "git commit" (and merge, 
> and pull - although you might well allow "fetch" to update the thing that 
> current HEAD points to, though), this would be a lot easier to use for 
> people who just follow somebody elses branch.

This certainly seems like a popular idea. I think the vote is to symlink (symref) to a non-refs/heads/ object if possible, but allow an arbitrary object ID as well. In either case, commits would be forbidden.

The only reason I had avoided symlinking before was in case the tag was deleted, but that can be fixed easily enough. (Either make git-tag -d/-f fail, or have it replace the HEAD symref with a raw hex object. Actually, you could do the same with git branch -d. Any opinions?)

I can try to write the patch if there are no better volunteers, although it'll take me a lot longer that someone more comfortable with the code.

Um.. for example, I'm not sure what the git fetch problem could possibly be. It only updates heads, no? Or are you thinking of the new refs/remotes thing that I'm not familiar with?

I'll have to examine the callers of git-symbolic-ref to see what it should do. Return the hex object ID and fail are the obvious possibilities.

Note that NOT having any sort of bisect label (and just using HEAD itself as a raw pointer) solves the "git reset --hard" problem; I can "git checkout HEAD^" and have debug hacks preserved.

It also removes a paragraph of excuses from some "using git" docs I'm writing. It's a lot easier to explain why you can't commit if you're not on a branch than to explain why you can't not be on a branch.

Oh, and as I mentioned, not that "git checkout -b <newbranch>" is exactly painful, but I think a "-b <newbranch>" option to git-commit would be a convenience. (An interesting question is whether it should create the new branch even if there is nothing to. I'm thinking "yes"

Karl Hasselström· Nov 15, 2006, 07:35 UTC · re: linux@horizon.com · lore
On 2006-11-14 16:38:00 -0500, linux@horizon.com wrote:
> It also removes a paragraph of excuses from some "using git" docs
> I'm writing. It's a lot easier to explain why you can't commit if
> you're not on a branch than to explain why you can't not be on a
> branch.

This is precisely why writing documentation is such a good idea: It is in many cases easier to fix the warts than finding a pedagogical way to explain them. :-)

(Well, then there's the secondary benefit that users can learn from the docs ...)

-- 
Karl Hasselström, kha@treskal.com
Linus Torvalds· Nov 15, 2006, 16:50 UTC · re: Karl Hasselström · lore
On Wed, 15 Nov 2006, Karl Hasselström wrote:
Show 10 quoted lines
> On 2006-11-14 16:38:00 -0500, linux@horizon.com wrote:
> 
> > It also removes a paragraph of excuses from some "using git" docs
> > I'm writing. It's a lot easier to explain why you can't commit if
> > you're not on a branch than to explain why you can't not be on a
> > branch.
> 
> This is precisely why writing documentation is such a good idea: It is
> in many cases easier to fix the warts than finding a pedagogical way
> to explain them. :-)

Heh. Pretty much all of the early git plumbing came about when I started to try to demonstrate git to others, and wrote some of the early tutorials. So yeah, trying to explain something to others (whether by documentation or through examples) is a good way to show what has bad interfaces.

Even if it's easy to use for yourself (I had my own scripts to do everything _I_ wanted to do), trying to explain why something is done some way to somebody who doesn't know the internals is always a good exercise.

		Linus

← back to recent threads