Hi
I can not rebase symlinks of an 6 years old repository.
See attached files (two languages, EN auto translation) for more details.
Created with `git bugreport`
Kind regards
Florian
[EN](#EN) Translated by https://www.deepl.com/translator
# EN
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your problem.
understand your problem.
What did you do before the error occurred? (Steps to reproduce your error
reproduce your error)
For 6 years I only did remote pushes locally to my local master.
github.com then refused to accept one.
The reason:
And now github.com but also `git` itself are bitching in detail.
github.com, as it no longer accepts a push:
index-pack failed
remote: error: object [hash]: gitmodulesSymlink: .gitmodules is a symbolic link
And `git` itself also aborts. So I can't solve the problems this way.
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Rewrite [SomeHash] (3/185) (0 seconds passed, remaining 0 predicted) \
error: Invalid path '.gitmodules' Could not initialize the index
The same attempt also failed with an older VM where `git`
version 2.11.0 was still available.
What did you expect to happen? (Expected behavior)
Rebase should work. Always :-)
What happened instead? (Actual behavior)
Abort of git.
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Rewrite [SomeHash] (3/185) (0 seconds passed, remaining 0 predicted) \
error: Invalid path '.gitmodules' Could not initialize the index
What is the difference between what you expected and what actually happened?
really happened?
With a current git version I can't fix such errors.
But in general I think the exclusion of symlinks to git system files is a mistake. It is implemented too sweepingly in my eyes.
Any other comments you would like to add:
My `.gitmodules` were always a matching file in the same directory to
to become aware that something is changing during a merge.
Branches are staging areas for me, among other things)
```
.gitmodules -> symlinks to one of these files
(depending on the current branch)
-> .gitmodules_stable
^ ------------------ Staging to stable, release
-> .gitmodules_testing
^ ------------------ Staging to testing, testing and preview
-> .gitmodules_unstable
^ ^ ^---<---------<-- Feature branch A
+-----<---------<-- Feature branch B
+-------<---------<-- Feature branch C ...
```
With a merge unstable -> testing (-ff), settings from unstable would simply be
would simply be included/adopted in testing without drawing attention to it.
attention. This also has the consequence that you are no longer made aware
that the dependencies of the submodules must also be raised,
before the merge is clean/finished.
If you are working on several submodules, this makes perfect sense. Especially
if you don't have or want to have everything online in order to check/test the current
to check/test the current status etc. before you then bind the hashes of the submodules and
then make everything public piece by piece depending on the dependency.
What an effort :-/
With `git` itself (version 2.39.0, Debian Bookworm, 2023) you can still work locally.
continue to work. With github.com, however, the fun is over. If it is in the
repository `git` system files like `.gitignore` or `.gitmodules` that are symlinks
are symlinks, github.com refuses to do any work to fix the bugs.
the bugs. Neither via the web interface nor via `git push --force` itself. Whew.
So: After 6 years! In between there were local updates from time to time, but these were
were not made public. The operating system, a Debian, is updated about every
updated every two years. So there have been at least 3 new `git` versions since then for
for this project. With the current version of `git` I cannot fix the problems
fix the problems. And that is really bad!
## Solution
Option 3. was the solution. A Debian Wheezy (7.3) brought a `git`
version 1.7.10.4, which I used to rebase one of the known and problematic commits.
known and problematic commits. I may have traveled too far into the
past, but this gave me a basis for testing.
Maybe it will stay that way and everything will be fine again?
Following this, and in order to do everything automatically again, the
git filter-branch came to mind again:
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Did its job, but didn't help anything Direction github.com as `push --force` for
for this branch.
- git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
+ git filter-branch --tree-filter 'rm -f .gitmodules'
So: complete and over everything please.
But to make this situation tidy:
.gitmodules ->- symlink to one of these... ->-
-> .gitmodules_master
-> .gitmodules_stable
-> .gitmodules_testing
-> .gitmodules_unstable
'rm -f .gitmodules' deletes, but does not delete the underlying bindings of the
submodules. Here, too, there were mixtures in the use/application, as the
history clearly showed on closer inspection. But the roadmap for doing it this way
remained consistent.
I had to fetch the local repository from the backup quite often in order to be able to repeat the many test steps.
to be able to repeat the many steps of tests...
Finally: Submodules (`.gitmodules`) were always a symlink in the idea.
So in order for it to fit for the repair in the future, all symlinks must be resolved into a
real file, so that the rebase via `git filter-branch
--tree-filter` can run cleanly and the dependencies in the base remain clean.
remain clean. And that looks like this:
# If .gitmodules is a symlink:
# - Find the path to the real file
# - Delete the symlink
# - Copy the real file to .gitmodules
git filter-branch --tree-filter \
'if [ -h .gitmodules ];then loc=$(readlink .gitmodules); rm -f .gitmodules; cp $loc .gitmodules; fi;'
This solved the problem. Symlinks removed and replaced with the real content
replaced by the real content. However, the complete history has now been rewritten. Locally as
as well as the newer `git` versions (clients and local server) reported
no more errors.
# Conclusion
I don't like the way `git` currently works. Symlinks help in
my case. They are transparent and available in every branch within the repository
and are maintained.
The most important thing: they make work easier as they draw attention to changes.
changes. This saves an enormous amount of time and running around afterwards if you forget to
to correct the submodules because with an almost forward merge it is simply treated
treated as new = better. Submodules are bound in the same branch workflow
in the same branch workflow.
Please check the rest of the error report below.
You can delete any line you do not want to report.
[System Info]
git Version:
git version 2.39.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64
Compiler Info: gnuc: 12.2
libc Info: glibc: 2.36
$SHELL (typically, interactive shell): /bin/zsh
[Aktivierte Hooks]
[DE](#DE)
[EN] See other text file
# DE
Vielen Dank für das Ausfüllen eines Git-Fehlerberichts!
Bitte antworten Sie auf die folgenden Fragen, um uns dabei zu helfen, Ihr
Problem zu verstehen.
Was haben Sie gemacht, bevor der Fehler auftrat? (Schritte, um Ihr Fehler
zu reproduzieren)
6 Jahre lang habe ich nur lokal zu meinem lokalen master remote pushes gemacht.
github.com hat dann eine Annahme verweigert.
Der Grund:
Und nun sind github.com aber auch `git` selbst im Detail zickig.
github.com, da es einen Push nicht mehr akzeptiert:
index-pack failed
remote: error: object [hash]: gitmodulesSymlink: .gitmodules is a symbolic link
Und `git` selbst bricht auch ab. Ich kann die Probleme so also nicht lösen.
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Rewrite [SomeHash] (3/185) (0 seconds passed, remaining 0 predicted) \
error: Invalid path '.gitmodules' Could not initialize the index
Der gleiche Versuch scheiterte ebenfalls mit einer älteren VM, wo noch `git`
Version 2.11.0 verfügbar war.
Was haben Sie erwartet, was passieren soll? (Erwartetes Verhalten)
Rebase soll funktionieren. Immer :-)
Was ist stattdessen passiert? (Wirkliches Verhalten)
Abbruch von git.
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Rewrite [SomeHash] (3/185) (0 seconds passed, remaining 0 predicted) \
error: Invalid path '.gitmodules' Could not initialize the index
Was ist der Unterschied zwischen dem, was Sie erwartet haben und was
wirklich passiert ist?
Mit einer aktuellen git Version kann ich derartige Fehler nicht bereinigen.
Aber ansich halte ich das ausgrenzen von symlinks zu git system Dateien für einen Fehler. Es ist zu Pauschal in meinen Augen implementiert.
Sonstige Anmerkungen, die Sie hinzufügen möchten:
Meine `.gitmodules` waren immer eine passende Datei im gleichen Verzeichnis, um
bei einem Merge darauf aufmerksam zu werden, das sich etwas ändert.
Branches sind bei mir u.a Staging- Bereiche)
```
.gitmodules -> symlinks zu einer dieser Dateien
(abhängig zum aktuellen Branch)
-> .gitmodules_stable
^ ------------------ Staging to stable, release
-> .gitmodules_testing
^ ------------------ Staging to testing, testing and preview
-> .gitmodules_unstable
^ ^ ^---<---------<-- Feature branch A
| +-----<---------<-- Feature branch B
+-------<---------<-- Feature branch C ...
```
Bei einem merge unstable -> testing (-ff) würden Einstellungen von unstable
einfach in testing mit einbezogen/übernommen werden, ohne darauf aufmerksam zu
werden. Was auch zur Folge hat, dass man nicht mehr darauf aufmerksam gemacht
wird, das die Abhängigkeiten der Submodule ebenfalls angehoben werden müssen,
bevor der merge sauber/ fertig ist.
Wenn an mehreren Submodulen gearbeitet wird, macht das durchaus Sinn. Gerade
dann, wenn man eben nicht alles online hat oder haben will, um einen aktuellen
Stand zu prüfen/testen etc. bevor man dann die Hashes der Submodule bindet und
alles dann je nach Abhängigkeit Stück für Stück öffentlich stellt.
Was für ein Aufwand :-/
Mit `git` selbst (Version 2.39.0, Debian Bookworm, 2023) kann man lokal noch
weiter arbeiten. Bei github.com ist allerdings Schluss mit lustig. Wenn es im
Repository `git` System Dateien gibt wie `.gitignore` oder `.gitmodules` die
Symlinks sind, verweigert github.com jegliche Arbeit, die Bugs beseitigen zu
können. Weder über das Webinterface noch via `git push --force` selbst. Uff.
Also: Nach 6 Jahren! Dazwischen gab es lokal immer wieder mal Updates, die aber
nicht öffentlich gestellt wurden. Das Betriebssystem, ein Debian, wird etwa alle
zwei Jahre aktualisiert. Neue `git` Versionen sind also mind. 3 Stk. seither für
dieses Projekt dabei. Mit der aktuellen Version von `git` kann ich die Probleme
allerdings nicht beheben. Und das ist wirklich schlecht!
## Lösungsweg
Option 3. war dann die Lösung. Ein Debian Wheezy (7.3) brachte eine `git`
Version 1.7.10.4 mit, mit der ich einen Rebase auf einen der mir bekannten und
problembehafteten Commits zulies. Ich bin vielleicht zu weit in die
Vergangenheit gereist, aber hiermit hatte ich erst einmal eine Basis zum testen.
Vielleicht bleibt es so und alles ist wieder gut!?
Darauf folgend und, um wieder automatisch alles zu erledigen, kam mir der
git filter-branch wieder in den Gedanken:
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Tat seinen Dienst, half aber nichts Richtung github.com als `push --force` für
diesen Branch.
- git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
+ git filter-branch --tree-filter 'rm -f .gitmodules'
Also: komplett und über alles bitte.
Damit diese Situation aber ordentlich wird:
.gitmodules ->- symlink zum einem dieser... ->-
-> .gitmodules_master
-> .gitmodules_stable
-> .gitmodules_testing
-> .gitmodules_unstable
'rm -f .gitmodules' löscht, löst aber nicht die zugrunde liegenden Bindungen der
Submodule. Auch hier gab es Mischungen in der Nutzung/ Verwendung, wie die
Historie beim genauen betrachten deutlich zeigte. Aber der Fahrplan, es so zu
machen, blieb einheitlich.
Ich habe das lokale Repository recht oft aus dem Back-up holen müssen, um dann
die vielen Steps von Tests wiederholen zu können...
Schließlich: Submodule (`.gitmodules`) waren in der Idee immer ein Symlink.
Damit es zukünftig für die Reparatur passt, müssen also alle symlinks in eine
echte Datei aufgelöst werden, damit der rebase via `git filter-branch
--tree-filter` sauber laufen kann und die Abhängigkeiten in der Basis sauber
bleiben. Und das sieht dann wie folgt aus:
# Wenn .gitmodules ein symlink ist:
# - Finde den Pfad zur echten Datei
# - Lösche den Symlink
# - Kopiere die echte Datei zu .gitmodules
git filter-branch --tree-filter \
'if [ -h .gitmodules ];then loc=$(readlink .gitmodules); rm -f .gitmodules; cp $loc .gitmodules; fi;'
Damit war dieses Problem erledigt. Symlinks weg und durch den echten Inhalt
getauscht. Allerdings wurde nun die komplette History neu geschrieben. Lokal als
auch die neueren `git` Versionen (Klienten und lokaler Server) meldeten
keinerlei Fehler mehr.
# Fazit
Ich mag diese Funktionsweise von `git` aktuell hierzu nicht. Symlinks helfen in
meinem Fall. Sie sind transparent und in jedem Branch innerhalb des Repositories
verfügbar und werden gepflegt.
Das wichtigste: Sie erleichten die Arbeit da sie auf Veränderungen aufmerksam
machen. Das spart ungemein viel Zeit und das hinterher laufen wenn man vergisst
die Submodule zu korrigieren da es bei einem fast forward merge schlicht weg
als neu = besser behandeld wird. Submudule werden im gleichen branch-Workflow
so gebunden.
Bitte überprüfen Sie den restlichen Teil des Fehlerberichts unten.
Sie können jede Zeile löschen, die Sie nicht mitteilen möchten.
[System Info]
git Version:
git version 2.39.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64
Compiler Info: gnuc: 12.2
libc Info: glibc: 2.36
$SHELL (typically, interactive shell): /bin/zsh
[Aktivierte Hooks]
# EN
