@@ -566,6 +566,37 @@ boolean hasFileBasedTags() {
566
566
return true ;
567
567
}
568
568
569
+ /**
570
+ * Builds a Git tag list by querying Git commit hash, commit time, and tag
571
+ * names.
572
+ * <p>Repository technically relies on the tag list to be ancestor ordered.
573
+ * <p>For a version control system that uses "linear revision numbering"
574
+ * (e.g. Subversion or Mercurial), the natural ordering in the
575
+ * {@link TreeSet} is by ancestor order and so
576
+ * {@link TagEntry#compareTo(HistoryEntry)} always determines the correct
577
+ * tag.
578
+ * <p>For {@link GitTagEntry} that does not use linear revision numbering,
579
+ * the {@link TreeSet} will be ordered by date. That does not necessarily
580
+ * align with ancestor order. In that case,
581
+ * {@link GitTagEntry#compareTo(HistoryEntry)} that compares by date can
582
+ * find the wrong tag.
583
+ * <p>Linus Torvalds: [When asking] "'can commit X be an ancestor of commit
584
+ * Y' (as a way to basically limit certain algorithms from having to walk
585
+ * all the way down). We've used commit dates for it, and realistically it
586
+ * really has worked very well. But it was always a broken heuristic."
587
+ * <p>"I think the lack of [generation numbers] is literally the only real
588
+ * design mistake we have [in Git]."
589
+ * <p>"We discussed adding generation numbers about 6 years ago [in 2005].
590
+ * We clearly *should* have done it. Instead, we went with the hacky `let's
591
+ * use commit time', that everybody really knew was technically wrong, and
592
+ * was a hack, but avoided the need."
593
+ * <p>If Git ever gets standard generation numbers,
594
+ * {@link GitTagEntry#compareTo(HistoryEntry)} should be revised to work
595
+ * reliably in all cases akin to a version control system that uses "linear
596
+ * revision numbering."
597
+ * @param directory a defined directory of the repository
598
+ * @param interactive true if in interactive mode
599
+ */
569
600
@ Override
570
601
protected void buildTagList (File directory , boolean interactive ) {
571
602
this .tagList = new TreeSet <>();
@@ -596,41 +627,6 @@ protected void buildTagList(File directory, boolean interactive) {
596
627
new Object []{directory .getAbsolutePath (), String .valueOf (status )});
597
628
// In case of partial success, do not null-out tagList here.
598
629
}
599
-
600
- /*
601
- * Repository technically relies on the tag list to be ancestor
602
- * ordered.
603
- *
604
- * For an SCM that uses "linear revision numbering" (e.g. Subversion or
605
- * Mercurial), the natural ordering in the TreeSet is by ancestor order
606
- * and so TagEntry.compareTo(HistoryEntry) always determines the
607
- * correct tag.
608
- *
609
- * For GitTagEntry that does not use linear revision numbering, the
610
- * TreeSet will be ordered by date. That does not necessarily align
611
- * with ancestor order. In that case,
612
- * GitTagEntry.compareTo(HistoryEntry) that compares by date can find
613
- * the wrong tag.
614
- *
615
- * Linus Torvalds: [When asking] "'can commit X be an ancestor of
616
- * commit Y' (as a way to basically limit certain algorithms from
617
- * having to walk all the way down). We've used commit dates for it,
618
- * and realistically it really has worked very well. But it was always
619
- * a broken heuristic."
620
- *
621
- * "I think the lack of [generation numbers] is literally the only real
622
- * design mistake we have [in Git]."
623
- *
624
- * "We discussed adding generation numbers about 6 years ago [in 2005].
625
- * We clearly *should* have done it. Instead, we went with the hacky
626
- * `let's use commit time', that everybody really knew was technically
627
- * wrong, and was a hack, but avoided the need."
628
- *
629
- * If Git ever gets standard generation numbers,
630
- * GitTagEntry.compareTo(HistoryEntry) should be revised to work
631
- * reliably in all cases akin to an SCM that uses "linear revision
632
- * numbering."
633
- */
634
630
}
635
631
636
632
@ Override
0 commit comments