Re: how to squash a few commits in the past

From: Gelonida <gelonida@gmail.com>
Date: May 5, 2010, 21:41 UTC
Message-ID: <4BE1E5F6.3040606@gmail.com>
In-Reply-To: <w2zf3271551005050619td67d697y97d7e9181c4496fc@mail.gmail.com>

Hi Ragu,

Ramkumar Ramachandra wrote:

Show 15 quoted lines

> 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