[TYPO3-core] [RFC] Upcoming Git changes

[Ernesto Baschny [cron IT]]

Helmut Hummel schrieb am 18.05.2013 12:30:

> On 15.05.13 10:57, Michael Stucki wrote:
> 
>> We see a lot of problems coming if Git history will be rewritten.
> 
> Can you elaborate on the problems?
> I would still prefer the history rewrite.

I guess one should describe what history exactly would have been
rewritten. As far as I understood is that we only rewrite the history
starting from the namespacing merge, in order to fix "git blame" on the
moved files.

But the plan has always be to merge the submodules into the core as a
regular "subtree merge", meaning that the submodules are still there in
older versions. I don't know of any other method to do it otherwise.

> My suggestion would be to:
> 
> 1. Create a new repo and Gerrit project following the new naming scheme
> 2. Fill the new repo with the rewritten history
> 3. Make the old repo read only
> optional: Have a script to transfer all open changes in Gerrit to the
> new Project.
> 
> Benefits:
> 
> * Clean history
>   # No hassels when fetching older versions where submodules are used

My first thought that this would be the case too, but how I understood
is that the submodules will still be present in our older history. So no
benefit "when fetching older versions".

>   # Working git blam without manual interaction

This is the true benefit, but can also be achieved very beautifully by
the recommended "git replace". This is not mandatory and only really
affects the output of git blame and allows git log to follow the files
across their moving (as far as I understood).

> * No breaking changes for clones of the "old" repo

If we move the repo to a new name anyway, this benefit will be there
regardless of what we do in the new repository.

> Downsides:
> * Merge freeze for the time until the new repo is ready (1 Day?)
> * Bit of more work for tranfering open change requests
> * forge core project could have broken associated merges in the tickets
> 
> Are there more downsides? Or dou you consider the last one as blocker
> (which I would understand)?

I guess most important drawback of rewriting history would be:

There are lots of developers and agencies working with their own forks /
repos of TYPO3, which branch from our known official repo. Developers
working on some "major feature" or stuff to be pushed to gerrit,
agencies having their hotfixes applied in their local git.

Those are kept in sync with our main repo with commands like "git merge
origin/TYPO3_4-5" for example. By rewriting the history (new SHA1 since
october last year) your local git looses track of any connection to the
old history and you end up having conflicts.

Of course these can be manually solved by "cherry-pick" or rebasing
changes somehow, but this requires lots of manual interaction and
questions (which we won't be able to answer always) will arise.

So I don't see the benefit of rewriting history considering that it
breaks more than it helps.

Cheers,
Ernesto