From: Andreas Ericsson Date: Tue, 14 Feb 2006 23:00:57 GMT Subject: Re: several quick questions Message-ID: <43F26129.4040804@op5.se> In-Reply-To: <7v7j7xr54u.fsf@assigned-by-dhcp.cox.net> Junio C Hamano wrote: > Josef Weidendorfer writes: > > >>Why not allow something like >> >> git-checkout master~5 >> >>which implicitly does create a read-only branch "seek-point"? > > > Now what does "git-checkout branch" mean? Does it switch to the > branch, or does it force tip of seek-point to be the tip of > branch and switch to seek-point branch? More interestingly, > what does "git-checkout seek-point" mean? > > If we _were_ to do something like cg-seek where an implicit > throw-away branch is used, you at least need a way to > disambiguate these cases, and "git seek" originally suggested is > far clearer than what you said above. > Nah. What's the point of having another protected name. Just allow $ git checkout -b discard HEAD~15 and we're good to go. > Having said that, I am not convinced in either way, though. > > >>A branch could be marked readonly by above command with >> >> chmod a-w .git/refs/heads/seek > > > I do not think that would work. Have you tried it? > It wouldn't on cygwin, for one. I'm against having things work differently on different platforms. If nothing else it usually worsens the bitrot that always happens to documentation. > >>And git-commit should refuse to commit on a readonly ref, telling >>the user to create a writable branch before with "git-branch new". > > > Now, read-only ref does not interest me, but "do not commit on > top of this yourself, only fast-forward from somewhere else is > allowed" may be useful, for the reason why you mentioned > "origin". > Do my suggestion and you wouldn't have to worry about read-only branches, and although merging any changes from it might be more trouble than its worth, it might be possible to cherry-pick the commit rather than reverting and re-applying it. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231