Hi Ragu, Ramkumar Ramachandra wrote: > Hi, > > On Mon, May 3, 2010 at 11:20 PM, Gelonida <gelonida@xxxxxxxxx> wrote: >> Is it normal, that git gets lost wehn rebasing such a structure. > > While performing an interactive rebase, conflicts can often occur and > this is quite normal. > >>> Automatic cherry-pick failed. After resolving the conflicts, >>> mark the corrected paths with 'git add <paths>', and >>> run 'git rebase --continue' >>> Could not apply 67f3f6d... preparation for #241 > > The problem and solution is described in that message. Open the file, > resolve the conflict and continue the rebase operation. Yes merging manually could be a theortical solution, but I really don't understand, why I should merge anything at all. The history is purely linear at the places where I want to squash. These two commits precede a few more consecutive commits, traverse then a tree which forks to multiple branches, which partially cherrypick from each other and will then join again to a unique linear sequence. If I have a history of several hundred commits and I am asked several times to merge, just because I want to squash two consecutve commits without any branches going out or in, then something (probably the way I try to attack the problem or much less likely a mysterious git bug) is kind of wrong. I'm still looking for a solution, where I specify only the commits to be squashed and everything else stays untouched without any further userinteraction -- 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