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

[Jakub Narebski <jnareb@gmail.com>]

Hi!

On Tue, 1 July 2008, Stephan Beyer wrote:
> On Tue, Jul 01, 2008 at 08:04:10PM +0200, Jakub Narebski wrote:
>> On Tue, 1 Jul 2008, Stephan Beyer wrote:
>>> On Tue, Jul 01, 2008 at 06:02:54AM -0700,
>>> Jakub Narebski <jnareb@gmail.com> wrote:
>>>> Stephan Beyer wrote:
[...]
>>>>> +ref <ref>::
>>>>> +	Set ref `<ref>` to the current HEAD, see also
>>>>> +	linkgit:git-update-ref[1].
>>>> 
>>>> So this functions like "git reset --soft <ref>", isn't it?
>>> 
>>> No. Why do you think that? `ref` is set, and not HEAD.
>>> I think the description makes that clear.
>> 
>> Ah.  I'm sorry.  So it is like "git branch <ref>", isn't it?

Actually I meant "git branch -f <ref>" here.  But I forgot that it
can be used to create lightweight tags, too.

> No. It is "git-update-ref <ref> HEAD".

So what do you envision would this be used for?

>> What is important is: does it update reflog (correctly)?
> 
> Good question. The reflog is another mistery to me that I haven't really
> cared about, because I haven't used it yet myself.
> At least the reflog test cases for git rebase -i in the test suite pass.
> (Of course, this is only a weak indication that it works as it should.)

You have 'branch' (<onto>) reflog, HEAD reflog, and reflog for '<ref>'.
While 'branch' reflog should I think record only start and end of
sequencer, or rather git-am or git-rebase, I'm not sure what to do about
HEAD reflog...  We should fill reflog for <ref>, to be able to revert
easily.

>>>>> +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...

Good work!
-- 
Jakub Narebski
Poland