Re: [PATCH] git-merge: add option --no-ff
- From
- Lars Hjemli <hjemli@gmail.com>
- Date
- Sep 18, 2007, 12:03 UTC
- Message-ID
- <8c5c35580709180503g24ef6c5hda2877e2215ba58d@mail.gmail.com>
- In-Reply-To
- <46EFBB9A.5070404@vilain.net>
[...sorry for making this such a long thread...]
On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
Show 20 quoted lines
> 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)
Show 7 quoted lines
> > > 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