On Wed, Jul 02, 2008 at 02:39:40AM +0200, Jakub Narebski wrote: > On Tue, 1 July 2008, Stephan Beyer wrote: > > On Tue, Jul 01, 2008 at 08:04:10PM +0200, Jakub Narebski wrote: [...] > > No. It is "git-update-ref <ref> HEAD". > > So what do you envision would this be used for? I think if I had not started on top js/rebase-i-sequencer, I would have not necessarily added "ref" (or "tag", as it was before). But js/rebase-i-sequencer introduced a nice feature to git-rebase-i: -t,--preserve-tags ... "update tags to the new commit object" I think this is worth the feature ;-) On Tue, Jul 01, 2008 at 06:20:15PM -0700, Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > > >> No. It is "git-update-ref <ref> HEAD". > > > > So what do you envision would this be used for? > > A simple answer and a more elaborate one. > > * It is the final step of "git rebase" which detaches HEAD while it > operates these days. Ha ;) That's a quite obvious truth that I have not implemented. Btw: sequencer does the detaching/attaching when using "--onto <base>" and <base> is a branch. IIRC there was a reason that I also kept the detaching/attaching of git-rebase-i itself but I can't remember. (I think I have to look over the rebase-i code more carefully later...) > * You can drive sequencer backend from a front-end that rewrite history > while rewriting tags, like filter-branch does. Yes. > >>> What is important is: does it update reflog (correctly)? > > That is not very important question, as reflog updates would happen as > long as you use update-ref automatically. > > Much more important question you did not ask is how it would interact with > "sequencer --abort". Ideally it should rewind the ref update (and without > relying on the user having reflog on that ref). Yes, you asked the question in the RFC thread about the spec. "Rewind the ref update" means: - delete new generated refs - update overwritten refs to their old commits So if I keep a list containing <ref> [<oldcommit>], that behavior is easily reached. But this is not suited for the shell prototype ;) Btw, also the --skip case can be arguable: pick fa1afe1 pick cedefe1 # conflict, will be "--skip"ped ref refs/tags/v1.6.2 Here the question can be, if the "ref" should be skipped, too. But I think the just-don't-care-strategy is a good one, so that fa1afe1' will be tagged. > I however personally feel that this "ref" thing is being a bit too > ambitious. I agree that it is no must-have feature but a nice-to-have feature ;) Especially for the --preserve-tags feature. Jakub wrote: > >>>>> +squash [options] --from <mark>:: > > [...] > >>> Here an example why it is useful for user-editing: > >>> > >>> (on commit f00babe) > >>> mark :1 > >>> pick badcebab > >>> patch foo > >>> pick dadadada > >>> squash -m "Foo the cebab" --signoff --from :1 > >>> > >>> This squashes all between the mark and the squash into one commit, > >>> on top of f00babe. > >> > >> Ah, so squash --from <mark> picks up everything since "mark <mark>", > >> but does not include marked commit! Clever! In this case allowing > >> only <mark> is a good idea, IMVHO. > > > > Good, thanks :) > > Although I guess having example would make it clear from the go... Yes, I see that the EXAMPLES section is really important and the squash --from is important therein. Regards, Stephan -- Stephan Beyer <s-beyer@xxxxxxx>, PGP 0x6EDDD207FCC5040F -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
