Re: Cleaning up history with git rebase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]