[Top][All Lists]

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

Re: CEDET Merge

From: Edward Steere
Subject: Re: CEDET Merge
Date: Wed, 18 Jan 2017 12:12:10 +0200

Patching does sound easier.

Given that we might be moving from upstream entirely it might be worth it to 
keep the commit history if we can though.  I know that git won't make is easy.

If we do go with patching though, and the changes are going to appear in the 
changelog then how are we going to go about doing that?  Would we use the 
add-change-log command on all of the commits since the last merge?

One disadvantage of all of this is that git blame results would be more 
difficult to interpret because the change and author would be documented 

> On 17 Jan 2017, at 11:23 PM, David Engster <address@hidden> wrote:
> Edward John Steere writes:
>> Our main concern is to maintain the commit history and I think that my
>> original approach of merging to CEDET and then back creates too much
>> noise.
> Merging to the CEDET repo is not needed, since we will abandon it
> anyway.
>> I think that the best way to go about this is to move everything in the
>> CEDET project into folders which mirror their destination in core.
>> Changes will be required for:
>> - The grammar files, which need to be in admin/grammars
>> - The tests, which need to be in test/manual/cedet
>> - The documentation files, which need to move to doc/misc (and
>>   should probably be flattened.)
>> Once moved we commit, add CEDET as a remote of Emacs and merge
>> CEDET/master allowing unrelated histories.
> I think it will be less work to simply do the diff|patch game and fixing
> a few paths along the way. Since the histories are unrelated, git cannot
> really help you with the merges anyway.
>> (I considered moving the tests, but they have history too and we'd have
>> to start splitting commits to get them across w/o the rest of upstream
>> CEDET.  Additionally there's nothing preventing the tests from being run
>> with CEDET in Emacs core.  Just start it with --no-init add the test
>> folder to the load path, load the relevant test file and run it.)
> I wouldn't worry too much about the history of the tests. The authorship
> of the changes should be clear, but at least I don't care much for
> granularity here.
> -David

reply via email to

[Prev in Thread] Current Thread [Next in Thread]