[TYPO3-core] Git Experts: Fix amnesia?

[Peter Niederlag]

Hi,git

On 17.10.2012 10:22, Helmut Hummel wrote:
> Hi,
> 
> what I learned from using Git is that nearly anything is possible.
> Now I have a challenging problem I'd like to discuss.
> 
> When moving to namespaces, we moved and at the same time changed files
> in our master branch.
> 
> With doing both we lost our complete history of the newly renamed files.

git has no "track rename/move" operation! git has a builtin algorithm
that detects renames/moves. This is based on detecting changes to the
tree/file contents (It doesn't matter if you use 'git mv' or 'git
add/git rm' as long as the result goes into one commit/tree).

That means: if you relocate a file *and* change huge chunks of its
content in *one* commit chances are high git commands wont detect the
rename. This is a none reversable thing! IMHO no way you can fix this
with more commits. :(

Also, if you *duplicate* a file to another location and keep the old
file modified in place for backwards compat manners this duplicated file
wont have a connection to the history by default (git log
t3lib/class.t3lib_beuserauth.php, git log
typo3/sysext/core/Classes/Authentication/BackendUserAuthentication.php).
You could of course rename first and commit, change content/commit,
readd backwards compat file in old location(having "no" history)/commit.

> That is really a pity and if possible I want to fix that.

hmmm...

> I have two ideas how we can manage to do that.
> 
> 1. Rewrite the history of the *remote* repo

imho rewrite is the only chance and needs proper preparation in order to
get the desired affect. To me it seems like this will be quite hard work. :(

As master is not in production/released yet I would consider a 'git
fetch --force'(needed for a rewritten remote branch) a small burden that
we could force our git users to do.

*But* any pending changes probably would have to be cherry-picked, I
seriously doubt rebasing will work after  such a huge history rewrite.

> 2. a) Change the content of the original files with their current
>       content
>    b) Remove the new files
>    c) Move the "old" files to their new location
>    d) Add the dummy files in the old location.

imho not possible.

[...]

> Is it worth fixing this history loss?

Tough question... not sure yet. In general the history is worth to be
kept but fixing it now... ?
There are workarounds like the "git log --follow" available in cases needed.

And more opinions on this question?

> Can someone put effort on this task?

pheew... I can try to assist but wont be able to spend more than three
ours in the next 7 days on this task. :(

Could someone maybe point me into the number of commits that might need
to be changed/reordered? Is this limited to "git show
4612259a457f43edaf7" or some more?

Greets,
Peter