Lars Hjemli wrote: > [...sorry for making this such a long thread...] > > On 9/18/07, Sam Vilain <sam@xxxxxxxxxx> wrote: > >> Lars Hjemli wrote: >> >>> On 9/18/07, Sam Vilain <sam@xxxxxxxxxx> 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. > But for the scenario we are discussing the revisions already exist upstream otherwise there would be no fast forward merge. So, if you want that behaviour you can use cherry-pick on the git side and the correct behaviour for git-svn is to write svn merge properties. > Also, doing a --squash means that I loose the merge history in git > (and then I need to edit the grafts file again) > There is no merge history in git, it was a fast forward. >>> 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 ;-) > Sure. I just don't see a good use case for it from this yet. Sam. - 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
