2

A few days ago I forked the current branch from master in the terminal. Since then, have made a few commits, but when I type git log, I see the previous commits, the ones I made on the current branch, and the ones other people made on master. Can only assume, somewhere between the other people's commits and mine, I would have (while on the master branch) typed in 

git checkout -b newbranch

Is there a git command which will tell you the exact timestamp when newbranch was forked from master?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
cardamom
  • 6,873
  • 11
  • 48
  • 102
  • If the accepted answer does not work for you, state why, and someone can reopen this question for you. – Tim Biegeleisen Jan 22 '19 at 14:50
  • @TimBiegeleisen yes, would like it reopened. `git merge-base master newbranch` or `git merge-base newbranch master` give you the commit hash of the most recent common ancestor, which is nice, but it still doesn't answer the question, when was the branch forked off, it only tells us "probably within a few minutes or hours of this last commit, but not before then." `--fork-point` doesn't seem to help either. – cardamom Jan 22 '19 at 14:59
  • Use `git show -s --format=%ci `, and replace `commit` with the hash from the merge-base command. – Tim Biegeleisen Jan 22 '19 at 15:04
  • Thanks, that works nicely to show you a timestamp, but it is a timestamp of that commit, not of the forking that happened later. Anyway, I suspect the truth of the situation is probably that git does not keep a record of forking occurred. – cardamom Jan 22 '19 at 15:10
  • Thanks, will be interesting to hear if it is possible. – cardamom Jan 22 '19 at 15:13
  • It would be just as accurate to say that most "close / dup" votes show no actual effort to understand what the new question was actually asking. We have people here who see one matching keyword and immediately flag dupes. (And try to use comments to answer questions. And basically do anything they can to avoid the intended question-then-answer flow) – Mark Adelsberger Jan 22 '19 at 15:47

2 Answers2

2

Not really. That isn't something git tracks. In fact, it doesn't even track the fact that newbranch was specifically branched "from master". (As an aside, I suggest not using "fork" to refer to the relationship between branches, since "fork" has a specific meaning with git repos and OSS projects in general.)

As RomainValeri suggests, you might be able, under specific circumstances, to look at filesystem timestamps for the metadata associated with the branch; but those aren't guaranteed to mean anything. Sometimes the file they mention either won't exist, or will have been created at a time that bears no relationship to branch creation. And even if it does exist and does reflect the right timestamp, it won't mean much; because "creating a branch" only means that a new ref was created. It doesn't mean it is (or ever was) checked out, or say anything about which ref(s) would contain new commits.

The easiest way to visualize how things are now is to get a commit graph that shows the positions of branches and other refs. You could use something like git log --graph --all --full-history. (The --full-history option is probably unnecessary, but since the point is that we're not exactly sure what's going on, this will give the most true picture.) Or you might find a GUI makes it easier to read; I often use gitk --all --full-history when I need to look at the "big picture".

Keep in mind that the commits from before the branch was created definitely will be shown by default. That is, if you have

A -- B -- C <--(master)
      \
       D <--(newbranch)

then a log of D by default includes A, B, and D, as this is the full history of the code as it exists at newbranch. If you're seeing C, that suggests that you really aren't on newbranch at all (and the above graph isn't what you really have in that case).

The rest of this may be a tangent, but just in case...

The reason A and B are included by default is because, again, git doesn't know/care which branch was created from which other branch, or anything like that. In the above picture, newbranch could have been the original branch and master could've been branched from it at B; to git, this is the same as newbranch being branched from master at B. Or D could've been created in detached HEAD state, and newbranch could've been created after the fact to preserve D. Or a lot of other things could happen.

If you want to see just commits that were added on newbranch, you could say something like git log master..newbranch (telling log to exclude any commits that are part of master's history).

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • Thanks, so by design, git does not care so much about branching and "when". `gitk --all --full-history` is good, even if you don't know exactly _when_ it narrows it down. – cardamom Jan 22 '19 at 15:56
  • BTW - the argument in the other command, `--graph--all` is not recognised, `--graph-all` also not – cardamom Jan 22 '19 at 15:56
  • @cardamom That was a typo (which I've fixed). It's two arguments `--graph` and `--all` – Mark Adelsberger Jan 22 '19 at 16:06
1

When you created your new branch newbranch, git writes a file (containing the SHA-1 of the commit it points to) here : .git/refs/heads/newbranch. Maybe check its creation timestamp?

(Of course, this would be a solution only on the local repo where the branch originated, not from another repo.)

Romain Valeri
  • 19,645
  • 3
  • 36
  • 61
  • While that might give a good indication of branch creation time under some circumstances (albeit reasonably common ones), it also can be very misleading and doesn't mean much even when it's "accurate". I wouldn't put much focus on trying to determine when the ref metadata was created personally – Mark Adelsberger Jan 22 '19 at 15:44
  • Thanks, I don't normally go in that `.git/` folder for fear of breaking something. Had a poke around in there just then in `.git/refs/heads/` and in other places. Also used recursive list `ls -lR` but couldn't really find some obvious thing which happened between the relevant time stamps. – cardamom Jan 22 '19 at 15:47
  • @MarkAdelsberger To be fair, I agree with you, this is not a good way to proceed, but I tried to give a factual answer to the question actually asked. Thanks for the much more ultimately useful explanation you gave in your answer. – Romain Valeri Jan 22 '19 at 15:47