I played with another remote called tmp
. I added the remote and pushed the branches master
and new-branch
. Then I deleted the the tmp
remote.
Now the branches tmp/master
and tmp/new-branch
are detached. I don't need them anymore. How do I delete them along with their commits?
Here is graph on my repo now:
* a856b8c - (HEAD -> master, tag: abc, origin/master) Update
| * 8a142e4 - (tmp/master) Update
|/
| * 5d43564 - (tmp/new-branch) New commit
| * f9f33d9 - New commit
| * 9869631 - New commit
| * 03cdb15 - New commit
| * 7a24a77 - Test
|/
* 97b8dcd - Skip lines
So I want to delete commits: 8a142e4, 5d43564 and so on from the repo's history.
CodePudding user response:
Use:
git remote remove tmp
(and you can stop here if you like; the rest is merely commentary). If that refuses to run because tmp
is gone, use git remote add tmp https://any.url.here
and then git remote remove tmp
.
It's not entirely clear what you mean to say with the phrase "detached branch". You did, however, have a tag, git-detached-head, which I snipped as it is not relevant to this particular setup. These are not "detached HEAD" cases. Instead, these are simply stale names.
One thing that is important here is that these are (presumably) remote-tracking names, or as Git calls them, remote-tracking branch names. That means git branch -delete
won't do the trick, but git branch -r --delete
would (though as SebDieBln notes in a comment, you would also need --force
).
A remote, in Git, is simply a name—like origin
or, in your case, tmp
—that we use to have Git be able to refer to some other Git repository by name, rather than having to type in some long and tedious URL repeatedly. But besides just storing the URL, the existence of a remote provides another ability:
- Each repository has its own branch names.
- Each of these branch names stores one (1) commit hash ID.
The fact that the name stores the hash ID gives us—and Git—an easy way to find the commit hash ID, and that's generally the first way we find commits: by some name. (The second way is by finding a commit—usually through a name—and then working backwards from there to earlier commits, and the third way is by just somehow magically knowing the hash ID, perhaps because we saw it in git log
earlier, which used the second method.)
But in general, the names in some other Git repository aren't accessible to us all the time. We'd have to run git ls-remote
or some similar command to find the hash IDs that go with their branch names. In ancient days (early 2005ish), people actually did this sort of thing. That got really tedious really quickly, like typing in long URLs, so Git was taught the idea of saving not only the URL, but also their branch names and hash IDs, via these remotes. So if you have a remote named origin
and they, whoever they are over at origin
, have a branch named xyzzy
, you end up with an origin/xyzzy
in your repository.
These remote-tracking names essentially serve as a way for your Git repository to remember the branch names in some other Git repository. That's their reason to exist. The git fetch
command builds these remote-tracking names, creating them and updating them whenever it gets a chance. (The git push
command will also update a name on successful push. Note that git pull
means run git fetch
, then run a second Git command and it's the fetch step of pull that updates remote-tracking names.)
The git remote
command is, in general, the user-facing command for manipulating remotes like origin
or (here) tmp
. A git remote add
adds a new remote. A git remote remove
removes the remote, and since the remote-tracking names exist on behalf of the remote, it also removes the remote-tracking names.1
Last:
So I want to delete commits: 8a142e4, 5d43564 and so on from the repo's history.
Deleting the names by which Git finds those hash IDs will stop the commits from showing up in git log
, but won't actually delete the commits. If you memorize their hash IDs and feed them to Git, it's very likely that you can still access those commits by their hash IDs, for at least 30 and perhaps 90 or more days.
Normally, deleting the names, so that you don't see the commits any more, is sufficient. If not, well, it's actually fairly difficult to truly delete a commit—not impossible, but not easy, and the methods don't really belong in this answer, so I will stop here.
1I vaguely recall that in some very early Git version, git remote remove
did not remove the corresponding remote-tracking names. However, these versions of Git should no longer be in use by now.