Re: [PATCH 2/5] add object-cache infrastructure

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

 



On 7/11/2011 6:21 PM, Junio C Hamano wrote:
> Jeff King<peff@xxxxxxxx>  writes:
>
>> ... But with a commit no top, you get:
>>
>>    <<<<<<<  HEAD
>>    two
>>    =======
>>    one
>>    >>>>>>>  one
>>
>> which looks like you are reverting, because of course you are building
>> on top of the finished series.
> Exactly.
>
>>    $ git rebase master topic
>>    Applying: one
>>    Using index info to reconstruct a base tree...
>>    Falling back to patching base and 3-way merge...
>>    Auto-merging file
>>    CONFLICT (content): Merge conflict in file
>>    Failed to merge in the changes.
>>    Patch failed at 0001 one
>>
>>    hint: this commit may already be in upstream as 1234abcd;
>>    hint: the differences between that commit and this one are:
>>
>>    diff --git a/file b/file
>>    --- a/file
>>    +++ b/file
>>    @@ -1 +1 @@
>>    -modified one
>>    +one
>>
>>    When you have resolved this problem run "git rebase --continue".
>>    If you would prefer to skip this patch, instead run "git rebase --skip".
>>    To restore the original branch and stop rebasing run "git rebase --abort".
> Actually I do not think identifying the ones that can safely skipped is
> such a big issue. The case I am most concerned about is when you see that
> "two reverted back to one" (which you obviously want to avoid, to keep the
> effect of the commit the upstream has to have "two" on that line), but at
> the same time when you do not agree with the change that the upstream took
> for the _current commit_ you are replaying (i.e. you want the final result
> to have "one", not "modified one" which the upstream has applied).
>
> The conflict resolution to come up with such an incremental change is very
> painful. You have to avoid the "s/two/one/" revert, and you have to keep
> the "s/modified one/one" revert, and you need to know which hunks are
> conflicting due to what (i.e. the former is because a patch similar to the
> one you haven't replayed in this rebase session is already in upstream,
> the latter is the upstream tweaked the current patch you are looking at in
> a way you do not agree with).
>
> I do not have a good idea to solve this in mind yet.

I am not 100% sure that my solution is exactly about this problem, but 
it seems to be quite relevant.

I think that if you rebase "step-by-step" by doing, for this particular 
example, something like

$ git rebase master^ topic
$ git rebase master topic

You will first see the /modified one/one/ conflict that you will resolve 
your "two" against and then your second rebase will apply with no conflicts.

I have a set of scripts that help me do this kind of rebases by 
essentially rebasing the topic branch against every single commit on the 
upstream.

This way I can clearly see every conflict as at appears and can fix it 
even in cases when a rebase against the final state would give an 
absolutely unbearable diff.

It definitely is much slower but in my case I find this to be the only 
possible solution.  rerere helps enormously here.
At the same time the less changes are in topic...master the faster it 
would be and the more changes are there the more you benefit from a 
gradual rebase.


Here is the actual use case in case I was not very clear above or in 
case someone is interested.

I have a very longed lived branch that I have to rebase against an 
actively developed master.
Besides been longed live the branch contains a lot of absolutely 
unrelated changes.

The branch is a "next version branch" and contains a result of a two 
year work done by two people who though that their version of the 
application will become master "tomorrow", so they where not too shy to 
change things.

The upstream is developed by another 6 - 8 people over 3 years and they 
have no knowledge of the changes done in the "next version branch".

Here is were I step in and am told to get the changes from the next 
version branch onto the master.  And I am not part of either of these 
two groups of people.

In addition to that one of the guys who developed the next version has 
left the company before I joined and the other one is also gone by now.

While it seems pretty crazy to me, thanks to git rebase, git rerere and 
the "step-by-step" rebase I am at my 9th rebase of this topic branch 
through last year and had only minor problems so far.

Essentially now we have 6 people developing the application "in the 
middle" of its history with one person trying to hold the rest of the 
history on top.
I imagine this as a kind of an acrobatic trick worth showing in a circus :)

Ilya Bobyr--
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]