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

Finding a patch's kernel version with git

Posted Jun 20, 2010 21:00 UTC (Sun) by marcH (subscriber, #57642)
In reply to: Finding a patch's kernel version with git by chad.netzer
Parent article: Finding a patch's kernel version with git

> An analogous situation with SVN could just as easily occur,

Please demonstrate it in more detail, thanks. Warning: you're not allowed completely artificial commands or workflows that a regular SVN user would never use in pratice.

(Log in to post comments)

Finding a patch's kernel version with git

Posted Jun 21, 2010 8:11 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257) [Link]

I'm intrigued by your warning; I'm not sure I want to take on the responsibility of not disappointing you.

Any system of development with feature branches, release branches, and a trunk can allow this situation to occur, since not all features need be merged into trunk before a release. farnz's example was adequate; rev numbers themselves aren't an indicator of when and where a bug might have been merged into trunk. That's why nearly all modern systems have history visualization.

You were discussing "centralized systems", and made the claim "by making branching and merging expensive, you prevent yourself from going into a complicated situation where you cannot easily track commits any more." However, I was discussing SVN, and one of the features of SVN is that branches are cheap:

http://en.wikipedia.org/wiki/Apache_Subversion#Features

So, does your claim apply to SVN? If so, perhaps you can suggest a change to the example SVN workflow on Wikipedia, demonstrating "many branches", so that it can be improved.

http://en.wikipedia.org/wiki/Apache_Subversion#Branching_...

Finding a patch's kernel version with git

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

> one of the features of SVN is that branches are cheap

This is about the implementation while I am talking about the workflow.

Please have a look at one of Linus' rants about centralized systems where he typically complains about the inconvenience of branching *and merging* in such systems.

Finding a patch's kernel version with git

Posted Jun 21, 2010 18:40 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257) [Link]

It's not clear *what* you are talking about. You stated "here is at last a feature centralized systems make much easier", but I don't see that supported, unless you are implying that centralized systems force an inherently linear history or short lived branches. It certainly is not the case that "because you can easily order commits in time and use that order as a commit ID", that you can know without inspection that a bug fix commit is included in a release or not. That requires checking the merge history. Certainly that's not unique to distributed systems.

If you mean that the common workflow in centralized systems does not allow long lived branches, and certainly not across releases, well I suppose I can accept that, but it is more a matter of discipline than central vs. distributed. Basically it means keeping non-mergeable feature branches out of the repository, or always rebasing them after a new release, so that branch rev ids are contained strictly between two releases. Neither option seems pleasant.