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

On Wed, Jul 02, 2008 at 02:39:40AM +0200, Jakub Narebski wrote:

On Tue, 1 July 2008, Stephan Beyer wrote:

quoted

On Tue, Jul 01, 2008 at 08:04:10PM +0200, Jakub Narebski wrote:

[...]

quoted

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 [off-list ref] writes:

quoted

quoted

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.

quoted

quoted

quoted

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:

quoted

quoted

quoted

quoted

quoted

+squash [options] --from <mark>::

[...]

quoted

quoted

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 [off-list ref], PGP 0x6EDDD207FCC5040F