From: Andreas Ericsson Date: Wed, 15 Feb 2006 09:06:17 GMT Subject: Re: several quick questions Message-ID: <43F2EF09.5060603@op5.se> In-Reply-To: <7vwtfxm917.fsf@assigned-by-dhcp.cox.net> Junio C Hamano wrote: > Andreas Ericsson 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 " 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