I believe you're running into *merge conflicts *with*the parser changes
*and/or*directory structure changes*.
Because the old repo and the new repo aren't considered forks
and because - strictly speaking - don't share any git history (every
historic commit was rewritten during the split-up),
git can't do any of it's merging magic.
So you're stuck with plain old patches (like in SVN) and *those patches
are stale*.
Originally, the plan was that you just merge your old repository until
the last non-splitting up commit:
You 'll probably run into merge conflicts with the parser changes too,
but they might be easier to fix.
Then create a patch from that, and apply it to the drools git repository
(probably with merge conflicts again).
Drools-core/compiler were not stable (= runnable) when they were
split-up (so in that commit revision):
Edson and Mark local branches had to applied on master to be migrated
and they collided.
If your patch also applies on files outside directories drools-core and
drools-compiler, such as drools-api (now knowledge-api), guvnor-webapp, etc
then manually split up that patch file into 2 patch files.
An alternative you can try, is fork on an old commit revision of drools
(note: the tags could not be migrated during the split-up):
then apply your patch on a branch of that and then merge HEAD to that
branch (which will give you those merge conflicts again, but with git's
merging magic).
Sorry that I can't help more :( Stale patches sux.
Op 03-04-11 09:27, Leonardo Gomes schreef:
Here's what I'm trying to do and haven't succeed so far:
*- Create a patch from my branch in droolsjbpm: *
https://github.com/droolsjbpm/droolsjbpm/commits/lr_unlinking_20101116
I forked, cloned and checked-out lr_unlinking_20101116. Then I tried
to different ways of generating a patch
- git diff revision HEAD > myPatch.diff
- git format-patch -k --stdout revision..HEAD > myPatch.patch
*- Apply the patch to my fork of drools: *
https://github.com/leogomes/drools
First let's have a look at the stats:
- git apply --stat ../droolsjbpm/drools-core/myPatch.patch
Then verify (and fail!):
leo@leonardo-laptop:~/java/drools/git/drools/drools-core$ git apply
--check ../droolsjbpm/drools-core/myPatch.patch
error: patch failed:
drools-core/src/main/java/org/drools/RuleBaseConfiguration.java:100
error:
drools-core/src/main/java/org/drools/RuleBaseConfiguration.java: patch
does not apply
(...)
I'm trying first with drools-core and then have to do the same for
drools-compiler and api.
Any hint or another approach to suggest?
Thanks,
Leo.
On Fri, Apr 1, 2011 at 9:12 AM, Geoffrey De Smet
<ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com>> wrote:
If you're building the first time since the split-up, do take a
look at the README to avoid all kinds of pitfalls:
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/READ...
It also talks about using UTF-8 encoding, unix (\n) line endings
(in non-java files too), ...
Op 01-04-11 08:49, Leonardo Gomes schreef:
> I managed to fork/clone and get diffs from everything I did, but
> I still need to install Maven 3 and make it coexist with Maven 2
> to be able to compile and test. Should be applying the patches
> later today, hopefully.
>
> Thanks, Geoffrey.
>
>
> On Thu, Mar 31, 2011 at 7:02 PM, Geoffrey De Smet
> <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com>> wrote:
>
>
>
> Op 31-03-11 17:25, Leonardo Gomes schreef:
>> Hello Guys,
>>
>> I didn't actually followed-up on all emails about the Git
>> repository, but I think that it should be simple.
>>
>> *Problem:*
>> I would like to manually apply the changes that I did into
>> lr_unlinking_20101116 branch (+ some other changes I didn't
>> commit yet) to the newly split repositories.
>> I modified: drools-api, drools-core, drools-compiler.
>>
>> *Solution:*
>> - Fork
https://github.com/droolsjbpm/droolsjbpm-knowledge
>> for the drools-api changes
>> and
https://github.com/droolsjbpm/drools for the others
>> (core and compiler).
>>
> and clone your forks
>> - Manually apply my patches
> locally, and then commit and push to your forks
>> , create a pull request.
> 2 probably, one for each repository
> but yes, that should work :)
>
>>
>> Is that correct? Anything else to keep in mind?
>>
>> Thanks,
>> Leonardo.
>>
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev