Re: several quick questions

[Andreas Ericsson <ae@op5.se>]

Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> 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