Re: [PATCH] git-merge: add option --no-ff

["Lars Hjemli" <hjemli@gmail.com>]

[...sorry for making this such a long thread...]

On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> Lars Hjemli wrote:
> > On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> >
> >> I think that writing a real fast-forward merge should only happen on
> >> dcommit, not git merge, because that is what is required for SVN.
> >>
> >
> > I don't think git-svn has any way of knowing that the user wanted a
> > merge, unless a merge commit is present. So the user would have to
> > specify the set of commits which should be considered a merge during
> > dcommit (this would actually resemble how merges are performed in
> > subversion).
> >
>
> Sure it can.  If you're committing to branch X, and the current tree has
> a whole lot of commits above that, then it should do the only thing you
> can do with SVN.
>
> Which is write a squash commit, and set the "svn:merge" and/or
> "svk:merge" properties to represent what happened.

I often have prepared a series of local commits which I _want_ to
preserve as different subversion revisions.

Also, doing a --squash means that I loose the merge history in git
(and then I need to edit the grafts file again)

>
> > Sidenote: this might be slightly controversial, but I've sometimes
> > missed a --no-ff option to 'git merge' when working on plain git
> > repositories; IMHO preserving the 'logical' merge history when the
> > merge of a topic branch results in a fast-forward can be interesting.
>
> If you really want one, use git commit-tree directly.

Yeah, that's an option, but --no-ff is somewhat less work ;-)

--
larsh