Submodules have a name in the configuration, but this name is simply
the path at which the submodule was initially checked in (by default
-- the name is totally arbitrary). If a submodule is moved, it
retains its original name, but its path changes. Since we discover
submodules inside trees, we have their path but not necessarily their
name.
Make the submodules() function return the submodule hash indexed by
path rather than name, so that renamed submodules can be looked up.
Signed-off-by: David Turner <novalis@novalis.org>
- Previously, we sorted commits by date, which seemed to work okay.
- The one edge case where this failed was when multiple commits have the same
commit date (for example: when a range of commits are cherry picked with a
single command, they all have the same commit date [and different author
dates]).
- Commits with the same commit date would be sorted arbitrarily, and usually
break the network graph.
- This commit solves the problem by both sorting by date, and by sorting
topographically (parents aren't displayed until all their children are
displayed)
- Include review comments from @adamniedzielski
A more detailed explanation is present here:
https://gitlab.com/gitlab-org/gitlab-ce/issues/30973#note_28706230
- We upgraded `rugged` to 0.25.1.1 in !10286 for %9.1
- Prior to this upgrade, the default sort order for commits returned by
`Gitlab::Git::Repository#find_commits` was `Rugged::SORT_DATE`, which the
graph relied on.
- While upgrading `rugged`, the MR also changed this default to
`Rugged::SORT_NONE`, which broke commit ordering in the graph.
- This commit adds an option to `Gitlab::Git::Repository#find_commits` to sort
by date, and changes the graph builder `Network::Graph` so it explictly
requests the `:date` sort order
This is analogous to `git log -- foo bar baz`, but not the same as
`Gitlab::Git::Repository#log(path: 'foo bar baz')`, which would run `git
log -- 'foo bar baz'`.