This is no RFE but rather recurring thoughts whenever I'm working with
commit graphs: a topological index attribute for commit objects would be
incredible useful. By "topological index" I mean a simple integer for
which following condition holds true:
if commit C is part of the history of commit D,
then C's topological index is smaller than D's index
This would allow topological sorting of commits (e.g. in queues) on the
fly and quickly give a "no" answer on the question whether D is part of
C's history.
-Marc
On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
[off-list ref] wrote:
This is no RFE but rather recurring thoughts whenever I'm working with
commit graphs: a topological index attribute for commit objects would be
incredible useful. By "topological index" I mean a simple integer for which
following condition holds true:
Look for "generation numbers" in the list archive, perhaps?
On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano [off-list ref] wrote:
On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
[off-list ref] wrote:
quoted
This is no RFE but rather recurring thoughts whenever I'm working with
commit graphs: a topological index attribute for commit objects would be
incredible useful. By "topological index" I mean a simple integer for which
following condition holds true:
Look for "generation numbers" in the list archive, perhaps?
Thanks for the pointer to the interesting discussions.
In http://www.spinics.net/lists/git/msg161363.html
Linus wrote in a discussion with Jeff:
Right now, we do *have* a "generation number". It's just that it's
very easy to corrupt even by mistake. It's called "committer date". We
could improve on it.
Would it make sense to refuse creating commits that have a commit date
prior to its parents commit date (except when the user gives a
`--dammit-I-know-I-break-a-wildy-used-heuristic`)?
With the proposal to refuse an earlier committer date we would avoid
the corruption by mistake and only allow for corruption by actual
users intention. And then going forward we could rely more on the
committer date than we do today (i.e. some algorithms can go faster)?
For that we'd
* need to document, what stuff actually breaks if the user overwrites
the committer date to be earlier
* and add a switch `--go-slow-because-dates-are-broken`
This seems to be the easiest fix in 2016 to me as that would require
to make just a very small change in commit creation, and we can postpone
the second part (relying even more on dates) until someone wants to fix it?
Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
W dniu 2016-06-29 o 20:59, Junio C Hamano pisze:
On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
[off-list ref] wrote:
quoted
This is no RFE but rather recurring thoughts whenever I'm working with
commit graphs: a topological index attribute for commit objects would be
incredible useful. By "topological index" I mean a simple integer for which
following condition holds true:
if commit C is part of the history of commit D,
then C's topological index is smaller than D's index
This would allow topological sorting of commits (e.g. in queues) on the fly
and quickly give a "no" answer on the question whether D is part of
C's history.
Look for "generation numbers" in the list archive, perhaps?
If I remember correctly the discussion, the problem by adding generation number
to the commit object format was twofold (at least).
First there was a problem of backward compatibility, namely what to do with
existing repositories, where commit objects do not have generation number.
Objects in Git are immutable (and I think replacements mechanism wasn't
invented yet - anyway too many replacements would slow down operations
I guess).
Second objection was of philosophical nature: generation numbers duplicate
(cache) information that is stored in the graph of revisions. Also, what
if they get out of sync?
That is, if I remember the summary of that discussion correctly.
Also, generation numbers (graph level) only help with topological sorting;
for finding of two commits are connected (two nodes are connected) people
play with different ideas, for example FELINE index:
http://openproceedings.org/EDBT/2014/paper_166.pdf
Nowadays there is also [compressed] bitmap index (if enabled), though I am
not sure if it is yet used to speed-up reachability queries
http://githubengineering.com/counting-objects/
https://www.eclipsecon.org/2013/sites/eclipsecon.org.2013/files/Scaling%20Up%20JGit%20-%20EclipseCon%202013.pdf
--
Jakub Narębski