Subject: Re: how to squash a few commits in the past

From: Gelonida <[email-masked]>
Date: Wed, 05 May 2010 23:41:10 +0200

Hi Ragu,

Ramkumar Ramachandra wrote:
> Hi,
> 
> On Mon, May 3, 2010 at 11:20 PM, Gelonida <[email-masked]> 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