Sounds reasonable to me. Let's try it the next time we add an engine version.
On Fri, May 13, 2022 at 12:14 AM Kyle Bendickson <k...@tabular.io> wrote: > I agree this is a good point. > > The git history is not retained when we port the way we currently do. > > So +1 as I understand it, the latest version will generally be the one to > have the most git commit history. Possibly looking back for changes that > occurred due to some other version. > > Thanks Liwei! > > - Kyle > > On Fri, May 13, 2022 at 12:10 AM Rajarshi Sarkar <rsarkar...@gmail.com> > wrote: > >> +1, good point. >> >> Regards, >> Rajarshi Sarkar >> >> >> On Fri, May 13, 2022 at 9:03 AM Reo Lei <leinuo...@gmail.com> wrote: >> >>> That is great ! +1 for this. >>> >>> liwei li <hilili...@gmail.com> 于2022年5月13日周五 11:12写道： >>> >>>> Correct a clerical errr: >>>> >>>> 3. Modify the v3.3 files to make it work for spark 3.3 correct. >>>> >>>> Liwei Li >>>> ------------------------------ >>>> *From:* Steven Wu <stevenz...@gmail.com> >>>> *Sent:* Friday, May 13, 2022 11:06:26 AM >>>> *To:* dev@iceberg.apache.org <dev@iceberg.apache.org> >>>> *Subject:* Re: [discuss] keep the commit history when adding a new >>>> engine version >>>> >>>> This is a good point. +1 for the proposal. >>>> >>>> On Thu, May 12, 2022 at 7:46 PM liwei li <hilili...@gmail.com> wrote: >>>> >>>> Hi, guys >>>> When we want to add support for a new version of an engine, simply >>>> copying files from an old version to a new directory will cause git commit >>>> history to be lost, making it difficult to find file change records, we can >>>> only go to look for changes in the old path, but we don't know it in which >>>> one, and the old may have been deleted. Is there a better way to keep it? >>>> I recommend that we first rename the old version to the new one, and >>>> then make a new copy as the old version. >>>> For example, if we want to add Spark 3.3, we can do the following: >>>> 1. Change the path of version 3.2 from v3.2 to v3.3 >>>> 2. Create a copy of v3.2 from v3.3 >>>> 3. Modify the v3.2 file to make it work for spark 3.3 correct. >>>> What do you think of the above? Or is it necessary? Or if there is >>>> another better way? >>>> Thank you. >>>> >>>> Liwei Li >>>> hilili...@gmail.com >>>> >>>> -- Ryan Blue Tabular
