top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration
Print Preview

git describe - strange results

0 votes
22 views

I am trying

git describe --contains 21dc330157454046dd7c494961277d76e1c957fe

and I get:

v2.6.37-rc1~147^2~717

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
 v2.6.12-rc4~37

what is ~37 ? Any ideas?

posted Jun 15, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social 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?

0 votes

I have a problem with an already committed file into my repo. This git repo was converted from svn to git some years ago. Last week I have change some lines in a file and I saw in the diff that it is marked as binary (it's a simple .cpp file). I think on the first commit it was detected as an utf-16 file (on windows). But no matter what I do I can't get it back to a "normal text" text file (git does not detect that), but I is now only utf-8. I also replace the whole content of the file with just 'a' and git say it's binary.

Is the only way to get it back to text-mode?:
* copy a utf-8 version of the original file
* delete the file
* make a commit
* add the old file as a new one

I think that will work but it will also break my history.

Is there a better way to get these behavior without losing history?


Useful Links with Similar Problem
Contact Us
+91 9880187415
sales@queryhome.net
support@queryhome.net
#470/147, 3rd Floor, 5th Main,
HSR Layout Sector 7,
Bangalore - 560102,
Karnataka INDIA.
QUERY HOME
...