Re: [RFC/PATCH 2/4] Add git-sequencer prototype documentation

[Stephan Beyer <s-beyer@gmx.net>]

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@gmail.com> 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@gmx.net>, PGP 0x6EDDD207FCC5040F