Hello git devs,
I'm toying with an idea of an improvement I would like to work on, but
not sure if it would be desirable enough to be considered good to merge
in the end, so I'm requesting your opinions before I work on it.
AFAIU git stores the contents of a repo as a sequence of patches in the
.git metadata folder. So then let's look at an example to illustrate my
point more easily.
Repo foo contains the following 2 commits:
1 file, first commit, with the content:
+First Line
+Second Line
+Third Line
2nd and last commit:
First Line
Second Line
-Third Line
+Last Line
Simple enough, right?
But, what if we decided to store it backwards in the metadata?
So first commit would be:
1 file, first commit, with the content:
+First Line
+Second Line
+Last Line
2nd commit:
First Line
Second Line
-Last Line
+Third Line
This would bring some advantages, as far as I understand:
1. `git clone --depth 1` would be way faster, and without the need of
on-demand compressing of packfiles in the server side, correct me if I'm
wrong?
2. `git clone` would be able to allow a "fast operation, complete in the
background" mode that would allow you to download the first snapshot of
the repo very quickly, so that the user would be able to start working
on his working directory very quickly, while a "background job" keeps
retreiving the history data in the background.
3. Any more advantages you see?
I'm aware that this would have also downsides, but IMHO the benefits
would outweigh them. The ones I see:
1. Everytime a commit is made, a big change of the history-metadata tree
would need to happen. (Well but this is essentially equivalent to
enabling an INDEX in a DB, you make WRITES more expensive in order to
improve the speed of READS.)
2. Locking issues? I imagine that rewriting the indexes would open
longer time windows to have locking issues, but I'm not an expert in
this, please expand.
3. Any more downsides you see?
I would be glad for any feedback you have. Thanks, and have a great day!
Andrés
--
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html