top button
Flag Notify
Site Registration

git describe - strange results

0 votes

I am trying

git describe --contains 21dc**********dd7c494961277d76e1c957fe

and I get:


While the info it returns is correct (this patch was indeed for v2.6.37-rc1), I don't understand the suffix.
What is "~147^2~717" ? any ideas?

And it occurs with every sha I try.
Just another example:

 git describe --contains 02c30a84e6298b6b20a56f0896ac80b47839e134

what is ~37 ? Any ideas?

posted Jun 15, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote
Best answer

It is using the parent^ and ancestor generation~ format shown in specifying revisions section of git-rev-parse. So 147th generation ago from the tag (taking first parent line), then take the second parent in that merge, and then a further 717 ancestors ago (more first parents) you reach your commit.

That's the way I read it.

answer Jun 15, 2013 by anonymous
Similar Questions
0 votes

with git I noticed when I removed a remote branch with git push origin --delete in my clone when I used git branch -a I don't the deleted branch but my colleagues still see it.

I tried with two clones in my PC, with the first one delete branch and the other still sees it despite git pull .

I use git version 2.9.4

+1 vote

I've been trying to put my filesystem for a very small busybox-based distro into a git-repository. And with success. The only strange thing I can not get my head around is the following :

When making a compressed tarball from the files from the repository (after clone/checkout) I get a very much larger tar.gz-file. Size goes up from 16M to 21M (!?)

+2 votes

I am getting some unexpected results from a merge and I'd like to understand why.

I have two commits X and Y that I want to merge.

git merge-base X Y # yields B
git diff B X -- F # is empty
git diff B Y -- F # contains the change I want merged
git rev-list X ^B -- F # is empty
git rev-list Y ^B -- F # contains one commit

git checkout X
git merge Y

fails with fixable merge conflicts on other files, but uses X's copy of F instead of Y's. I was expecting it to use Y's copy of F, since only Y has modified F since B. What could cause this?