Finding a patch's kernel version with git
Posted Jun 21, 2010 12:11 UTC (Mon) by farnz
In reply to: Finding a patch's kernel version with git
Parent article: Finding a patch's kernel version with git
The problem is that because revision numbers are not per-branch in most CVCSes (CVS is one exception), it's far too easy to accidentally compare revision numbers in different branches, without realising that that's what you've done. You're never going to stop people throwing around branchless revision numbers (whether they be SVN repository versions, or git SHA tags), because they're a convenient shorthand and happen to work just fine most of the time.
Further, because it's "obvious" that r176594 came after r176593, it's all too easy to assume that whatever changed in r176593 is also changed in r176594. This isn't a safe assumption in a world with branches, but in a CVCS world, you normally get away without explicitly stating which branch a revision is on. Same applies in the DVCS world, but because there's no "obvious" order to DVCS commit IDs, people don't make assumptions when they see a bare revision number; they'll check one way or another.
The painfully long explanation is simply because you refused to believe that people did this sort of thing when I presented it without explanation. Now I've added an explanation, you're complaining that it's unrealistic because I've had to tell you in great detail just how it happens, since you didn't believe that it did happen at all unless you had it explained in great detail?!? Oh, and your initial example didn't include branch names as part of the revision ID, either; if you really expect that developers don't use bare revision IDs, but use the combination of branch name and revision ID, why didn't your example include them?
to post comments)