Mailing-List: contact dev-help@fineract.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@fineract.incubator.apache.org
From: Sander van der Heijden <sandervanderheyden@musoni.eu>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: Missing git history
Message-Id: <C76DD32F-5630-4378-90FB-71F39B3438A9@musoni.eu>
Date: Sat, 30 Jan 2016 12:47:31 +0100
References: 
 <CAF6owcyma4=+J5snHRdPk-eWkXkkD0XK2nSds4LoK9PnSi6vhg@mail.gmail.com>
 <DUB407-EAS117787C0B10FCCF9B6ABE6295DC0@phx.gbl>
 <CAF6owczYa_6ijYxbrtR=_Ej8q76KJ8quP=pH4eDv_mR60ORYyA@mail.gmail.com>
 <DUB127-W276F6E0F26FB2194E243CE95DC0@phx.gbl>
 <CAF6owcxufWspjWAxUkZVfWwQ=J_AaFNLLa=iwJdteSN_HAG90A@mail.gmail.com>
 <DUB407-EAS2527E6E57C76943928093BC95DC0@phx.gbl>
In-Reply-To: <DUB407-EAS2527E6E57C76943928093BC95DC0@phx.gbl>
To: dev@fineract.incubator.apache.org

Hi guys,

+1 from me on keeping  history, it has proven to be very useful in troublesh=
ooting 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 perspecti=
ve?=20

S

Sent from my iPhone

> On 30 Jan 2016, at 11:49, <markus.geiss@live.de> <markus.geiss@live.de> wr=
ote:
>=20
>=20
>=20
> 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 ...
>=20
>=20
> 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.
>=20
>=20
> Aside from that keeping the history only to keep contributors mentioned is=
 not an argument to me.
>=20
>=20
> Best,
>=20
>=20
> Markus
>=20
>=20
> .:: YAGNI likes a DRY KISS ::.
>=20
>=20
>=20
>=20
>=20
>=20
> On Sat, Jan 30, 2016 at 2:26 AM -0800, "Vishwas Babu" <vishwas@confluxtech=
nologies.com> wrote:
>=20
>=20
>=20
>=20
>=20
> Markus,
>=20
> I would assume that redoing the same, i.e changing the package structure i=
n
> an IDE and then re-licencing (a search replace) shouldn't take much time a=
t
> all for the core team.
>=20
> Anyone maintaining a fork would be conversant enough with GIT to understan=
d
> 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.
>=20
> The Mifos community has always ensured that all releases are merged back
> into both master / develop branch. So migrating any one of them to finerac=
t
> is all that a fork maintainer would need to update his fork.
>=20
> 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=
.
>=20
> Regards,
> Vishwas
>=20
>=20
>> On Sat, Jan 30, 2016 at 3:05 PM, Markus Gei=C3=9F <markus.geiss@live.de> w=
rote:
>>=20
>> Vishwas,
>>=20
>> 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 lea=
d
>> to a
>> new BLOB in a new tree so git would recognize them as new not changed
>> files.
>>=20
>> The risk to 'act' like there is a history and others using the Apache rep=
o
>> as the new
>> upstream, loosing there files by accident b/c the files are 'deleted' was=

>> simply too
>> high.
>>=20
>> If we like to preserve the history all changes need to be reverted and
>> every single step
>> needs to be in its own commit.
>>=20
>> It would also not be feasible to move the whole repo over, because we onl=
y
>> can move
>> the recent develop. All open branches, and release branches should not be=

>> moved
>> for clarity reasons and to avoid confusion.
>>=20
>> Best,
>>=20
>> Markus
>>=20
>> .::YAGNI likes a DRY KISS::.
>>=20
>>> Date: Sat, 30 Jan 2016 13:02:26 +0530
>>> Subject: Re: Missing git history
>>> From: vishwas@confluxtechnologies.com
>>> To: dev@fineract.incubator.apache.org
>>>=20
>>> Markus,
>>>=20
>>> Git does an excellent job of recognizing renamed files. Merging forks
>> with
>>> the new package structure is a very straightforward process.
>>>=20
>>> What is the issue with retaining the commit history ?
>>>=20
>>> Regards,
>>> Vishwas
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Sat, Jan 30, 2016 at 11:29 AM, <markus.geiss@live.de> wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> Hey Vishwas,
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>> Best,
>>>>=20
>>>>=20
>>>> Markus
>>>>=20
>>>>=20
>>>> .:: YAGNI likes a DRY KISS ::.
>>>>=20
>>>>=20
>>>>=20
>>>> From: Vishwas Babu
>>>>=20
>>>> Sent: Saturday, January 30, 02:46
>>>>=20
>>>> Subject: Missing git history
>>>>=20
>>>> To: dev@fineract.incubator.apache.org
>>>>=20
>>>>=20
>>>>=20
>>>> Hi,
>>>>=20
>>>>=20
>>>> https://github.com/apache/incubator-fineract doesn't carry over the
>> commit
>>>>=20
>>>> history from https://github.com/openMF/mifosx.
>>>>=20
>>>>=20
>>>> Given that the MifosX platform has been around for a few years now,
>>>>=20
>>>> numerous organizations maintain multiple forks of the same . Without
>> the
>>>>=20
>>>> commit history being carried over, upgrading these forks becomes an
>>>>=20
>>>> unnecessarily painful process.
>>>>=20
>>>>=20
>>>> Also, the contribution history of around 78 volunteers to the original
>>>>=20
>>>> MifosX project is lost.
>>>>=20
>>>>=20
>>>> Is there any reason for initializing fineract as a new git repository ?=

>>>>=20
>>>>=20
>>>> Regards,
>>>>=20
>>>> Vishwas
>>=20
>>=20