git (ls-remote) - List "remote" branches ordered by creation date

Question

I know that with the git command below I can list all my "remote" branches...

[someone@someone-pc somerepo]$ git ls-remote
Username for 'https://somegit.com': someone
Password for 'https://[email protected]': 
From https://somegit.com/somepath/somerepo.git
32b73a94a2ef1be27298a7bbf6670670c9ad4892        HEAD
99cfe797ee2f4cd3fc12ea1aef8dc4ea0f3538c7        refs/heads/a_branch
687332d5e82436d806fea2c22ac5e8772e73b33a        refs/heads/b_branch
b1d82987dd87b99c505282cbcdf1d4c4d36be2d2        refs/heads/c_branch
32d4a73e686524e50a92880ddbd744d1363834bb        refs/heads/d_branch
097ad2a9a69399996f7e1864436d483b2a85e3c1        refs/heads/e_branch
1e92bb0aa448a840e04928272759a3941774575b        refs/heads/f_branch
32b73a94a2ef1be27298a7bbf6670670c9ad4892        refs/heads/master

QUESTION: Is there a way to list these branches ordered by creation date?

Thanks! =D

---

UPDATE:

To illustrate I would like something sorted like the gitlab branches list...

Answer 1

What git ls-remote does is call up the other Git—the one at the URL you see above—and ask it about its references: HEAD, branch names, tag names, and so on. But the only information that it sends are those names and the hash IDs.

As I noted in comments above, each commit—represented by a hash ID, which is sort of the commit's true name—has two timestamps in it.¹ To obtain either or both time stamp, you must have the commit. So this means git ls-remote is not sufficient in general: you might not have the commits whose hash IDs you get from the other Git.

What you need to run first is git fetch, which starts the same way: it calls up some other Git and gets from it a list of their branches, tags, etc., and the hash IDs that each of those names represent. Then, for their branches, your Git will create or update your remote-tracking names: their master becomes your origin/master, for instance. Their develop becomes your origin/develop. Whatever names they have—refs/heads/* being the full form—your Git creates or updates your own corresponding refs/remotes/origin/* name. But before your Git can do that, your Git must obtain the commits themselves as well, so for any commits they have that you don't, that your Git needs, your Git gets those.

You may want to add --prune (git fetch -p for short) to direct your own Git to delete any remote-tracking name you have now that no longer corresponds to a branch in their Git. If you don't, you'll keep stale remote-tracking names forever (or until you explicitly prune them). This isn't really harmful so much as clutter-y.

Now you have all of their commits, plus any of your own you have not sent. You also have all of their names, changed into your remote-tracking names.

You can view these branches with git branch -r. The default sort order for git branch is alphabetic-within-group.² But you can give a --sort=key option:³

git branch -r --sort=authordate

or:

git branch -r --sort=committerdate

which will sort based on the corresponding time stamp stored in the commit to which each remote-tracking name points.

Hence:

git fetch -p
git branch -r --sort=committerdate

should get you what you want (unless you want author date; see footnote 1).

(Aside: I like to configure fetch.prune to true in my per-user configuration, so that all fetches act like git fetch --prune always.)

---

¹The two timestamps are the author timestamp and the committer timestamp. In many cases, both hold the same date-and-time anyway. A new commit in general gets both the same, and then if you copy the commit to a new and improved one, via git commit --amend or git rebase or any of the many other ways that can do that, the new and improved commit has the old commit's author information, and you-and-now as the committer information.

²Technically, it's more ASCII-betic, or UTF-8-betic, than alphabetic: a digit comes before uppercase, and uppercase comes before lowercase.

³Your git branch needs to be new enough to have the --sort option, which was introduced to git branch in Git 2.7. If your Git is older, consider using git for-each-ref.