Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I <em>think</em> what you're actually asking boils down to: "if I do <code>git branch -d old_homepage</code> will the commits get lost", and the answer is: "Deleting the name only deletes the <em>name</em>; the commits themselves stick around as long as you can see them in <code>git log --all</code>, and actually even longer."</p> <p>To visualize this better, run something like <code>gitk --all</code> or <code>gitk --tags</code> (try both on some complex git repos). Scroll around through the commits. Now imagine putting a sticky note on any commit. That's a "tag" or "branch" name. Take the sticky note off. Commit is still there, right? :-)</p> <p>That leaves one obvious question: when do things like commits <em>actually</em> go away? The answer is: only after you remove <em>all</em> the names that lead to them. The <code>gitk</code> command (like most other git commands) starts with the name <code>HEAD</code>. If you give it <code>--all</code> it adds all the branch names it can find. If you give it <code>--tags</code> it adds all the tag names it can find. Then it works backwards, looking at each commit to see what other commit(s) it refers to.</p> <p>Git removes things (commits, etc) when there is no way to find them by starting at one of these obvious names and working backwards. (Even then it waits a long time, 30 to 90 days by default.) So, if you add a branch or tag label to an old commit whose number you found by doing <code>git log</code> for instance, that gives you a new obvious name for that commit number; but removing again it is safe as long as it's not the <em>only</em> way to find it by name.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload