Finding a patch's kernel version with git [LWN.net]

Finding a patch's kernel version with git

Posted Jun 21, 2010 11:46 UTC (Mon) by marcH (subscriber, #57642)
In reply to: Finding a patch's kernel version with git by farnz
Parent article: Finding a patch's kernel version with git

> Of course, this takes us a long way from your claim that this is an advantage of CVCS - you had said that all I had to do was look at revision numbers;

Yes, all you have to do is to look at revision numbers *in the same branch* (otherwise the order is obviously meaningless). SVN makes this very easy whereas git does not (because branches are so much more flexible in git). That's all really.

The rest is just about the day you overlooked SVN branches, not very relevant to this discussion.

As long as you use "branchless" SVN revision numbers + make wild guesses about these numbers then you will hit the same problem again and again. Simply stop making guesses; how difficult is that? By the way your painfully long explanation above demonstrates that this type of mistake is not common, even for your team.

(Log in to post comments)

Finding a patch's kernel version with git

Posted Jun 21, 2010 12:11 UTC (Mon) by farnz (guest, #17727) [Link]

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?

Finding a patch's kernel version with git

Posted Jun 21, 2010 16:12 UTC (Mon) by marcH (subscriber, #57642) [Link]

> 1. it's far too easy to accidentally compare revision numbers in different branches, without realising that that's what you've done.
> [...]
> 2. branchless revision numbers happen to work just fine most of the time.

If you cannot see the contradiction above then there is not much that can be done.

> The painfully long explanation is simply because you refused to believe that people did this sort of thing when I presented it without explanation.

The only reason your explanation is long is because it has to enumerate an unlikely long chain of mistakes, oversights and clueless SVN users. Or are you seriously saying such branch confusion happens often at your place? And yet you are still using branchless numbers? Hard to believe.

I asked for more detail because your first "explanation" was just: "thanks to human error, the developer forgot to ensure that the fix was present on TRUNK". This did not explain anything.

> and your initial example didn't include branch names as part of the revision ID, either;[...] why didn't your example include them?

Because you were supposed to read the entire post, not just the beginning of it. OK: this second post of mine sucked. Believe it or not, but I am glad you pushed me in clarifying the whole thing.

Finding a patch's kernel version with git

Posted Jun 21, 2010 16:43 UTC (Mon) by bronson (subscriber, #4806) [Link]

> If you cannot see the contradiction above then there is not much that can be done.

Obviously he sees the contradiction -- he pointed it out. "You're never going to stop people throwing around branchless revision numbers" means that until 'svn st' includes the branch name so people will copy-n-paste both into an email in one swipe, svn users will tend to use branchless revision numbers even when they know better.

You both are doing a great job of slinging insults and quote mining, making very little forward progress on what is ultimately an absurdly simple concept.

Finding a patch's kernel version with git

Posted Jun 21, 2010 15:48 UTC (Mon) by anselm (subscriber, #2796) [Link]

The underlying problem here is that SVN, being conceptually a souped-up CVS, basically deals in »snapshots of trees«. A branch in SVN is essentially just another subdirectory inside the repository (alongside »trunk«), and snapshots of the whole repository tree get numbered consecutively no matter where any changes happen.

DVCSes like git, on the other hand, normally work in terms of »changesets«, i.e., atomic collections of patches to files in the repository. A branch is just a sequence of changesets that hasn't yet been applied to the main repository (the »trunk« if you will).

The advantage of the changeset-based approach is that it is a lot easier to tell whether a repository contains a given change(set), where with SVN the system needs to try to infer this after the fact from looking at the files in question – which is why DVCSes are generally much better at merging than SVN. If the previous poster had used a DVCS instead of SVN, it would have been very obvious that the 4.0.1 bug fix had not been reintroduced to the mainline (i.e., the changeset incorporating the fix had not been merged), where SVN, on the other hand, didn't really help with this. The idea of numbering revisions consecutively even if that doesn't mean anything in the context of a branched repository is not one of the high points of SVN's design.