Re: several quick questions

[Andreas Ericsson <ae@op5.se>]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>Junio C Hamano wrote:
>>
>>
>>>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.
> 
> 
> Sorry, is this "do my suggestion" a solution to my "do not
> commit on top of this yourself, only fast-forward from somewhere
> else is allowed -- e.g. to protect 'origin'" issue, or is it
> something completely different?
> 

The "git checkout -b foo HEAD~15", which was already supported, although 
I missed that. All programmers have names to use just for throwaway 
variables (never heard "frotz" and "nitfol" before though), so adding 
the burden of selecting a name for the throw-away search branch 
shouldn't be too hard on them. Then it would be possible to commit to 
it, and merge or cherry-pick from it later. It's usually preferrable to 
amend to a broken patch than to revert it completely.

In essence, I claim that git-seek is superfluous and inferior to "git 
checkout -b foo <commit-ish>" and shouldn't be implemented. If anyone 
wants to distribute the source to non-scm people as per a given point in 
the history I think "git tar-tree" works marvelously as is.

The good thing about being past 1.0 in a project is that it's 
feature-complete, or close to. The bad thing is that bloat usually 
starts to happen around 1.1.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231