git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Witten <mfwitten@gmail.com>
To: Patricia Bittencourt Egeland <pbegeland@linea.gov.br>
Cc: Ricky Egeland <rickyegeland@linea.gov.br>, <git@vger.kernel.org>
Subject: Re: Cleaning up history with git rebase
Date: Thu, 04 Aug 2011 14:35:19 -0000	[thread overview]
Message-ID: <b3e1c29767984546a61e2d10fb180188-mfwitten@gmail.com> (raw)
In-Reply-To: <80e62eb56a83a138a79e112e382da4ae@linea.gov.br>

[Put your reply text below the quoted text.]

On Wed, 03 Aug 2011 17:58:26 -0300, Patricia Egeland wrote:

> On Mon, 01 Aug 2011 01:07:33 -0000, Michael Witten wrote:
>
>> Michael Witten wrote:
>>
>>> On Sun, 31 Jul 2011 18:44:43 -0300, Ricky, Egeland wrote:
>>>
>>>> On Jul 31, 2011, at 6:33 PM, Michael Witten wrote:
>>>>
>>>>> On Sun, Jul 31, 2011 at 20:21, Michael Witten <mfwitten@gmail.com> 
>>>>> wrote:
>>>>>> Why are there conflicts anyway?
>>>>>
>>>>> Oh...
>>>>>
>>>>> I guess there were conflicts when the merge commit was made in
>>>>> the original repository, and these conflicts were resolved by
>>>>> the merge commit itself. Hence, when rebase tries to split up
>>>>> a merge by dealing with just the non-merge parents, you end up
>>>>> having to deal with the conflict again.
>>>>
>>>> Yes, I thought it was something like this going on, too. In the
>>>> pre-rebase history, when there is a commit with "Conflict:" and
>>>> listing file which is in the sub-repository history, this is a
>>>> point where rebase stops with a conflict.
>>>>
>>>>> Shouldn't rebase take this into account?
>>>>
>>>> Not sure.  Seems that it does not, it makes me resolve the conflict 
>>>> =
>>>> again.
>>>
>>> I think git rebase should take this into account is what I'm saying.
>>>
>>> The following implements what I think `git rebase' should be doing;
>>> run it instead of `git rebase' in your repo:
>>>
>>>   git branch saved
>>>   git rev-list HEAD --reverse --first-parent --parents |
>>>   {
>>>     read root
>>>     git reset --hard $root
>>>     rebase_head=$root
>>>
>>>     while read commit first_parent other_parents; do
>>>
>>>       if [ -z "$other_parents" ]; then
>>>
>>>         git cherry-pick $commit
>>>         rebase_head=$commit
>>>
>>>       else
>>>
>>>         for parent in $other_parents; do
>>>
>>>           if ! git cherry-pick $parent; then
>>>
>>>             git reset --hard $rebase_head
>>>             git merge $other_parents
>>>             git rm -rf .
>>>             git checkout -- $commit
>>>             git commit -aC $commit
>>>             break
>>>
>>>           fi
>>>
>>>         done
>>>
>>>         rebase_head=$(git rev-parse HEAD)
>>>
>>>       fi
>>>
>>>     done
>>>   }
>>
>> Woops!
>>
>> This line:
>>
>>   git checkout -- $commit
>>
>> should be:
>>
>>   git checkout $commit -- .
>
>      I tried to run the script in my repo. However, seems like the 'git 
> merge $other_parents' process fails. In the script output I see some 
> lines saying that files were not able to be merged, ie:
>
> warning: Cannot merge binary files: 
> scienceportal/images/tabs/tabs-gray.png (HEAD vs. 
> 84f6fc283861aa7c5798f58769789dd0b91a5e9d)
> warning: Cannot merge binary files: scienceportal/images/waiting.gif 
> (HEAD vs. e033cbbf1e9d24b66cb55a04701c059dc945c1c3)
>
>      Do you have some suggestion?

That's probably as expected; the script is coming across the conflict, but
it should be taking care of the conflict automatically.

Unfortunately, though, the results probably end up being almost completely
similar to the original un-rebased branch because the original script
actually has ANOTHER mistake (sorry!). See the updated version here (or
in your inbox):

  http://marc.info/?l=git&m=131246773005168&w=2
  Message-ID: <d62225a3cc5740cda7cb163a94d55892-mfwitten@gmail.com>

  reply	other threads:[~2011-08-04 14:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-31 17:20 Cleaning up history with git rebase Ricky Egeland
2011-07-31 20:21 ` Michael Witten
2011-07-31 21:33   ` Michael Witten
2011-07-31 21:44     ` Ricky Egeland
2011-08-01  1:02       ` Michael Witten
2011-08-01  1:07         ` Michael Witten
2011-08-03 20:58           ` pbegeland
2011-08-04 14:35             ` Michael Witten [this message]
2011-08-05 21:26               ` pbegeland
2011-08-06 23:59                 ` Michael Witten
2011-08-09 12:29                   ` pbegeland
2011-08-04 14:18           ` Michael Witten

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b3e1c29767984546a61e2d10fb180188-mfwitten@gmail.com \
    --to=mfwitten@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pbegeland@linea.gov.br \
    --cc=rickyegeland@linea.gov.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).