I want to remove the commit and clear up my git log history.
But when I did, some commits was not disappeared.
(using command : git log --all --graph --oneline)
I don't know why
Here my example
I made 2 branches(br1, br2), and did not merge it with master.
and then I deleted 2 branches (br1, br2)
But still there are commits in the log('log --all' not 'log')
and also I did reset or rebase to delete them.
Did I something do wrong?
or Can't I remove the commit in log when it has tag?
CodePudding user response:
The correct explanation is that you can't remove a commit at all. It doesn't matter whether the commit has a tag or a branch name associated with it, as far as its existence goes. And it does not matter whether a commit exists either! What matters to git log
is whether git log
can find the commit.
Obviously git log
is not going to find a commit that doesn't exist. But sometimes git log
cannot find a commit that does exist. So the interesting question is really: When can git log
find a commit?
The answer is: Whenever you give it the right hash ID, either directly or indirectly.
You give git log
a commit hash ID directly by typing it in:
git log b30a5cf
for instance. Git looks up that hash ID—technically this is a shortened hash ID; Git checks to make sure that there is exactly one commit with the full hash ID that starts with this b30a5cf
number—and having found that commit, git log
shows that commit. Then it goes on to show some more commits.
You give git log
a commit hash ID indirectly by doing any of these:
- providing a name that translates to a hash ID, such as
master
orbasePoint
for instance; - providing a flag like
--branches
,--tags
, or--all
that tellsgit log
to look up all branch names, all tag names, or all references;1 or - providing, directly or indirectly, the hash ID of a commit that in turn contains the hash ID of another commit, or perhaps multiple additional commits.
This last point is one of the keys to understanding Git. Each commit contains a list of previous commit hash IDs. In most commits, this list has just one entry, which Git calls the parent of the commit. So each commit points—backwards, not forwards—to its parent:
... <-o <-o <-o ...
Here the round o
s represent commits, with later commits towards the right. The later commits each point backwards to one earlier commit.
If you run:
git log master
or:
git log b30a5cf
you tell git log
to look up that particular commit, which it does; it shows the commit, and then finds the commit's parent(s), which in this case is just the one commit c348c14
. The git log
command then displays that commit, and follows the backwards arrow to the next—or rather, previous—commit and displays that one.
With --all
, you tell git log
to start at all commits that have names. This gets more complicated, because now git log
has to show multiple commits all at once, and it literally can't. So it picks out a commit to show based on a priority. Using --graph
modifies the priority selection so that git log
can draw the connections from each commit to its predecessor(s).
Deleting a name does not delete a commit. It merely removes your access to that commit through that name. If you have access to that commit through some other name, you will still be able to find the commit. If you memorize the commit's hash ID, then even with no names or other commits providing access, you can access the commit by raw hash ID.
If there are literally no names by which Git can ever find a commit, that commit becomes eligible for what Git calls garbage collection. These "abandoned" commits will persist for a minimum of 14 days by default, and 30 days by default for most cases. After that, git gc
may decide that the commit has no actual value, and remove it for real. But you can't remove it directly, and you have no control over precisely when git gc
will get around to removing it. All you can do is remove the names that find a commit so that you no longer have to see it.2
1A reference is the generalized form of "any name that can find some Git object". Branch and tag names are two kinds of references, but there are many more.
2In an emergency—such as after accidentally adding a terabyte database to a Git repository—it's possible to clean these things out manually. It's rather tricky though. It's not something you want to do often.
CodePudding user response:
git log
will display any commit reachable.
Meaning:
- reachable from a branch HEAD
- or from a tag
You would therefore need to delete the tag, not just the branch
git tag -d br2-tag
Note that all those steps are for your local repository only.
If you had also pushed those branches and tags, you would need to push their deletion too.
git push --delete origin br2
git push --delete origin br2-tag