Hi,

On Tue, Jul 01, 2008 at 08:04:10PM +0200, Jakub Narebski wrote:
quoted text
> 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:
> >>> +merge [options] <commit-ish1> <commit-ish2> ... <commit-ishN>::
> >>> +	Merge commits into HEAD.
> >> 
> >> Nice.
> >> 
> >> "HEAD" mean last picked up / created commit, isn't it?
> > 
> > Right. This is used throughout the document...
> > I thought it is clear and better to use than always describing around it
> > by "last created commit".
> 
> O.K.

I don't know.  If something like "last created commit" is better,
I have no problem to change it :)

quoted text
> >>> +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?

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

quoted text
> 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.)

quoted text
> >>> +squash [options] --from <mark>::
[...]
quoted text
> > 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 :)

quoted text
> >>> +	--include-merges;;
> >>> +		Sanity check does not fail if you have merges
> >>> +		between HEAD and <mark>.
> >> 
> >> How do you squash merges?  Creating merge with an union of parents,
> >> excluding commits which got squashed?
> > 
> > My squashes are realized using git reset --soft ... and then commit.
> > I think this makes only sense when there are no merges in between,
> > so I added the check, but if someone wants to squash merges, he should
> > be able to do it.
> >
> > To somehow answer your question: I do not care what the result is,
> > because I do not know what the result "should be".
> 
> O.K.  I guess that is something left for later, especially that
> forbidding merges in squashed commit is default (and you can always
> do without merges, I think).

Forbidding merges is default currently. It's just a sanity check. And
the option bypasses this check.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html