On Fri, 05 Aug 2011 18:26:27 -0300, Patricia Egeland wrote:
>> On Thu, 04 Aug 2011 14:35:19 -0000, Michael Witten wrote:
>>
>> [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@xxxxxxxxx>
>>>>>>> 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@xxxxxxxxx>
>
>
> Thanks for taking a look at it again.
> I tried to run the script with that update, but in the end I got more
> merge messages than I had originally. (71 additional merges. From those
> 71, I got 53 "Merge commit" messages. While in the saved repo I have 1
> "Merge commit".). Do you see what may be causing that?
>
> Another thing I noticed is that the auto-merging is still failing:
>
> fatal: Commit b0596fce207735081b8aa9afdd9686b7d412f5d8 is a merge but
> no -m option was given.
> HEAD is now at ac5eaa2 *Continue Last Commit*
> Auto-merging scienceportal/css/myprofile.css
> CONFLICT (content): Merge conflict in scienceportal/css/myprofile.css
> Auto-merging scienceportal/css/qc.css
> Automatic merge failed; fix conflicts and then commit the result.
> scienceportal/css/myprofile.css: needs merge
> rm 'scienceportal/css/des.css'
>
> Looking at this thread:
> http://www.mail-archive.com/git-users@xxxxxxxxxxxxxxxx/msg01046.html
> I thought that the attempt of removing the files was the step first
> facing the conflicts as the one shown above. So that, I tried to iterate
> through the files and in case the removal of any file failed, I added
> the steps as suggested in the thread:
> git checkout --theirs $file
> git add $file
> git commit -m 'Fixing conflict during rebase'
>
> But that didn't work either.
>
> I'd be greatly appreciated if you are still willing to help.
Those error messages are expected, but my original script is
incredibly naive (to the point of being incorrect).
Fortunately, I've thought a bit more about it, and I have a much
better solution in the works, so please hold on just a bit longer
while I work out the kinks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html