Hi, 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@xxxxxxxxx> 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 :) > >>> +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". > 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.) > >>> +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 :) > >>> + --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@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
