Jiri Slaby wrote: > Alan Jenkins napsal(a): >> There must be a better way (for efficient merges, right?). But all I >> can think of is comparing the files in question against the diff. I >> checked myself and the changes don't appear to have been included in >> v2.6.26. > > Ah, I see. Is this a git-describe bug or my misunderstanding of the tool?
It's not an implementation bug. It's just very easy to misunderstand. git-describe only looks _back_ in time to what the current commit is based on. In this case the commit was based on v2.6.26-rc8 - but it _wasn't_ merged into 2.6.26. It was presumably merged in for v2.6.27-rc1. This is a perfectly legal history in GIT. It's probably most often encountered during git-bisect. If you bisect e.g. between v2.6.26 and v.2.6.27-rc1, you're likely to see commits which were based on v2.6.26-rc8. If that doesn't help, try finding an introduction to GIT with some good pictures. I think it's easier to understand it visually. Alan _______________________________________________ ath5k-devel mailing list [email protected] https://lists.ath5k.org/mailman/listinfo/ath5k-devel
