LWN.net Logo

Finding a patch's kernel version with git

Finding a patch's kernel version with git

Posted Jun 21, 2010 16:18 UTC (Mon) 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

> 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.


(Log in to post comments)

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.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds