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:18:47 -0000	[thread overview]
Message-ID: <d62225a3cc5740cda7cb163a94d55892-mfwitten@gmail.com> (raw)
In-Reply-To: <1b66c8efe0214915be2c52a5aacd22de-mfwitten@gmail.com>

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 noticed that my script has another problem; the line:

  rebase_head=$commit

should be:

  rebase_head=$(git rev-parse HEAD)

I was trying to make an optimization, but it's the wrong
logic :-/

Sorry for the confusion. Here is an updated version of
the entire script:

  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

      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

      fi

      rebase_head=$(git rev-parse HEAD)

    done
  }

      parent reply	other threads:[~2011-08-04 14:22 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
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 [this message]

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=d62225a3cc5740cda7cb163a94d55892-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).