You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Vishwas Babu <vi...@confluxtechnologies.com> on 2016/01/30 02:45:53 UTC
Missing git history
Hi,
https://github.com/apache/incubator-fineract doesn't carry over the commit
history from https://github.com/openMF/mifosx.
Given that the MifosX platform has been around for a few years now,
numerous organizations maintain multiple forks of the same . Without the
commit history being carried over, upgrading these forks becomes an
unnecessarily painful process.
Also, the contribution history of around 78 volunteers to the original
MifosX project is lost.
Is there any reason for initializing fineract as a new git repository ?
Regards,
Vishwas
Re: Missing git history
Posted by Greg Stein <gs...@gmail.com>.
"git would not be able to detect the move"
... my Subversion background just wants to say something about that ... oh.
Just did.
:-P
On Sat, Jan 30, 2016 at 3:35 AM, Markus Geiß <ma...@live.de> wrote:
> Vishwas,
>
> given that the core team has done the renaming and relicensing in one
> commit,
> git would not be able to detect the move. All files will be detached from
> the history
> anyways. Git compares files by tree and their BLOB, the changed files lead
> to a
> new BLOB in a new tree so git would recognize them as new not changed
> files.
>
> The risk to 'act' like there is a history and others using the Apache repo
> as the new
> upstream, loosing there files by accident b/c the files are 'deleted' was
> simply too
> high.
>
> If we like to preserve the history all changes need to be reverted and
> every single step
> needs to be in its own commit.
>
> It would also not be feasible to move the whole repo over, because we only
> can move
> the recent develop. All open branches, and release branches should not be
> moved
> for clarity reasons and to avoid confusion.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > Date: Sat, 30 Jan 2016 13:02:26 +0530
> > Subject: Re: Missing git history
> > From: vishwas@confluxtechnologies.com
> > To: dev@fineract.incubator.apache.org
> >
> > Markus,
> >
> > Git does an excellent job of recognizing renamed files. Merging forks
> with
> > the new package structure is a very straightforward process.
> >
> > What is the issue with retaining the commit history ?
> >
> > Regards,
> > Vishwas
> >
> >
> >
> >
> >
> > On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> >
> > >
> > >
> > > Hey Vishwas,
> > >
> > >
> > > The repackeging led to a delete and add of all files anyways, so a
> simple
> > > fetch merge could cause more harm than the creation of a new fork and
> > > manually transfer made changes to the code that never where contributed
> > > back.
> > >
> > >
> > > In addition I'd suggest to do future code enhancements in a way that
> > > allows either a contribution back or keeps the forked base clean and
> > > mergable.
> > >
> > >
> > > Best,
> > >
> > >
> > > Markus
> > >
> > >
> > > .:: YAGNI likes a DRY KISS ::.
> > >
> > >
> > >
> > > From: Vishwas Babu
> > >
> > > Sent: Saturday, January 30, 02:46
> > >
> > > Subject: Missing git history
> > >
> > > To: dev@fineract.incubator.apache.org
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > > https://github.com/apache/incubator-fineract doesn't carry over the
> commit
> > >
> > > history from https://github.com/openMF/mifosx.
> > >
> > >
> > > Given that the MifosX platform has been around for a few years now,
> > >
> > > numerous organizations maintain multiple forks of the same . Without
> the
> > >
> > > commit history being carried over, upgrading these forks becomes an
> > >
> > > unnecessarily painful process.
> > >
> > >
> > > Also, the contribution history of around 78 volunteers to the original
> > >
> > > MifosX project is lost.
> > >
> > >
> > > Is there any reason for initializing fineract as a new git repository ?
> > >
> > >
> > > Regards,
> > >
> > > Vishwas
> > >
> > >
> > >
> > >
>
>
Re: Missing git history
Posted by Myrle Krantz <mk...@mifos.org>.
Vishwas and Markus have both given us their thoughts on the matter. I don't know if it's possible to import the commit history now, but even assuming it is, I would give precedence to the work already performed *if* no one else has an opinion.
Does anyone else here have an opinion?
My opinion for the record: I'm a bit sad about the loss of history, but if I need it, I can get it from the MifosX repository. I'm glad to have a clean start with respect to version branches, though I imagine I could find a branch naming scheme in which the existing version branches would not represent too much of an obstacle. But on the whole I'm not significantly bothered by the way Markus did the initial commit and I am grateful he did the work. It would not be worthwhile to me personally to redo this. If the *community* wants it though, I would be okay with that too.
Greets,
Myrle Krantz
> On 30.01.2016, at 11:25, Vishwas Babu <vi...@confluxtechnologies.com> wrote:
>
> Markus,
>
> I would assume that redoing the same, i.e changing the package structure in
> an IDE and then re-licencing (a search replace) shouldn't take much time at
> all for the core team.
>
> Anyone maintaining a fork would be conversant enough with GIT to understand
> what he / she are doing. Given that the fineract community isn't forcing
> someone to use the new codebase as their upstream, I do not buy the
> argument that this is a high risk for the community.
>
> The Mifos community has always ensured that all releases are merged back
> into both master / develop branch. So migrating any one of them to fineract
> is all that a fork maintainer would need to update his fork.
>
> Further, if you would poll the top 5 contributors to the Mifos platform
> (myself included), I am sure that all things being equal we would all want
> to maintain the commit history, unless there is a real reason to not do so.
>
> Regards,
> Vishwas
>
>
>> On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de> wrote:
>>
>> Vishwas,
>>
>> given that the core team has done the renaming and relicensing in one
>> commit,
>> git would not be able to detect the move. All files will be detached from
>> the history
>> anyways. Git compares files by tree and their BLOB, the changed files lead
>> to a
>> new BLOB in a new tree so git would recognize them as new not changed
>> files.
>>
>> The risk to 'act' like there is a history and others using the Apache repo
>> as the new
>> upstream, loosing there files by accident b/c the files are 'deleted' was
>> simply too
>> high.
>>
>> If we like to preserve the history all changes need to be reverted and
>> every single step
>> needs to be in its own commit.
>>
>> It would also not be feasible to move the whole repo over, because we only
>> can move
>> the recent develop. All open branches, and release branches should not be
>> moved
>> for clarity reasons and to avoid confusion.
>>
>> Best,
>>
>> Markus
>>
>> .::YAGNI likes a DRY KISS::.
>>
>>> Date: Sat, 30 Jan 2016 13:02:26 +0530
>>> Subject: Re: Missing git history
>>> From: vishwas@confluxtechnologies.com
>>> To: dev@fineract.incubator.apache.org
>>>
>>> Markus,
>>>
>>> Git does an excellent job of recognizing renamed files. Merging forks
>> with
>>> the new package structure is a very straightforward process.
>>>
>>> What is the issue with retaining the commit history ?
>>>
>>> Regards,
>>> Vishwas
>>>
>>>
>>>
>>>
>>>
>>>> On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
>>>>
>>>>
>>>>
>>>> Hey Vishwas,
>>>>
>>>>
>>>> The repackeging led to a delete and add of all files anyways, so a
>> simple
>>>> fetch merge could cause more harm than the creation of a new fork and
>>>> manually transfer made changes to the code that never where contributed
>>>> back.
>>>>
>>>>
>>>> In addition I'd suggest to do future code enhancements in a way that
>>>> allows either a contribution back or keeps the forked base clean and
>>>> mergable.
>>>>
>>>>
>>>> Best,
>>>>
>>>>
>>>> Markus
>>>>
>>>>
>>>> .:: YAGNI likes a DRY KISS ::.
>>>>
>>>>
>>>>
>>>> From: Vishwas Babu
>>>>
>>>> Sent: Saturday, January 30, 02:46
>>>>
>>>> Subject: Missing git history
>>>>
>>>> To: dev@fineract.incubator.apache.org
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>> https://github.com/apache/incubator-fineract doesn't carry over the
>> commit
>>>>
>>>> history from https://github.com/openMF/mifosx.
>>>>
>>>>
>>>> Given that the MifosX platform has been around for a few years now,
>>>>
>>>> numerous organizations maintain multiple forks of the same . Without
>> the
>>>>
>>>> commit history being carried over, upgrading these forks becomes an
>>>>
>>>> unnecessarily painful process.
>>>>
>>>>
>>>> Also, the contribution history of around 78 volunteers to the original
>>>>
>>>> MifosX project is lost.
>>>>
>>>>
>>>> Is there any reason for initializing fineract as a new git repository ?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Vishwas
>>
>>
Re: Missing git history
Posted by ma...@live.de.
Thanks for the clarification ...
Best,
Markus
.:: YAGNI likes a DRY KISS ::.
On Sat, Jan 30, 2016 at 6:43 AM -0800, "Greg Stein" <gs...@gmail.com> wrote:
The ASF has zero problem if version control contains history that does not
conform to its policies.
The "rules" really come into play when a source [tarball] release is made.
*That* needs to conform. Anything leading up to it ... meh.
Recall: releases are made when (3) PMC members vote +1, which establishes
that release as an official action/release of the Foundation. Something
sitting in version control is not blessed in that way, so it does not
impinge/bother the Foundation and its goals.
Another way to look at it: there is no such thing as a "passive" release.
The ASF rules only apply to voted releases.
Cheers,
-g
On Sat, Jan 30, 2016 at 6:07 AM, Markus Geiß <ma...@live.de> wrote:
> That is a good question ... I'd assume that given we remove the hard
> dependency
> on Pentaho and change the license headers to Apache, we should fulfill
> legal
> policies, even if the history holds some things that don't comply to them.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > From: sandervanderheyden@musoni.eu
> > Subject: Re: Missing git history
> > Date: Sat, 30 Jan 2016 12:47:31 +0100
> > To: dev@fineract.incubator.apache.org
> >
> > Hi guys,
> >
> > +1 from me on keeping history, it has proven to be very useful in
> troubleshooting and debugging manier time.
> >
> > I'm not a git guru but sounds like technically it shouldn't be a
> problem. To what extent are there any compilations from a legal and
> licensing perspective?
> >
> > S
> >
> > Sent from my iPhone
> >
> > > On 30 Jan 2016, at 11:49, <ma...@live.de> <ma...@live.de>
> wrote:
> > >
> > >
> > >
> > > I can understand your concern ... and if we agree on doing so ... I'm
> fine with reverting the changes ... clean the repo again ... and pull in
> develop only ...
> > >
> > >
> > > I did not say that keeping the history in general is a risk, all I've
> said is keeping the history as it is now holds some risk.
> > >
> > >
> > > Aside from that keeping the history only to keep contributors
> mentioned is not an argument to me.
> > >
> > >
> > > Best,
> > >
> > >
> > > Markus
> > >
> > >
> > > .:: YAGNI likes a DRY KISS ::.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <
> vishwas@confluxtechnologies.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > > Markus,
> > >
> > > I would assume that redoing the same, i.e changing the package
> structure in
> > > an IDE and then re-licencing (a search replace) shouldn't take much
> time at
> > > all for the core team.
> > >
> > > Anyone maintaining a fork would be conversant enough with GIT to
> understand
> > > what he / she are doing. Given that the fineract community isn't
> forcing
> > > someone to use the new codebase as their upstream, I do not buy the
> > > argument that this is a high risk for the community.
> > >
> > > The Mifos community has always ensured that all releases are merged
> back
> > > into both master / develop branch. So migrating any one of them to
> fineract
> > > is all that a fork maintainer would need to update his fork.
> > >
> > > Further, if you would poll the top 5 contributors to the Mifos platform
> > > (myself included), I am sure that all things being equal we would all
> want
> > > to maintain the commit history, unless there is a real reason to not
> do so.
> > >
> > > Regards,
> > > Vishwas
> > >
> > >
> > >> On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de>
> wrote:
> > >>
> > >> Vishwas,
> > >>
> > >> given that the core team has done the renaming and relicensing in one
> > >> commit,
> > >> git would not be able to detect the move. All files will be detached
> from
> > >> the history
> > >> anyways. Git compares files by tree and their BLOB, the changed files
> lead
> > >> to a
> > >> new BLOB in a new tree so git would recognize them as new not changed
> > >> files.
> > >>
> > >> The risk to 'act' like there is a history and others using the Apache
> repo
> > >> as the new
> > >> upstream, loosing there files by accident b/c the files are 'deleted'
> was
> > >> simply too
> > >> high.
> > >>
> > >> If we like to preserve the history all changes need to be reverted and
> > >> every single step
> > >> needs to be in its own commit.
> > >>
> > >> It would also not be feasible to move the whole repo over, because we
> only
> > >> can move
> > >> the recent develop. All open branches, and release branches should
> not be
> > >> moved
> > >> for clarity reasons and to avoid confusion.
> > >>
> > >> Best,
> > >>
> > >> Markus
> > >>
> > >> .::YAGNI likes a DRY KISS::.
> > >>
> > >>> Date: Sat, 30 Jan 2016 13:02:26 +0530
> > >>> Subject: Re: Missing git history
> > >>> From: vishwas@confluxtechnologies.com
> > >>> To: dev@fineract.incubator.apache.org
> > >>>
> > >>> Markus,
> > >>>
> > >>> Git does an excellent job of recognizing renamed files. Merging forks
> > >> with
> > >>> the new package structure is a very straightforward process.
> > >>>
> > >>> What is the issue with retaining the commit history ?
> > >>>
> > >>> Regards,
> > >>> Vishwas
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>> Hey Vishwas,
> > >>>>
> > >>>>
> > >>>> The repackeging led to a delete and add of all files anyways, so a
> > >> simple
> > >>>> fetch merge could cause more harm than the creation of a new fork
> and
> > >>>> manually transfer made changes to the code that never where
> contributed
> > >>>> back.
> > >>>>
> > >>>>
> > >>>> In addition I'd suggest to do future code enhancements in a way that
> > >>>> allows either a contribution back or keeps the forked base clean and
> > >>>> mergable.
> > >>>>
> > >>>>
> > >>>> Best,
> > >>>>
> > >>>>
> > >>>> Markus
> > >>>>
> > >>>>
> > >>>> .:: YAGNI likes a DRY KISS ::.
> > >>>>
> > >>>>
> > >>>>
> > >>>> From: Vishwas Babu
> > >>>>
> > >>>> Sent: Saturday, January 30, 02:46
> > >>>>
> > >>>> Subject: Missing git history
> > >>>>
> > >>>> To: dev@fineract.incubator.apache.org
> > >>>>
> > >>>>
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>>
> > >>>> https://github.com/apache/incubator-fineract doesn't carry over the
> > >> commit
> > >>>>
> > >>>> history from https://github.com/openMF/mifosx.
> > >>>>
> > >>>>
> > >>>> Given that the MifosX platform has been around for a few years now,
> > >>>>
> > >>>> numerous organizations maintain multiple forks of the same . Without
> > >> the
> > >>>>
> > >>>> commit history being carried over, upgrading these forks becomes an
> > >>>>
> > >>>> unnecessarily painful process.
> > >>>>
> > >>>>
> > >>>> Also, the contribution history of around 78 volunteers to the
> original
> > >>>>
> > >>>> MifosX project is lost.
> > >>>>
> > >>>>
> > >>>> Is there any reason for initializing fineract as a new git
> repository ?
> > >>>>
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>> Vishwas
> > >>
> > >>
>
>
Re: Missing git history
Posted by Greg Stein <gs...@gmail.com>.
The ASF has zero problem if version control contains history that does not
conform to its policies.
The "rules" really come into play when a source [tarball] release is made.
*That* needs to conform. Anything leading up to it ... meh.
Recall: releases are made when (3) PMC members vote +1, which establishes
that release as an official action/release of the Foundation. Something
sitting in version control is not blessed in that way, so it does not
impinge/bother the Foundation and its goals.
Another way to look at it: there is no such thing as a "passive" release.
The ASF rules only apply to voted releases.
Cheers,
-g
On Sat, Jan 30, 2016 at 6:07 AM, Markus Geiß <ma...@live.de> wrote:
> That is a good question ... I'd assume that given we remove the hard
> dependency
> on Pentaho and change the license headers to Apache, we should fulfill
> legal
> policies, even if the history holds some things that don't comply to them.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > From: sandervanderheyden@musoni.eu
> > Subject: Re: Missing git history
> > Date: Sat, 30 Jan 2016 12:47:31 +0100
> > To: dev@fineract.incubator.apache.org
> >
> > Hi guys,
> >
> > +1 from me on keeping history, it has proven to be very useful in
> troubleshooting and debugging manier time.
> >
> > I'm not a git guru but sounds like technically it shouldn't be a
> problem. To what extent are there any compilations from a legal and
> licensing perspective?
> >
> > S
> >
> > Sent from my iPhone
> >
> > > On 30 Jan 2016, at 11:49, <ma...@live.de> <ma...@live.de>
> wrote:
> > >
> > >
> > >
> > > I can understand your concern ... and if we agree on doing so ... I'm
> fine with reverting the changes ... clean the repo again ... and pull in
> develop only ...
> > >
> > >
> > > I did not say that keeping the history in general is a risk, all I've
> said is keeping the history as it is now holds some risk.
> > >
> > >
> > > Aside from that keeping the history only to keep contributors
> mentioned is not an argument to me.
> > >
> > >
> > > Best,
> > >
> > >
> > > Markus
> > >
> > >
> > > .:: YAGNI likes a DRY KISS ::.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <
> vishwas@confluxtechnologies.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > > Markus,
> > >
> > > I would assume that redoing the same, i.e changing the package
> structure in
> > > an IDE and then re-licencing (a search replace) shouldn't take much
> time at
> > > all for the core team.
> > >
> > > Anyone maintaining a fork would be conversant enough with GIT to
> understand
> > > what he / she are doing. Given that the fineract community isn't
> forcing
> > > someone to use the new codebase as their upstream, I do not buy the
> > > argument that this is a high risk for the community.
> > >
> > > The Mifos community has always ensured that all releases are merged
> back
> > > into both master / develop branch. So migrating any one of them to
> fineract
> > > is all that a fork maintainer would need to update his fork.
> > >
> > > Further, if you would poll the top 5 contributors to the Mifos platform
> > > (myself included), I am sure that all things being equal we would all
> want
> > > to maintain the commit history, unless there is a real reason to not
> do so.
> > >
> > > Regards,
> > > Vishwas
> > >
> > >
> > >> On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de>
> wrote:
> > >>
> > >> Vishwas,
> > >>
> > >> given that the core team has done the renaming and relicensing in one
> > >> commit,
> > >> git would not be able to detect the move. All files will be detached
> from
> > >> the history
> > >> anyways. Git compares files by tree and their BLOB, the changed files
> lead
> > >> to a
> > >> new BLOB in a new tree so git would recognize them as new not changed
> > >> files.
> > >>
> > >> The risk to 'act' like there is a history and others using the Apache
> repo
> > >> as the new
> > >> upstream, loosing there files by accident b/c the files are 'deleted'
> was
> > >> simply too
> > >> high.
> > >>
> > >> If we like to preserve the history all changes need to be reverted and
> > >> every single step
> > >> needs to be in its own commit.
> > >>
> > >> It would also not be feasible to move the whole repo over, because we
> only
> > >> can move
> > >> the recent develop. All open branches, and release branches should
> not be
> > >> moved
> > >> for clarity reasons and to avoid confusion.
> > >>
> > >> Best,
> > >>
> > >> Markus
> > >>
> > >> .::YAGNI likes a DRY KISS::.
> > >>
> > >>> Date: Sat, 30 Jan 2016 13:02:26 +0530
> > >>> Subject: Re: Missing git history
> > >>> From: vishwas@confluxtechnologies.com
> > >>> To: dev@fineract.incubator.apache.org
> > >>>
> > >>> Markus,
> > >>>
> > >>> Git does an excellent job of recognizing renamed files. Merging forks
> > >> with
> > >>> the new package structure is a very straightforward process.
> > >>>
> > >>> What is the issue with retaining the commit history ?
> > >>>
> > >>> Regards,
> > >>> Vishwas
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>> Hey Vishwas,
> > >>>>
> > >>>>
> > >>>> The repackeging led to a delete and add of all files anyways, so a
> > >> simple
> > >>>> fetch merge could cause more harm than the creation of a new fork
> and
> > >>>> manually transfer made changes to the code that never where
> contributed
> > >>>> back.
> > >>>>
> > >>>>
> > >>>> In addition I'd suggest to do future code enhancements in a way that
> > >>>> allows either a contribution back or keeps the forked base clean and
> > >>>> mergable.
> > >>>>
> > >>>>
> > >>>> Best,
> > >>>>
> > >>>>
> > >>>> Markus
> > >>>>
> > >>>>
> > >>>> .:: YAGNI likes a DRY KISS ::.
> > >>>>
> > >>>>
> > >>>>
> > >>>> From: Vishwas Babu
> > >>>>
> > >>>> Sent: Saturday, January 30, 02:46
> > >>>>
> > >>>> Subject: Missing git history
> > >>>>
> > >>>> To: dev@fineract.incubator.apache.org
> > >>>>
> > >>>>
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>>
> > >>>> https://github.com/apache/incubator-fineract doesn't carry over the
> > >> commit
> > >>>>
> > >>>> history from https://github.com/openMF/mifosx.
> > >>>>
> > >>>>
> > >>>> Given that the MifosX platform has been around for a few years now,
> > >>>>
> > >>>> numerous organizations maintain multiple forks of the same . Without
> > >> the
> > >>>>
> > >>>> commit history being carried over, upgrading these forks becomes an
> > >>>>
> > >>>> unnecessarily painful process.
> > >>>>
> > >>>>
> > >>>> Also, the contribution history of around 78 volunteers to the
> original
> > >>>>
> > >>>> MifosX project is lost.
> > >>>>
> > >>>>
> > >>>> Is there any reason for initializing fineract as a new git
> repository ?
> > >>>>
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>> Vishwas
> > >>
> > >>
>
>
RE: Missing git history
Posted by Markus Geiß <ma...@live.de>.
That is a good question ... I'd assume that given we remove the hard dependency
on Pentaho and change the license headers to Apache, we should fulfill legal
policies, even if the history holds some things that don't comply to them.
Best,
Markus
.::YAGNI likes a DRY KISS::.
> From: sandervanderheyden@musoni.eu
> Subject: Re: Missing git history
> Date: Sat, 30 Jan 2016 12:47:31 +0100
> To: dev@fineract.incubator.apache.org
>
> Hi guys,
>
> +1 from me on keeping history, it has proven to be very useful in troubleshooting and debugging manier time.
>
> I'm not a git guru but sounds like technically it shouldn't be a problem. To what extent are there any compilations from a legal and licensing perspective?
>
> S
>
> Sent from my iPhone
>
> > On 30 Jan 2016, at 11:49, <ma...@live.de> <ma...@live.de> wrote:
> >
> >
> >
> > I can understand your concern ... and if we agree on doing so ... I'm fine with reverting the changes ... clean the repo again ... and pull in develop only ...
> >
> >
> > I did not say that keeping the history in general is a risk, all I've said is keeping the history as it is now holds some risk.
> >
> >
> > Aside from that keeping the history only to keep contributors mentioned is not an argument to me.
> >
> >
> > Best,
> >
> >
> > Markus
> >
> >
> > .:: YAGNI likes a DRY KISS ::.
> >
> >
> >
> >
> >
> >
> > On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <vi...@confluxtechnologies.com> wrote:
> >
> >
> >
> >
> >
> > Markus,
> >
> > I would assume that redoing the same, i.e changing the package structure in
> > an IDE and then re-licencing (a search replace) shouldn't take much time at
> > all for the core team.
> >
> > Anyone maintaining a fork would be conversant enough with GIT to understand
> > what he / she are doing. Given that the fineract community isn't forcing
> > someone to use the new codebase as their upstream, I do not buy the
> > argument that this is a high risk for the community.
> >
> > The Mifos community has always ensured that all releases are merged back
> > into both master / develop branch. So migrating any one of them to fineract
> > is all that a fork maintainer would need to update his fork.
> >
> > Further, if you would poll the top 5 contributors to the Mifos platform
> > (myself included), I am sure that all things being equal we would all want
> > to maintain the commit history, unless there is a real reason to not do so.
> >
> > Regards,
> > Vishwas
> >
> >
> >> On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de> wrote:
> >>
> >> Vishwas,
> >>
> >> given that the core team has done the renaming and relicensing in one
> >> commit,
> >> git would not be able to detect the move. All files will be detached from
> >> the history
> >> anyways. Git compares files by tree and their BLOB, the changed files lead
> >> to a
> >> new BLOB in a new tree so git would recognize them as new not changed
> >> files.
> >>
> >> The risk to 'act' like there is a history and others using the Apache repo
> >> as the new
> >> upstream, loosing there files by accident b/c the files are 'deleted' was
> >> simply too
> >> high.
> >>
> >> If we like to preserve the history all changes need to be reverted and
> >> every single step
> >> needs to be in its own commit.
> >>
> >> It would also not be feasible to move the whole repo over, because we only
> >> can move
> >> the recent develop. All open branches, and release branches should not be
> >> moved
> >> for clarity reasons and to avoid confusion.
> >>
> >> Best,
> >>
> >> Markus
> >>
> >> .::YAGNI likes a DRY KISS::.
> >>
> >>> Date: Sat, 30 Jan 2016 13:02:26 +0530
> >>> Subject: Re: Missing git history
> >>> From: vishwas@confluxtechnologies.com
> >>> To: dev@fineract.incubator.apache.org
> >>>
> >>> Markus,
> >>>
> >>> Git does an excellent job of recognizing renamed files. Merging forks
> >> with
> >>> the new package structure is a very straightforward process.
> >>>
> >>> What is the issue with retaining the commit history ?
> >>>
> >>> Regards,
> >>> Vishwas
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Hey Vishwas,
> >>>>
> >>>>
> >>>> The repackeging led to a delete and add of all files anyways, so a
> >> simple
> >>>> fetch merge could cause more harm than the creation of a new fork and
> >>>> manually transfer made changes to the code that never where contributed
> >>>> back.
> >>>>
> >>>>
> >>>> In addition I'd suggest to do future code enhancements in a way that
> >>>> allows either a contribution back or keeps the forked base clean and
> >>>> mergable.
> >>>>
> >>>>
> >>>> Best,
> >>>>
> >>>>
> >>>> Markus
> >>>>
> >>>>
> >>>> .:: YAGNI likes a DRY KISS ::.
> >>>>
> >>>>
> >>>>
> >>>> From: Vishwas Babu
> >>>>
> >>>> Sent: Saturday, January 30, 02:46
> >>>>
> >>>> Subject: Missing git history
> >>>>
> >>>> To: dev@fineract.incubator.apache.org
> >>>>
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>>
> >>>> https://github.com/apache/incubator-fineract doesn't carry over the
> >> commit
> >>>>
> >>>> history from https://github.com/openMF/mifosx.
> >>>>
> >>>>
> >>>> Given that the MifosX platform has been around for a few years now,
> >>>>
> >>>> numerous organizations maintain multiple forks of the same . Without
> >> the
> >>>>
> >>>> commit history being carried over, upgrading these forks becomes an
> >>>>
> >>>> unnecessarily painful process.
> >>>>
> >>>>
> >>>> Also, the contribution history of around 78 volunteers to the original
> >>>>
> >>>> MifosX project is lost.
> >>>>
> >>>>
> >>>> Is there any reason for initializing fineract as a new git repository ?
> >>>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> Vishwas
> >>
> >>
Re: Missing git history
Posted by Sander van der Heijden <sa...@musoni.eu>.
Hi guys,
+1 from me on keeping history, it has proven to be very useful in troubleshooting and debugging manier time.
I'm not a git guru but sounds like technically it shouldn't be a problem. To what extent are there any compilations from a legal and licensing perspective?
S
Sent from my iPhone
> On 30 Jan 2016, at 11:49, <ma...@live.de> <ma...@live.de> wrote:
>
>
>
> I can understand your concern ... and if we agree on doing so ... I'm fine with reverting the changes ... clean the repo again ... and pull in develop only ...
>
>
> I did not say that keeping the history in general is a risk, all I've said is keeping the history as it is now holds some risk.
>
>
> Aside from that keeping the history only to keep contributors mentioned is not an argument to me.
>
>
> Best,
>
>
> Markus
>
>
> .:: YAGNI likes a DRY KISS ::.
>
>
>
>
>
>
> On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <vi...@confluxtechnologies.com> wrote:
>
>
>
>
>
> Markus,
>
> I would assume that redoing the same, i.e changing the package structure in
> an IDE and then re-licencing (a search replace) shouldn't take much time at
> all for the core team.
>
> Anyone maintaining a fork would be conversant enough with GIT to understand
> what he / she are doing. Given that the fineract community isn't forcing
> someone to use the new codebase as their upstream, I do not buy the
> argument that this is a high risk for the community.
>
> The Mifos community has always ensured that all releases are merged back
> into both master / develop branch. So migrating any one of them to fineract
> is all that a fork maintainer would need to update his fork.
>
> Further, if you would poll the top 5 contributors to the Mifos platform
> (myself included), I am sure that all things being equal we would all want
> to maintain the commit history, unless there is a real reason to not do so.
>
> Regards,
> Vishwas
>
>
>> On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de> wrote:
>>
>> Vishwas,
>>
>> given that the core team has done the renaming and relicensing in one
>> commit,
>> git would not be able to detect the move. All files will be detached from
>> the history
>> anyways. Git compares files by tree and their BLOB, the changed files lead
>> to a
>> new BLOB in a new tree so git would recognize them as new not changed
>> files.
>>
>> The risk to 'act' like there is a history and others using the Apache repo
>> as the new
>> upstream, loosing there files by accident b/c the files are 'deleted' was
>> simply too
>> high.
>>
>> If we like to preserve the history all changes need to be reverted and
>> every single step
>> needs to be in its own commit.
>>
>> It would also not be feasible to move the whole repo over, because we only
>> can move
>> the recent develop. All open branches, and release branches should not be
>> moved
>> for clarity reasons and to avoid confusion.
>>
>> Best,
>>
>> Markus
>>
>> .::YAGNI likes a DRY KISS::.
>>
>>> Date: Sat, 30 Jan 2016 13:02:26 +0530
>>> Subject: Re: Missing git history
>>> From: vishwas@confluxtechnologies.com
>>> To: dev@fineract.incubator.apache.org
>>>
>>> Markus,
>>>
>>> Git does an excellent job of recognizing renamed files. Merging forks
>> with
>>> the new package structure is a very straightforward process.
>>>
>>> What is the issue with retaining the commit history ?
>>>
>>> Regards,
>>> Vishwas
>>>
>>>
>>>
>>>
>>>
>>>> On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
>>>>
>>>>
>>>>
>>>> Hey Vishwas,
>>>>
>>>>
>>>> The repackeging led to a delete and add of all files anyways, so a
>> simple
>>>> fetch merge could cause more harm than the creation of a new fork and
>>>> manually transfer made changes to the code that never where contributed
>>>> back.
>>>>
>>>>
>>>> In addition I'd suggest to do future code enhancements in a way that
>>>> allows either a contribution back or keeps the forked base clean and
>>>> mergable.
>>>>
>>>>
>>>> Best,
>>>>
>>>>
>>>> Markus
>>>>
>>>>
>>>> .:: YAGNI likes a DRY KISS ::.
>>>>
>>>>
>>>>
>>>> From: Vishwas Babu
>>>>
>>>> Sent: Saturday, January 30, 02:46
>>>>
>>>> Subject: Missing git history
>>>>
>>>> To: dev@fineract.incubator.apache.org
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>> https://github.com/apache/incubator-fineract doesn't carry over the
>> commit
>>>>
>>>> history from https://github.com/openMF/mifosx.
>>>>
>>>>
>>>> Given that the MifosX platform has been around for a few years now,
>>>>
>>>> numerous organizations maintain multiple forks of the same . Without
>> the
>>>>
>>>> commit history being carried over, upgrading these forks becomes an
>>>>
>>>> unnecessarily painful process.
>>>>
>>>>
>>>> Also, the contribution history of around 78 volunteers to the original
>>>>
>>>> MifosX project is lost.
>>>>
>>>>
>>>> Is there any reason for initializing fineract as a new git repository ?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Vishwas
>>
>>
Re: Missing git history
Posted by ma...@live.de.
Hey Adi,
this sounds like a good approach. Don't feel pressured to do it over the weekend. Take your time to do needed adjustments and if it is mid of next week this us fine too!
If we now do this, let's make it clean and right. Do the changes, send a pull request, and let's merge it into develop.
Then we push develop with complete history over to the Apache repo.
Best,
Markus
.:: YAGNI likes a DRY KISS ::.
On Sat, Jan 30, 2016 at 3:06 AM -0800, "Adi Raju" <ad...@confluxtechnologies.com> wrote:
Vishwas/Markus,
As markus mentioned, the commit we did on our remote, did not consider the
file rename.
Till commit, git status displayed the changes as rename(move), but post
commit it started showing as add/delete.
May be this was due to amount of change.
Such a commit wouldn't help anyone to merge changes into their fork.
If change history is important and contributor history is important, give
me time till monday and i will see if doing the changes in multiple commits
will preserve the change history.
Regards,
Adi
On Sat, Jan 30, 2016 at 4:19 PM, <ma...@live.de> wrote:
>
>
> I can understand your concern ... and if we agree on doing so ... I'm fine
> with reverting the changes ... clean the repo again ... and pull in develop
> only ...
>
>
> I did not say that keeping the history in general is a risk, all I've said
> is keeping the history as it is now holds some risk.
>
>
> Aside from that keeping the history only to keep contributors mentioned is
> not an argument to me.
>
>
> Best,
>
>
> Markus
>
>
> .:: YAGNI likes a DRY KISS ::.
>
>
>
>
>
>
> On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <
> vishwas@confluxtechnologies.com> wrote:
>
>
>
>
>
> Markus,
>
> I would assume that redoing the same, i.e changing the package structure in
> an IDE and then re-licencing (a search replace) shouldn't take much time at
> all for the core team.
>
> Anyone maintaining a fork would be conversant enough with GIT to understand
> what he / she are doing. Given that the fineract community isn't forcing
> someone to use the new codebase as their upstream, I do not buy the
> argument that this is a high risk for the community.
>
> The Mifos community has always ensured that all releases are merged back
> into both master / develop branch. So migrating any one of them to fineract
> is all that a fork maintainer would need to update his fork.
>
> Further, if you would poll the top 5 contributors to the Mifos platform
> (myself included), I am sure that all things being equal we would all want
> to maintain the commit history, unless there is a real reason to not do so.
>
> Regards,
> Vishwas
>
>
> On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de> wrote:
>
> > Vishwas,
> >
> > given that the core team has done the renaming and relicensing in one
> > commit,
> > git would not be able to detect the move. All files will be detached from
> > the history
> > anyways. Git compares files by tree and their BLOB, the changed files
> lead
> > to a
> > new BLOB in a new tree so git would recognize them as new not changed
> > files.
> >
> > The risk to 'act' like there is a history and others using the Apache
> repo
> > as the new
> > upstream, loosing there files by accident b/c the files are 'deleted' was
> > simply too
> > high.
> >
> > If we like to preserve the history all changes need to be reverted and
> > every single step
> > needs to be in its own commit.
> >
> > It would also not be feasible to move the whole repo over, because we
> only
> > can move
> > the recent develop. All open branches, and release branches should not be
> > moved
> > for clarity reasons and to avoid confusion.
> >
> > Best,
> >
> > Markus
> >
> > .::YAGNI likes a DRY KISS::.
> >
> > > Date: Sat, 30 Jan 2016 13:02:26 +0530
> > > Subject: Re: Missing git history
> > > From: vishwas@confluxtechnologies.com
> > > To: dev@fineract.incubator.apache.org
> > >
> > > Markus,
> > >
> > > Git does an excellent job of recognizing renamed files. Merging forks
> > with
> > > the new package structure is a very straightforward process.
> > >
> > > What is the issue with retaining the commit history ?
> > >
> > > Regards,
> > > Vishwas
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> > >
> > > >
> > > >
> > > > Hey Vishwas,
> > > >
> > > >
> > > > The repackeging led to a delete and add of all files anyways, so a
> > simple
> > > > fetch merge could cause more harm than the creation of a new fork and
> > > > manually transfer made changes to the code that never where
> contributed
> > > > back.
> > > >
> > > >
> > > > In addition I'd suggest to do future code enhancements in a way that
> > > > allows either a contribution back or keeps the forked base clean and
> > > > mergable.
> > > >
> > > >
> > > > Best,
> > > >
> > > >
> > > > Markus
> > > >
> > > >
> > > > .:: YAGNI likes a DRY KISS ::.
> > > >
> > > >
> > > >
> > > > From: Vishwas Babu
> > > >
> > > > Sent: Saturday, January 30, 02:46
> > > >
> > > > Subject: Missing git history
> > > >
> > > > To: dev@fineract.incubator.apache.org
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > >
> > > > https://github.com/apache/incubator-fineract doesn't carry over the
> > commit
> > > >
> > > > history from https://github.com/openMF/mifosx.
> > > >
> > > >
> > > > Given that the MifosX platform has been around for a few years now,
> > > >
> > > > numerous organizations maintain multiple forks of the same . Without
> > the
> > > >
> > > > commit history being carried over, upgrading these forks becomes an
> > > >
> > > > unnecessarily painful process.
> > > >
> > > >
> > > > Also, the contribution history of around 78 volunteers to the
> original
> > > >
> > > > MifosX project is lost.
> > > >
> > > >
> > > > Is there any reason for initializing fineract as a new git
> repository ?
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Vishwas
> > > >
> > > >
> > > >
> > > >
> >
> >
>
Re: Missing git history
Posted by Greg Stein <gs...@gmail.com>.
Yup. Take two or three steps, to keep it all connected.
IMO, taking some extra days to ensure history is retained, is very
worthwhile.
On Sat, Jan 30, 2016 at 5:12 AM, Vishwas Babu <
vishwas@confluxtechnologies.com> wrote:
> Adi,
>
> Committing files after package rename (and prior to any other changes
> involving licencing) should be sufficient for git to recognize that the
> file was moved.
>
> Regards,
> Vishwas
>
> On Sat, Jan 30, 2016 at 4:35 PM, Adi Raju <
> adi.raju@confluxtechnologies.com>
> wrote:
>
> > Vishwas/Markus,
> >
> > As markus mentioned, the commit we did on our remote, did not consider
> the
> > file rename.
> > Till commit, git status displayed the changes as rename(move), but post
> > commit it started showing as add/delete.
> > May be this was due to amount of change.
> >
> > Such a commit wouldn't help anyone to merge changes into their fork.
> >
> > If change history is important and contributor history is important, give
> > me time till monday and i will see if doing the changes in multiple
> commits
> > will preserve the change history.
> >
> > Regards,
> > Adi
> >
> >
> > On Sat, Jan 30, 2016 at 4:19 PM, <ma...@live.de> wrote:
> >
> > >
> > >
> > > I can understand your concern ... and if we agree on doing so ... I'm
> > fine
> > > with reverting the changes ... clean the repo again ... and pull in
> > develop
> > > only ...
> > >
> > >
> > > I did not say that keeping the history in general is a risk, all I've
> > said
> > > is keeping the history as it is now holds some risk.
> > >
> > >
> > > Aside from that keeping the history only to keep contributors mentioned
> > is
> > > not an argument to me.
> > >
> > >
> > > Best,
> > >
> > >
> > > Markus
> > >
> > >
> > > .:: YAGNI likes a DRY KISS ::.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <
> > > vishwas@confluxtechnologies.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > > Markus,
> > >
> > > I would assume that redoing the same, i.e changing the package
> structure
> > in
> > > an IDE and then re-licencing (a search replace) shouldn't take much
> time
> > at
> > > all for the core team.
> > >
> > > Anyone maintaining a fork would be conversant enough with GIT to
> > understand
> > > what he / she are doing. Given that the fineract community isn't
> forcing
> > > someone to use the new codebase as their upstream, I do not buy the
> > > argument that this is a high risk for the community.
> > >
> > > The Mifos community has always ensured that all releases are merged
> back
> > > into both master / develop branch. So migrating any one of them to
> > fineract
> > > is all that a fork maintainer would need to update his fork.
> > >
> > > Further, if you would poll the top 5 contributors to the Mifos platform
> > > (myself included), I am sure that all things being equal we would all
> > want
> > > to maintain the commit history, unless there is a real reason to not do
> > so.
> > >
> > > Regards,
> > > Vishwas
> > >
> > >
> > > On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de>
> > wrote:
> > >
> > > > Vishwas,
> > > >
> > > > given that the core team has done the renaming and relicensing in one
> > > > commit,
> > > > git would not be able to detect the move. All files will be detached
> > from
> > > > the history
> > > > anyways. Git compares files by tree and their BLOB, the changed files
> > > lead
> > > > to a
> > > > new BLOB in a new tree so git would recognize them as new not changed
> > > > files.
> > > >
> > > > The risk to 'act' like there is a history and others using the Apache
> > > repo
> > > > as the new
> > > > upstream, loosing there files by accident b/c the files are 'deleted'
> > was
> > > > simply too
> > > > high.
> > > >
> > > > If we like to preserve the history all changes need to be reverted
> and
> > > > every single step
> > > > needs to be in its own commit.
> > > >
> > > > It would also not be feasible to move the whole repo over, because we
> > > only
> > > > can move
> > > > the recent develop. All open branches, and release branches should
> not
> > be
> > > > moved
> > > > for clarity reasons and to avoid confusion.
> > > >
> > > > Best,
> > > >
> > > > Markus
> > > >
> > > > .::YAGNI likes a DRY KISS::.
> > > >
> > > > > Date: Sat, 30 Jan 2016 13:02:26 +0530
> > > > > Subject: Re: Missing git history
> > > > > From: vishwas@confluxtechnologies.com
> > > > > To: dev@fineract.incubator.apache.org
> > > > >
> > > > > Markus,
> > > > >
> > > > > Git does an excellent job of recognizing renamed files. Merging
> forks
> > > > with
> > > > > the new package structure is a very straightforward process.
> > > > >
> > > > > What is the issue with retaining the commit history ?
> > > > >
> > > > > Regards,
> > > > > Vishwas
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Hey Vishwas,
> > > > > >
> > > > > >
> > > > > > The repackeging led to a delete and add of all files anyways, so
> a
> > > > simple
> > > > > > fetch merge could cause more harm than the creation of a new fork
> > and
> > > > > > manually transfer made changes to the code that never where
> > > contributed
> > > > > > back.
> > > > > >
> > > > > >
> > > > > > In addition I'd suggest to do future code enhancements in a way
> > that
> > > > > > allows either a contribution back or keeps the forked base clean
> > and
> > > > > > mergable.
> > > > > >
> > > > > >
> > > > > > Best,
> > > > > >
> > > > > >
> > > > > > Markus
> > > > > >
> > > > > >
> > > > > > .:: YAGNI likes a DRY KISS ::.
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Vishwas Babu
> > > > > >
> > > > > > Sent: Saturday, January 30, 02:46
> > > > > >
> > > > > > Subject: Missing git history
> > > > > >
> > > > > > To: dev@fineract.incubator.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > > https://github.com/apache/incubator-fineract doesn't carry over
> > the
> > > > commit
> > > > > >
> > > > > > history from https://github.com/openMF/mifosx.
> > > > > >
> > > > > >
> > > > > > Given that the MifosX platform has been around for a few years
> now,
> > > > > >
> > > > > > numerous organizations maintain multiple forks of the same .
> > Without
> > > > the
> > > > > >
> > > > > > commit history being carried over, upgrading these forks becomes
> an
> > > > > >
> > > > > > unnecessarily painful process.
> > > > > >
> > > > > >
> > > > > > Also, the contribution history of around 78 volunteers to the
> > > original
> > > > > >
> > > > > > MifosX project is lost.
> > > > > >
> > > > > >
> > > > > > Is there any reason for initializing fineract as a new git
> > > repository ?
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Vishwas
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > >
> >
>
Re: Missing git history
Posted by Vishwas Babu <vi...@confluxtechnologies.com>.
Adi,
Committing files after package rename (and prior to any other changes
involving licencing) should be sufficient for git to recognize that the
file was moved.
Regards,
Vishwas
On Sat, Jan 30, 2016 at 4:35 PM, Adi Raju <ad...@confluxtechnologies.com>
wrote:
> Vishwas/Markus,
>
> As markus mentioned, the commit we did on our remote, did not consider the
> file rename.
> Till commit, git status displayed the changes as rename(move), but post
> commit it started showing as add/delete.
> May be this was due to amount of change.
>
> Such a commit wouldn't help anyone to merge changes into their fork.
>
> If change history is important and contributor history is important, give
> me time till monday and i will see if doing the changes in multiple commits
> will preserve the change history.
>
> Regards,
> Adi
>
>
> On Sat, Jan 30, 2016 at 4:19 PM, <ma...@live.de> wrote:
>
> >
> >
> > I can understand your concern ... and if we agree on doing so ... I'm
> fine
> > with reverting the changes ... clean the repo again ... and pull in
> develop
> > only ...
> >
> >
> > I did not say that keeping the history in general is a risk, all I've
> said
> > is keeping the history as it is now holds some risk.
> >
> >
> > Aside from that keeping the history only to keep contributors mentioned
> is
> > not an argument to me.
> >
> >
> > Best,
> >
> >
> > Markus
> >
> >
> > .:: YAGNI likes a DRY KISS ::.
> >
> >
> >
> >
> >
> >
> > On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <
> > vishwas@confluxtechnologies.com> wrote:
> >
> >
> >
> >
> >
> > Markus,
> >
> > I would assume that redoing the same, i.e changing the package structure
> in
> > an IDE and then re-licencing (a search replace) shouldn't take much time
> at
> > all for the core team.
> >
> > Anyone maintaining a fork would be conversant enough with GIT to
> understand
> > what he / she are doing. Given that the fineract community isn't forcing
> > someone to use the new codebase as their upstream, I do not buy the
> > argument that this is a high risk for the community.
> >
> > The Mifos community has always ensured that all releases are merged back
> > into both master / develop branch. So migrating any one of them to
> fineract
> > is all that a fork maintainer would need to update his fork.
> >
> > Further, if you would poll the top 5 contributors to the Mifos platform
> > (myself included), I am sure that all things being equal we would all
> want
> > to maintain the commit history, unless there is a real reason to not do
> so.
> >
> > Regards,
> > Vishwas
> >
> >
> > On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de>
> wrote:
> >
> > > Vishwas,
> > >
> > > given that the core team has done the renaming and relicensing in one
> > > commit,
> > > git would not be able to detect the move. All files will be detached
> from
> > > the history
> > > anyways. Git compares files by tree and their BLOB, the changed files
> > lead
> > > to a
> > > new BLOB in a new tree so git would recognize them as new not changed
> > > files.
> > >
> > > The risk to 'act' like there is a history and others using the Apache
> > repo
> > > as the new
> > > upstream, loosing there files by accident b/c the files are 'deleted'
> was
> > > simply too
> > > high.
> > >
> > > If we like to preserve the history all changes need to be reverted and
> > > every single step
> > > needs to be in its own commit.
> > >
> > > It would also not be feasible to move the whole repo over, because we
> > only
> > > can move
> > > the recent develop. All open branches, and release branches should not
> be
> > > moved
> > > for clarity reasons and to avoid confusion.
> > >
> > > Best,
> > >
> > > Markus
> > >
> > > .::YAGNI likes a DRY KISS::.
> > >
> > > > Date: Sat, 30 Jan 2016 13:02:26 +0530
> > > > Subject: Re: Missing git history
> > > > From: vishwas@confluxtechnologies.com
> > > > To: dev@fineract.incubator.apache.org
> > > >
> > > > Markus,
> > > >
> > > > Git does an excellent job of recognizing renamed files. Merging forks
> > > with
> > > > the new package structure is a very straightforward process.
> > > >
> > > > What is the issue with retaining the commit history ?
> > > >
> > > > Regards,
> > > > Vishwas
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> > > >
> > > > >
> > > > >
> > > > > Hey Vishwas,
> > > > >
> > > > >
> > > > > The repackeging led to a delete and add of all files anyways, so a
> > > simple
> > > > > fetch merge could cause more harm than the creation of a new fork
> and
> > > > > manually transfer made changes to the code that never where
> > contributed
> > > > > back.
> > > > >
> > > > >
> > > > > In addition I'd suggest to do future code enhancements in a way
> that
> > > > > allows either a contribution back or keeps the forked base clean
> and
> > > > > mergable.
> > > > >
> > > > >
> > > > > Best,
> > > > >
> > > > >
> > > > > Markus
> > > > >
> > > > >
> > > > > .:: YAGNI likes a DRY KISS ::.
> > > > >
> > > > >
> > > > >
> > > > > From: Vishwas Babu
> > > > >
> > > > > Sent: Saturday, January 30, 02:46
> > > > >
> > > > > Subject: Missing git history
> > > > >
> > > > > To: dev@fineract.incubator.apache.org
> > > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > >
> > > > > https://github.com/apache/incubator-fineract doesn't carry over
> the
> > > commit
> > > > >
> > > > > history from https://github.com/openMF/mifosx.
> > > > >
> > > > >
> > > > > Given that the MifosX platform has been around for a few years now,
> > > > >
> > > > > numerous organizations maintain multiple forks of the same .
> Without
> > > the
> > > > >
> > > > > commit history being carried over, upgrading these forks becomes an
> > > > >
> > > > > unnecessarily painful process.
> > > > >
> > > > >
> > > > > Also, the contribution history of around 78 volunteers to the
> > original
> > > > >
> > > > > MifosX project is lost.
> > > > >
> > > > >
> > > > > Is there any reason for initializing fineract as a new git
> > repository ?
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Vishwas
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> >
>
Re: Missing git history
Posted by Adi Raju <ad...@confluxtechnologies.com>.
Vishwas/Markus,
As markus mentioned, the commit we did on our remote, did not consider the
file rename.
Till commit, git status displayed the changes as rename(move), but post
commit it started showing as add/delete.
May be this was due to amount of change.
Such a commit wouldn't help anyone to merge changes into their fork.
If change history is important and contributor history is important, give
me time till monday and i will see if doing the changes in multiple commits
will preserve the change history.
Regards,
Adi
On Sat, Jan 30, 2016 at 4:19 PM, <ma...@live.de> wrote:
>
>
> I can understand your concern ... and if we agree on doing so ... I'm fine
> with reverting the changes ... clean the repo again ... and pull in develop
> only ...
>
>
> I did not say that keeping the history in general is a risk, all I've said
> is keeping the history as it is now holds some risk.
>
>
> Aside from that keeping the history only to keep contributors mentioned is
> not an argument to me.
>
>
> Best,
>
>
> Markus
>
>
> .:: YAGNI likes a DRY KISS ::.
>
>
>
>
>
>
> On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <
> vishwas@confluxtechnologies.com> wrote:
>
>
>
>
>
> Markus,
>
> I would assume that redoing the same, i.e changing the package structure in
> an IDE and then re-licencing (a search replace) shouldn't take much time at
> all for the core team.
>
> Anyone maintaining a fork would be conversant enough with GIT to understand
> what he / she are doing. Given that the fineract community isn't forcing
> someone to use the new codebase as their upstream, I do not buy the
> argument that this is a high risk for the community.
>
> The Mifos community has always ensured that all releases are merged back
> into both master / develop branch. So migrating any one of them to fineract
> is all that a fork maintainer would need to update his fork.
>
> Further, if you would poll the top 5 contributors to the Mifos platform
> (myself included), I am sure that all things being equal we would all want
> to maintain the commit history, unless there is a real reason to not do so.
>
> Regards,
> Vishwas
>
>
> On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de> wrote:
>
> > Vishwas,
> >
> > given that the core team has done the renaming and relicensing in one
> > commit,
> > git would not be able to detect the move. All files will be detached from
> > the history
> > anyways. Git compares files by tree and their BLOB, the changed files
> lead
> > to a
> > new BLOB in a new tree so git would recognize them as new not changed
> > files.
> >
> > The risk to 'act' like there is a history and others using the Apache
> repo
> > as the new
> > upstream, loosing there files by accident b/c the files are 'deleted' was
> > simply too
> > high.
> >
> > If we like to preserve the history all changes need to be reverted and
> > every single step
> > needs to be in its own commit.
> >
> > It would also not be feasible to move the whole repo over, because we
> only
> > can move
> > the recent develop. All open branches, and release branches should not be
> > moved
> > for clarity reasons and to avoid confusion.
> >
> > Best,
> >
> > Markus
> >
> > .::YAGNI likes a DRY KISS::.
> >
> > > Date: Sat, 30 Jan 2016 13:02:26 +0530
> > > Subject: Re: Missing git history
> > > From: vishwas@confluxtechnologies.com
> > > To: dev@fineract.incubator.apache.org
> > >
> > > Markus,
> > >
> > > Git does an excellent job of recognizing renamed files. Merging forks
> > with
> > > the new package structure is a very straightforward process.
> > >
> > > What is the issue with retaining the commit history ?
> > >
> > > Regards,
> > > Vishwas
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> > >
> > > >
> > > >
> > > > Hey Vishwas,
> > > >
> > > >
> > > > The repackeging led to a delete and add of all files anyways, so a
> > simple
> > > > fetch merge could cause more harm than the creation of a new fork and
> > > > manually transfer made changes to the code that never where
> contributed
> > > > back.
> > > >
> > > >
> > > > In addition I'd suggest to do future code enhancements in a way that
> > > > allows either a contribution back or keeps the forked base clean and
> > > > mergable.
> > > >
> > > >
> > > > Best,
> > > >
> > > >
> > > > Markus
> > > >
> > > >
> > > > .:: YAGNI likes a DRY KISS ::.
> > > >
> > > >
> > > >
> > > > From: Vishwas Babu
> > > >
> > > > Sent: Saturday, January 30, 02:46
> > > >
> > > > Subject: Missing git history
> > > >
> > > > To: dev@fineract.incubator.apache.org
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > >
> > > > https://github.com/apache/incubator-fineract doesn't carry over the
> > commit
> > > >
> > > > history from https://github.com/openMF/mifosx.
> > > >
> > > >
> > > > Given that the MifosX platform has been around for a few years now,
> > > >
> > > > numerous organizations maintain multiple forks of the same . Without
> > the
> > > >
> > > > commit history being carried over, upgrading these forks becomes an
> > > >
> > > > unnecessarily painful process.
> > > >
> > > >
> > > > Also, the contribution history of around 78 volunteers to the
> original
> > > >
> > > > MifosX project is lost.
> > > >
> > > >
> > > > Is there any reason for initializing fineract as a new git
> repository ?
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Vishwas
> > > >
> > > >
> > > >
> > > >
> >
> >
>
Re: Missing git history
Posted by Vishwas Babu <vi...@confluxtechnologies.com>.
>>I can understand your concern ... and if we agree on doing so ... I'm
fine with reverting the changes ... clean the repo again ... and pull in
develop only ...
Thanks Markus :) This ensures that all fork maintainers can upgrade to the
fineract code-base at their leisure
On Sat, Jan 30, 2016 at 4:19 PM, <ma...@live.de> wrote:
>
>
> I can understand your concern ... and if we agree on doing so ... I'm fine
> with reverting the changes ... clean the repo again ... and pull in develop
> only ...
>
>
> I did not say that keeping the history in general is a risk, all I've said
> is keeping the history as it is now holds some risk.
>
>
> Aside from that keeping the history only to keep contributors mentioned is
> not an argument to me.
>
>
> Best,
>
>
> Markus
>
>
> .:: YAGNI likes a DRY KISS ::.
>
>
>
>
>
>
> On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <
> vishwas@confluxtechnologies.com> wrote:
>
>
>
>
>
> Markus,
>
> I would assume that redoing the same, i.e changing the package structure in
> an IDE and then re-licencing (a search replace) shouldn't take much time at
> all for the core team.
>
> Anyone maintaining a fork would be conversant enough with GIT to understand
> what he / she are doing. Given that the fineract community isn't forcing
> someone to use the new codebase as their upstream, I do not buy the
> argument that this is a high risk for the community.
>
> The Mifos community has always ensured that all releases are merged back
> into both master / develop branch. So migrating any one of them to fineract
> is all that a fork maintainer would need to update his fork.
>
> Further, if you would poll the top 5 contributors to the Mifos platform
> (myself included), I am sure that all things being equal we would all want
> to maintain the commit history, unless there is a real reason to not do so.
>
> Regards,
> Vishwas
>
>
> On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de> wrote:
>
> > Vishwas,
> >
> > given that the core team has done the renaming and relicensing in one
> > commit,
> > git would not be able to detect the move. All files will be detached from
> > the history
> > anyways. Git compares files by tree and their BLOB, the changed files
> lead
> > to a
> > new BLOB in a new tree so git would recognize them as new not changed
> > files.
> >
> > The risk to 'act' like there is a history and others using the Apache
> repo
> > as the new
> > upstream, loosing there files by accident b/c the files are 'deleted' was
> > simply too
> > high.
> >
> > If we like to preserve the history all changes need to be reverted and
> > every single step
> > needs to be in its own commit.
> >
> > It would also not be feasible to move the whole repo over, because we
> only
> > can move
> > the recent develop. All open branches, and release branches should not be
> > moved
> > for clarity reasons and to avoid confusion.
> >
> > Best,
> >
> > Markus
> >
> > .::YAGNI likes a DRY KISS::.
> >
> > > Date: Sat, 30 Jan 2016 13:02:26 +0530
> > > Subject: Re: Missing git history
> > > From: vishwas@confluxtechnologies.com
> > > To: dev@fineract.incubator.apache.org
> > >
> > > Markus,
> > >
> > > Git does an excellent job of recognizing renamed files. Merging forks
> > with
> > > the new package structure is a very straightforward process.
> > >
> > > What is the issue with retaining the commit history ?
> > >
> > > Regards,
> > > Vishwas
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> > >
> > > >
> > > >
> > > > Hey Vishwas,
> > > >
> > > >
> > > > The repackeging led to a delete and add of all files anyways, so a
> > simple
> > > > fetch merge could cause more harm than the creation of a new fork and
> > > > manually transfer made changes to the code that never where
> contributed
> > > > back.
> > > >
> > > >
> > > > In addition I'd suggest to do future code enhancements in a way that
> > > > allows either a contribution back or keeps the forked base clean and
> > > > mergable.
> > > >
> > > >
> > > > Best,
> > > >
> > > >
> > > > Markus
> > > >
> > > >
> > > > .:: YAGNI likes a DRY KISS ::.
> > > >
> > > >
> > > >
> > > > From: Vishwas Babu
> > > >
> > > > Sent: Saturday, January 30, 02:46
> > > >
> > > > Subject: Missing git history
> > > >
> > > > To: dev@fineract.incubator.apache.org
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > >
> > > > https://github.com/apache/incubator-fineract doesn't carry over the
> > commit
> > > >
> > > > history from https://github.com/openMF/mifosx.
> > > >
> > > >
> > > > Given that the MifosX platform has been around for a few years now,
> > > >
> > > > numerous organizations maintain multiple forks of the same . Without
> > the
> > > >
> > > > commit history being carried over, upgrading these forks becomes an
> > > >
> > > > unnecessarily painful process.
> > > >
> > > >
> > > > Also, the contribution history of around 78 volunteers to the
> original
> > > >
> > > > MifosX project is lost.
> > > >
> > > >
> > > > Is there any reason for initializing fineract as a new git
> repository ?
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Vishwas
> > > >
> > > >
> > > >
> > > >
> >
> >
>
Re: Missing git history
Posted by ma...@live.de.
I can understand your concern ... and if we agree on doing so ... I'm fine with reverting the changes ... clean the repo again ... and pull in develop only ...
I did not say that keeping the history in general is a risk, all I've said is keeping the history as it is now holds some risk.
Aside from that keeping the history only to keep contributors mentioned is not an argument to me.
Best,
Markus
.:: YAGNI likes a DRY KISS ::.
On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <vi...@confluxtechnologies.com> wrote:
Markus,
I would assume that redoing the same, i.e changing the package structure in
an IDE and then re-licencing (a search replace) shouldn't take much time at
all for the core team.
Anyone maintaining a fork would be conversant enough with GIT to understand
what he / she are doing. Given that the fineract community isn't forcing
someone to use the new codebase as their upstream, I do not buy the
argument that this is a high risk for the community.
The Mifos community has always ensured that all releases are merged back
into both master / develop branch. So migrating any one of them to fineract
is all that a fork maintainer would need to update his fork.
Further, if you would poll the top 5 contributors to the Mifos platform
(myself included), I am sure that all things being equal we would all want
to maintain the commit history, unless there is a real reason to not do so.
Regards,
Vishwas
On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de> wrote:
> Vishwas,
>
> given that the core team has done the renaming and relicensing in one
> commit,
> git would not be able to detect the move. All files will be detached from
> the history
> anyways. Git compares files by tree and their BLOB, the changed files lead
> to a
> new BLOB in a new tree so git would recognize them as new not changed
> files.
>
> The risk to 'act' like there is a history and others using the Apache repo
> as the new
> upstream, loosing there files by accident b/c the files are 'deleted' was
> simply too
> high.
>
> If we like to preserve the history all changes need to be reverted and
> every single step
> needs to be in its own commit.
>
> It would also not be feasible to move the whole repo over, because we only
> can move
> the recent develop. All open branches, and release branches should not be
> moved
> for clarity reasons and to avoid confusion.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > Date: Sat, 30 Jan 2016 13:02:26 +0530
> > Subject: Re: Missing git history
> > From: vishwas@confluxtechnologies.com
> > To: dev@fineract.incubator.apache.org
> >
> > Markus,
> >
> > Git does an excellent job of recognizing renamed files. Merging forks
> with
> > the new package structure is a very straightforward process.
> >
> > What is the issue with retaining the commit history ?
> >
> > Regards,
> > Vishwas
> >
> >
> >
> >
> >
> > On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> >
> > >
> > >
> > > Hey Vishwas,
> > >
> > >
> > > The repackeging led to a delete and add of all files anyways, so a
> simple
> > > fetch merge could cause more harm than the creation of a new fork and
> > > manually transfer made changes to the code that never where contributed
> > > back.
> > >
> > >
> > > In addition I'd suggest to do future code enhancements in a way that
> > > allows either a contribution back or keeps the forked base clean and
> > > mergable.
> > >
> > >
> > > Best,
> > >
> > >
> > > Markus
> > >
> > >
> > > .:: YAGNI likes a DRY KISS ::.
> > >
> > >
> > >
> > > From: Vishwas Babu
> > >
> > > Sent: Saturday, January 30, 02:46
> > >
> > > Subject: Missing git history
> > >
> > > To: dev@fineract.incubator.apache.org
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > > https://github.com/apache/incubator-fineract doesn't carry over the
> commit
> > >
> > > history from https://github.com/openMF/mifosx.
> > >
> > >
> > > Given that the MifosX platform has been around for a few years now,
> > >
> > > numerous organizations maintain multiple forks of the same . Without
> the
> > >
> > > commit history being carried over, upgrading these forks becomes an
> > >
> > > unnecessarily painful process.
> > >
> > >
> > > Also, the contribution history of around 78 volunteers to the original
> > >
> > > MifosX project is lost.
> > >
> > >
> > > Is there any reason for initializing fineract as a new git repository ?
> > >
> > >
> > > Regards,
> > >
> > > Vishwas
> > >
> > >
> > >
> > >
>
>
Re: Missing git history
Posted by Vishwas Babu <vi...@confluxtechnologies.com>.
Markus,
I would assume that redoing the same, i.e changing the package structure in
an IDE and then re-licencing (a search replace) shouldn't take much time at
all for the core team.
Anyone maintaining a fork would be conversant enough with GIT to understand
what he / she are doing. Given that the fineract community isn't forcing
someone to use the new codebase as their upstream, I do not buy the
argument that this is a high risk for the community.
The Mifos community has always ensured that all releases are merged back
into both master / develop branch. So migrating any one of them to fineract
is all that a fork maintainer would need to update his fork.
Further, if you would poll the top 5 contributors to the Mifos platform
(myself included), I am sure that all things being equal we would all want
to maintain the commit history, unless there is a real reason to not do so.
Regards,
Vishwas
On Sat, Jan 30, 2016 at 3:05 PM, Markus Geiß <ma...@live.de> wrote:
> Vishwas,
>
> given that the core team has done the renaming and relicensing in one
> commit,
> git would not be able to detect the move. All files will be detached from
> the history
> anyways. Git compares files by tree and their BLOB, the changed files lead
> to a
> new BLOB in a new tree so git would recognize them as new not changed
> files.
>
> The risk to 'act' like there is a history and others using the Apache repo
> as the new
> upstream, loosing there files by accident b/c the files are 'deleted' was
> simply too
> high.
>
> If we like to preserve the history all changes need to be reverted and
> every single step
> needs to be in its own commit.
>
> It would also not be feasible to move the whole repo over, because we only
> can move
> the recent develop. All open branches, and release branches should not be
> moved
> for clarity reasons and to avoid confusion.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > Date: Sat, 30 Jan 2016 13:02:26 +0530
> > Subject: Re: Missing git history
> > From: vishwas@confluxtechnologies.com
> > To: dev@fineract.incubator.apache.org
> >
> > Markus,
> >
> > Git does an excellent job of recognizing renamed files. Merging forks
> with
> > the new package structure is a very straightforward process.
> >
> > What is the issue with retaining the commit history ?
> >
> > Regards,
> > Vishwas
> >
> >
> >
> >
> >
> > On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
> >
> > >
> > >
> > > Hey Vishwas,
> > >
> > >
> > > The repackeging led to a delete and add of all files anyways, so a
> simple
> > > fetch merge could cause more harm than the creation of a new fork and
> > > manually transfer made changes to the code that never where contributed
> > > back.
> > >
> > >
> > > In addition I'd suggest to do future code enhancements in a way that
> > > allows either a contribution back or keeps the forked base clean and
> > > mergable.
> > >
> > >
> > > Best,
> > >
> > >
> > > Markus
> > >
> > >
> > > .:: YAGNI likes a DRY KISS ::.
> > >
> > >
> > >
> > > From: Vishwas Babu
> > >
> > > Sent: Saturday, January 30, 02:46
> > >
> > > Subject: Missing git history
> > >
> > > To: dev@fineract.incubator.apache.org
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > > https://github.com/apache/incubator-fineract doesn't carry over the
> commit
> > >
> > > history from https://github.com/openMF/mifosx.
> > >
> > >
> > > Given that the MifosX platform has been around for a few years now,
> > >
> > > numerous organizations maintain multiple forks of the same . Without
> the
> > >
> > > commit history being carried over, upgrading these forks becomes an
> > >
> > > unnecessarily painful process.
> > >
> > >
> > > Also, the contribution history of around 78 volunteers to the original
> > >
> > > MifosX project is lost.
> > >
> > >
> > > Is there any reason for initializing fineract as a new git repository ?
> > >
> > >
> > > Regards,
> > >
> > > Vishwas
> > >
> > >
> > >
> > >
>
>
RE: Missing git history
Posted by Markus Geiß <ma...@live.de>.
Vishwas,
given that the core team has done the renaming and relicensing in one commit,
git would not be able to detect the move. All files will be detached from the history
anyways. Git compares files by tree and their BLOB, the changed files lead to a
new BLOB in a new tree so git would recognize them as new not changed files.
The risk to 'act' like there is a history and others using the Apache repo as the new
upstream, loosing there files by accident b/c the files are 'deleted' was simply too
high.
If we like to preserve the history all changes need to be reverted and every single step
needs to be in its own commit.
It would also not be feasible to move the whole repo over, because we only can move
the recent develop. All open branches, and release branches should not be moved
for clarity reasons and to avoid confusion.
Best,
Markus
.::YAGNI likes a DRY KISS::.
> Date: Sat, 30 Jan 2016 13:02:26 +0530
> Subject: Re: Missing git history
> From: vishwas@confluxtechnologies.com
> To: dev@fineract.incubator.apache.org
>
> Markus,
>
> Git does an excellent job of recognizing renamed files. Merging forks with
> the new package structure is a very straightforward process.
>
> What is the issue with retaining the commit history ?
>
> Regards,
> Vishwas
>
>
>
>
>
> On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
>
> >
> >
> > Hey Vishwas,
> >
> >
> > The repackeging led to a delete and add of all files anyways, so a simple
> > fetch merge could cause more harm than the creation of a new fork and
> > manually transfer made changes to the code that never where contributed
> > back.
> >
> >
> > In addition I'd suggest to do future code enhancements in a way that
> > allows either a contribution back or keeps the forked base clean and
> > mergable.
> >
> >
> > Best,
> >
> >
> > Markus
> >
> >
> > .:: YAGNI likes a DRY KISS ::.
> >
> >
> >
> > From: Vishwas Babu
> >
> > Sent: Saturday, January 30, 02:46
> >
> > Subject: Missing git history
> >
> > To: dev@fineract.incubator.apache.org
> >
> >
> >
> > Hi,
> >
> >
> > https://github.com/apache/incubator-fineract doesn't carry over the commit
> >
> > history from https://github.com/openMF/mifosx.
> >
> >
> > Given that the MifosX platform has been around for a few years now,
> >
> > numerous organizations maintain multiple forks of the same . Without the
> >
> > commit history being carried over, upgrading these forks becomes an
> >
> > unnecessarily painful process.
> >
> >
> > Also, the contribution history of around 78 volunteers to the original
> >
> > MifosX project is lost.
> >
> >
> > Is there any reason for initializing fineract as a new git repository ?
> >
> >
> > Regards,
> >
> > Vishwas
> >
> >
> >
> >
Re: Missing git history
Posted by Vishwas Babu <vi...@confluxtechnologies.com>.
Markus,
Git does an excellent job of recognizing renamed files. Merging forks with
the new package structure is a very straightforward process.
What is the issue with retaining the commit history ?
Regards,
Vishwas
On Sat, Jan 30, 2016 at 11:29 AM, <ma...@live.de> wrote:
>
>
> Hey Vishwas,
>
>
> The repackeging led to a delete and add of all files anyways, so a simple
> fetch merge could cause more harm than the creation of a new fork and
> manually transfer made changes to the code that never where contributed
> back.
>
>
> In addition I'd suggest to do future code enhancements in a way that
> allows either a contribution back or keeps the forked base clean and
> mergable.
>
>
> Best,
>
>
> Markus
>
>
> .:: YAGNI likes a DRY KISS ::.
>
>
>
> From: Vishwas Babu
>
> Sent: Saturday, January 30, 02:46
>
> Subject: Missing git history
>
> To: dev@fineract.incubator.apache.org
>
>
>
> Hi,
>
>
> https://github.com/apache/incubator-fineract doesn't carry over the commit
>
> history from https://github.com/openMF/mifosx.
>
>
> Given that the MifosX platform has been around for a few years now,
>
> numerous organizations maintain multiple forks of the same . Without the
>
> commit history being carried over, upgrading these forks becomes an
>
> unnecessarily painful process.
>
>
> Also, the contribution history of around 78 volunteers to the original
>
> MifosX project is lost.
>
>
> Is there any reason for initializing fineract as a new git repository ?
>
>
> Regards,
>
> Vishwas
>
>
>
>
Re: Missing git history
Posted by ma...@live.de.
In addition we will honor Contributors more prominent in the future with a special thank you section at the website and for sure will add all current contributors there too.
Best,
Markus
.:: YAGNI likes a DRY KISS ::.
On Fri, Jan 29, 2016 at 9:59 PM -0800, <ma...@live.de> wrote:
Hey Vishwas,
The repackeging led to a delete and add of all files anyways, so a simple fetch merge could cause more harm than the creation of a new fork and manually transfer made changes to the code that never where contributed back.
In addition I'd suggest to do future code enhancements in a way that allows either a contribution back or keeps the forked base clean and mergable.
Best,
Markus
.:: YAGNI likes a DRY KISS ::.
From: Vishwas Babu
Sent: Saturday, January 30, 02:46
Subject: Missing git history
To: dev@fineract.incubator.apache.org
Hi,
https://github.com/apache/incubator-fineract doesn't carry over the commit
history from https://github.com/openMF/mifosx.
Given that the MifosX platform has been around for a few years now,
numerous organizations maintain multiple forks of the same . Without the
commit history being carried over, upgrading these forks becomes an
unnecessarily painful process.
Also, the contribution history of around 78 volunteers to the original
MifosX project is lost.
Is there any reason for initializing fineract as a new git repository ?
Regards,
Vishwas
Re: Missing git history
Posted by ma...@live.de.
Hey Vishwas,
The repackeging led to a delete and add of all files anyways, so a simple fetch merge could cause more harm than the creation of a new fork and manually transfer made changes to the code that never where contributed back.
In addition I'd suggest to do future code enhancements in a way that allows either a contribution back or keeps the forked base clean and mergable.
Best,
Markus
.:: YAGNI likes a DRY KISS ::.
From: Vishwas Babu
Sent: Saturday, January 30, 02:46
Subject: Missing git history
To: dev@fineract.incubator.apache.org
Hi,
https://github.com/apache/incubator-fineract doesn't carry over the commit
history from https://github.com/openMF/mifosx.
Given that the MifosX platform has been around for a few years now,
numerous organizations maintain multiple forks of the same . Without the
commit history being carried over, upgrading these forks becomes an
unnecessarily painful process.
Also, the contribution history of around 78 volunteers to the original
MifosX project is lost.
Is there any reason for initializing fineract as a new git repository ?
Regards,
Vishwas