Hi Ragu,

Ramkumar Ramachandra wrote:
quoted text
> Hi,
> 
> On Mon, May 3, 2010 at 11:20 PM, Gelonida <gelonida@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html